2023年馬上就要過去了，突然意識到自己09年畢業，到今年已經整整過去10年了。真是歲月如梭、光陰似箭啊。
從大一學c語言後，就開始用c語言寫練習，到如今也算寫了14年的**了。
記得剛工作時，大家討論的內容是用table布局呢還是用div布局，10年後的今天再來看看這些事情，可能自己都會笑出聲來。
是啊，10年間變化的不僅僅是技術的迭代、興起與滅亡。還有人，包括自己在內，對很多事物的認知、看法或想法都發生了變化。
剛工作時，總是喜歡關注細節，會為自己又學會哪些知識點或寫出了一段自認為還不錯的**而沾沾自喜。
10年後的今天，我更傾向於從整體上或巨集觀上去看待一件事情或乙個事物，甚至去研究它的起因，變化過程或趨勢，然後嘗試著去推測它的未來。
但這並不是說，我全然放棄了對細節的追求。其實從巨集觀上觀察有時會更利於對細節的理解。細節在關鍵時刻還是很重要的，畢竟有句話叫「細節決定成敗。
無論各行各業，隨著時間的推移，唯一不變的就是變化，無非是有的變化的猛烈，有的變化的輕柔罷了。
那麼問題來了，「巨集觀」和「細節」在變化面前，哪個能夠堅持的久一些，或者說變化的慢一些？
如果把「巨集觀」看作是整體架構或結構，把「細節」看作是實現方式或處理方法，你會優先關注哪乙個呢？
細節還能決定成敗嗎？能，當然能。但是巨集觀同樣關乎著命運，甚至影響著未來的走向。
從某種意義上講，巨集觀應該受到的關注度更高一些，但至少應該和細節持平。因為「巨集觀」通常和整體結構對應，「細節」通常和區域性處理對應。
整體結構一旦確定下來，後期改起來很麻煩，因為牽扯到的方面太多。但是區域性處理因涉及範圍較小，後期更換處理方法會相對容易一些。
無論是從理論還是實踐來看，實現細節是變化最頻繁的。所以我們應該做的是把整體結構設計良好，具體某個地方的實現細節根據實際情況而定。
不過很多人總是會陷入去關注細節，讓細節佔據自己的大部分思維，往往忽視了從巨集觀整體上的把握，或在此上面投入的精力不夠。
程式 = 資料結構 + 演算法
只要是計算機專業的，或半路轉行但愛學習的，都知道這樣乙個公式，程式 = 資料結構 + 演算法。很顯然，這個公式是老外很早提出的，不過基本上所有人都是認可的。
我之前還看到有老外說過，在資料結構和演算法這兩者中，資料結構要更重要一些，它的重要性是要大於演算法的。我個人是比較同意這個觀點的。
比如，有這樣一道題目，給你乙個單鏈表，要逆向輸出一下。拿到這個題目後，不管最終如何實現，至少要去想一想。
現在把這個題目改一下，給你乙個雙向鍊錶，也逆向輸出一下。拿到這個題目後，根本就不用想，直接從尾部向前輸出即可。
可以看到，資料結構變了之後，實現方法一下子就簡單了很多。所以資料結構的重要性是要大於演算法的。可以說是資料結構決定了演算法。
就像人們常說的，雖然條條道路通羅馬，但有些人一出生就在羅馬。就算你的排序演算法再快，都不可能比已經有序根本就不用排序的還快。
當然，這是極限思維的運用。
說起資料結構，很多人第一反應就是大學資料結構這門課裡講的東西，線性表啊，樹啊，圖啊等這些。
說起演算法，很多人也肯定認為就是書上講的那些，氣泡排序啊，快速排序啊，二分查詢啊，深度優先/廣度優先遍歷啊等這些。
怎麼說呢，這些其實都是非常學院派的說法，如果是乙個學生或剛參加工作時間不長，可以這樣來理解。
一旦到實際應用當中，相當於進入了工程界，脫離了學術圈，很多事情都要重新換個立場或角度去看待。
所以資料結構指的是資料的儲存方式或描述方式，我們自己定義的介面啊、類啊這些都叫資料結構，並不只是list或map這些才是。
同樣，演算法就是指解決問題的方法，我們平常寫的一些**也可以稱為演算法，並不只是像排序演算法、雜湊演算法或選舉演算法這些才是。
好了，現在可以想一想我們寫的程式**，大部分都是什麼樣子的？不就是定義資料，獲取資料，傳遞資料，運算元據，儲存資料嘛。
定義資料就是類，獲取資料就是查詢資料庫或從客戶端提交，傳遞資料就是本地方法的引數或遠端呼叫時資料的協議傳輸，運算元據就是各種運算/轉換/排序等，儲存資料就是類物件或容器物件或資料庫等。
定義資料和儲存資料就是資料結構呀，運算元據就是演算法呀，所以，程式 = 資料結構 + 演算法。
如果資料結構經過精心設計，那麼演算法就會變得很簡單，如果再處理好資料的獲取與傳遞，那最終寫出來的程式，一定是非常棒的**。
不信自己試試看。
軟體 = 邏輯抽象 + 合理實現
離散的程式**可能沒有太大的意義，但是把它們堆在一起構成具有某種功能的軟體就會產生一定的價值。所以從微觀上看，軟體就是一堆程式**。
從巨集觀上看，軟體又分為系統軟體、應用軟體和中介軟體。國內搞系統軟體的應該比較少，大部分都是應用軟體和一些中介軟體。但不管什麼軟體，最終都是在計算機上執行的。
那麼計算機是怎麼來的呢？不是土里長出來的，也不是樹上結出來的，更不是某個物種進化的。它是人類的偉大發明，是抽象出來的，而且是符合邏輯的。所以在計算機的世界裡，邏輯和抽象佔據很重要的地位。
那麼軟體是怎麼來的呢？可能是產品團隊會進行市場調研，功能規劃，介面設計和互動設計等。嚴格來說這些只能叫做原型或需求。只有當著手和實現相關的工作時，才是軟體的真正開始。
從程式角度，軟體的實現都是從邏輯抽象開始，無論是橫向的分模組還是縱向的分層，或者說分子系統，只不過是不同的抽象方法運用而已。這個邏輯抽象是非常非常重要的，凡是存活時間長的軟體，都是經過良好邏輯抽象的。
因為隨著時間的推移，所有事物都在變化，良好的抽象更能抵抗變化，或更能適應變化，所以活的時間就會更久一些。
邏輯抽象是乙個很複雜的問題，裡面涉及很多哲學的思想或權衡的問題。比如，自動化程度高的軟體，定製性不強，不容易滿足使用者的個性化需求。定製性強的軟體，必定自動化程度不高，會造成使用者難以上手，不容易普及推廣。
抽象完了之後，一定要能合理實現才行。不能為了抽象而抽象，最後無法實現，一切不能落地的，都是空談。比如抽象乙個腦機介面，把大腦和計算機連線起來，通過意識交流，這恐怕暫時真的實現不了。
總的來說，就是這樣：
day 1
老闆：「來來來，我有個需求給你說下」。
day 2
老闆：「昨天的那種方式不好，按這種方式實現吧」。
day 3
老闆：「昨天的那種方式好像還有點問題，按這種新的方式實現吧」。
day 4
老闆：「昨天的那種方式好是好，可能別人一時不太好接受，要不還是按最開始的方式實現吧」。
day 5
老闆：「多長時間能做好」。
哈哈，祝賀自己畢業10年啦！
是工作超過
10年的碼農，現在任架構師。喜歡研究技術，崇尚簡單快樂。
追求以通俗易懂的語言解說技術，希望所有的讀者都能看懂並記住。
DNSV如何做好實驗記錄？我有話說！
dnsv如何做好實驗記錄？一 質量記錄過程中常見的問題與對策 記錄是記載過程狀態和過程結果的檔案，是質量管理體系檔案的乙個重要組成部分。所謂過程狀態主要針對產品質量的形成過程和體系的執行過程，而過程結果則是指體系執行效果和產品滿足質量要求的程度。根據記錄的上述特性，記錄在組織的質量管理體系中發揮著重...
我的那些年 2 我畢業了
回到目錄 在家待業，等待老師介紹工作 2003年，我從校園走出來了，大部分同學都已經找到了工作，就在我們7月拿畢業證時，很多人都已經上班了，而我還在家裡等老師的訊息，當時自己也去過人才市場，記得是和我舅媽一起的，還請了吃了麥當勞，那應該是我第一次吃這種東西，人才市場是雍和宮的，在市場裡居然沒有乙個計...
我的畢業實習一年總結
2013年6月份出來到鄭州雲計畫科技 作為乙個剛畢業的菜鳥。剛開始很多東西都不明白，但是對未來我卻很有把握，很清楚自己在做什麼。作為跳板，我來到了雲 計畫科技 培訓了幾個月。由於在學校自己學的還可以。雖然培訓的時候沒有學到太多，但是感覺學東西這件事請完全就是靠自己。別人幫不了你。只有你自己才是主 宰...