只有細節能夠決定成敗嗎？


2019年馬上就要過去了，突然意識到自己09年畢業，到今年已經整整過去10年了。真是歲月如梭、光陰似箭啊。

從大一學C語言後，就開始用C語言寫練習，到如今也算寫了14年的程式碼了。

記得剛工作時，大家討論的內容是用table佈局呢還是用div佈局，10年後的今天再來看看這些事情，可能自己都會笑出聲來。

是啊，10年間變化的不僅僅是技術的迭代、興起與滅亡。還有人，包括自己在內，對很多事物的認知、看法或想法都發生了變化。

剛工作時，總是喜歡關注細節，會為自己又學會哪些知識點或寫出了一段自認為還不錯的程式碼而沾沾自喜。

10年後的今天，我更傾向於從整體上或巨集觀上去看待一件事情或一個事物，甚至去研究它的起因，變化過程或趨勢，然後嘗試著去推測它的未來。

但這並不是說，我全然放棄了對細節的追求。其實從巨集觀上觀察有時會更利於對細節的理解。細節在關鍵時刻還是很重要的，畢竟有句話叫“細節決定成敗。

無論各行各業，隨著時間的推移，唯一不變的就是變化，無非是有的變化的猛烈，有的變化的輕柔罷了。

那麼問題來了，“巨集觀”和“細節”在變化面前，哪個能夠堅持的久一些，或者說變化的慢一些？

如果把“巨集觀”看作是整體架構或結構，把“細節”看作是實現方式或處理方法，你會優先關注哪一個呢？

細節還能決定成敗嗎？能，當然能。但是巨集觀同樣關乎著命運，甚至影響著未來的走向。

從某種意義上講，巨集觀應該受到的關注度更高一些，但至少應該和細節持平。因為“巨集觀”通常和整體結構對應，“細節”通常和區域性處理對應。

整體結構一旦確定下來，後期改起來很麻煩，因為牽扯到的方面太多。但是區域性處理因涉及範圍較小，後期更換處理方法會相對容易一些。

無論是從理論還是實踐來看，實現細節是變化最頻繁的。所以我們應該做的是把整體結構設計良好，具體某個地方的實現細節根據實際情況而定。

不過很多人總是會陷入去關注細節，讓細節佔據自己的大部分思維，往往忽視了從巨集觀整體上的把握，或在此上面投入的精力不夠。


程式 = 資料結構 + 演算法


只要是計算機專業的，或半路轉行但愛學習的，都知道這樣一個公式，程式 = 資料結構 + 演算法。很顯然，這個公式是老外很早提出的，不過基本上所有人都是認可的。

我之前還看到有老外說過，在資料結構和演算法這兩者中，資料結構要更重要一些，它的重要性是要大於演算法的。我個人是比較同意這個觀點的。

比如，有這樣一道題目，給你一個單鏈表，要逆向輸出一下。拿到這個題目後，不管最終如何實現，至少要去想一想。

現在把這個題目改一下，給你一個雙向連結串列，也逆向輸出一下。拿到這個題目後，根本就不用想，直接從尾部向前輸出即可。

可以看到，資料結構變了之後，實現方法一下子就簡單了很多。所以資料結構的重要性是要大於演算法的。可以說是資料結構決定了演算法。

就像人們常說的，雖然條條道路通羅馬，但有些人一出生就在羅馬。就算你的排序演算法再快，都不可能比已經有序根本就不用排序的還快。當然，這是極限思維的運用。

說起資料結構，很多人第一反應就是大學資料結構這門課裡講的東西，線性表啊，樹啊，圖啊等這些。

說起演算法，很多人也肯定認為就是書上講的那些，氣泡排序啊，快速排序啊，二分查詢啊，深度優先/廣度優先遍歷啊等這些。

怎麼說呢，這些其實都是非常學院派的說法，如果是一個學生或剛參加工作時間不長，可以這樣來理解。

一旦到實際應用當中，相當於進入了工程界，脫離了學術圈，很多事情都要重新換個立場或角度去看待。

所以資料結構指的是資料的儲存方式或描述方式，我們自己定義的介面啊、類啊這些都叫資料結構，並不只是List或Map這些才是。

同樣，演算法就是指解決問題的方法，我們平常寫的一些程式碼也可以稱為演算法，並不只是像排序演算法、雜湊演算法或選舉演算法這些才是。

好了，現在可以想一想我們寫的程式程式碼，大部分都是什麼樣子的？不就是定義資料，獲取資料，傳遞資料，操作資料，儲存資料嘛。

定義資料就是類，獲取資料就是查詢資料庫或從客戶端提交，傳遞資料就是本地方法的引數或遠端呼叫時資料的協議傳輸，操作資料就是各種運算/轉換/排序等，儲存資料就是類物件或容器物件或資料庫等。

定義資料和儲存資料就是資料結構呀，操作資料就是演算法呀，所以，程式 = 資料結構 + 演算法。

如果資料結構經過精心設計，那麼演算法就會變得很簡單，如果再處理好資料的獲取與傳遞，那最終寫出來的程式，一定是非常棒的程式碼。

不信自己試試看。


軟體 = 邏輯抽象 + 合理實現


離散的程式程式碼可能沒有太大的意義，但是把它們堆在一起構成具有某種功能的軟體就會產生一定的價值。所以從微觀上看，軟體就是一堆程式程式碼。

從巨集觀上看，軟體又分為系統軟體、應用軟體和中介軟體。國內搞系統軟體的應該比較少，大部分都是應用軟體和一些中介軟體。但不管什麼軟體，最終都是在計算機上執行的。

那麼計算機是怎麼來的呢？不是土裡長出來的，也不是樹上結出來的，更不是某個物種進化的。它是人類的偉大發明，是抽象出來的，而且是符合邏輯的。所以在計算機的世界裡，邏輯和抽象佔據很重要的地位。

那麼軟體是怎麼來的呢？可能是產品團隊會進行市場調研，功能規劃，介面設計和互動設計等。嚴格來說這些只能叫做原型或需求。只有當著手和實現相關的工作時，才是軟體的真正開始。

從程式角度，軟體的實現都是從邏輯抽象開始，無論是橫向的分模組還是縱向的分層，或者說分子系統，只不過是不同的抽象方法運用而已。這個邏輯抽象是非常非常重要的，凡是存活時間長的軟體，都是經過良好邏輯抽象的。

因為隨著時間的推移，所有事物都在變化，良好的抽象更能抵抗變化，或更能適應變化，所以活的時間就會更久一些。

邏輯抽象是一個很複雜的問題，裡面涉及很多哲學的思想或權衡的問題。比如，自動化程度高的軟體，定製性不強，不容易滿足使用者的個性化需求。定製性強的軟體，必定自動化程度不高，會造成使用者難以上手，不容易普及推廣。

 

大家想想Hibernate的消亡以及Mybatis的興起，就是一個定製化大於自動化的結果。Linux用作伺服器作業系統，需要專人維護。Windows用作日常辦公系統，每個人都會用。平板電腦則走進千家萬戶，連3歲小孩都玩的很溜。無所謂好與壞，定位不同罷了。

 

所以抽象是一個綜合問題，充滿著哲學、權衡與取捨。沒有特別統一的標準，也沒有嚴格意義的對與錯。只有你更關注什麼，或更期望什麼。

抽象完了之後，一定要能合理實現才行。不能為了抽象而抽象，最後無法實現，一切不能落地的，都是空談。比如抽象一個腦機介面，把大腦和計算機連線起來，通過意識交流，這恐怕暫時真的實現不了。


總的來說，就是這樣：

 

一、合理抽象，劃分好子系統/模組，定義好功能邊界、互動方式，這樣整體結構非常清晰。

二、精心設計資料結構，定義好類或介面，這樣會使程式碼寫起來變的簡單，而且後期容易改。

三、其實就是既從巨集觀整體把握，又著眼於具體實現細節，可稱之為有勇有謀。

 

當然，這是理想情況，實際上是這樣：

day 1
老闆：“來來來，我有個需求給你說下”。

我：“好的”。

day 2
老闆：“昨天的那種方式不好，按這種方式實現吧”。

我：“好的”。

day 3
老闆：“昨天的那種方式好像還有點問題，按這種新的方式實現吧”。

我：“好的”。

day 4
老闆：“昨天的那種方式好是好，可能別人一時不太好接受，要不還是按最開始的方式實現吧”。

我：“好的”。

day 5
老闆：“多長時間能做好”。

我：“投入5個人，大概2個月吧”。
老闆：“我給你20個人，半個月能弄好吧”。

我：“這個。。。”。
老闆：“哦，對了，以後再招人，35以上的不要了啊”。

我：“好的”。

 

咦，莫非老闆是在暗示我，因為明年我就35啦。

 

以上內容純屬娛樂，請各位老闆不要當真哦。哈哈，祝賀自己畢業10年啦！

 

 

（END）

 

作者是工作超過10年的碼農，現在任架構師。喜歡研究技術，崇尚簡單快樂。追求以通俗易懂的語言解說技術，希望所有的讀者都能看懂並記住。下面是公眾號的二維碼，歡迎關注！