只有細節能夠決定成敗嗎？
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年的碼農，現在任架構師。喜歡研究技術，崇尚簡單快樂。追求以通俗易懂的語言解說技術，希望所有的讀者都能看懂並記住。下面是公眾號的二維碼，歡迎關注！
