毕业10年，我有话说
今天帶來一篇大佬的文章，公眾號“編程新說”的作者李新杰，工作超過10年，現(xiàn)任架構師，喜歡研究技術，崇尚簡單快樂。
只有細節(jié)能夠決定成敗嗎？
6月22號看到很多高校畢業(yè)典禮的新聞，當時也沒多想。今天想到這個事，突然意識到自己09年畢業(yè)，到今年已經(jīng)整整過去10年了。真是歲月如梭、光陰似箭啊。
從大一學C語言后，就開始用C語言寫練習，到如今也算寫了14年的代碼了。
記得剛工作時，大家討論的內(nèi)容是用table布局呢還是用div布局，10年后的今天再來看看這些事情，可能自己都會笑出聲來。
是啊，10年間變化的不僅僅是技術的迭代、興起與滅亡。還有人，包括自己在內(nèi)，對很多事物的認知、看法或想法都發(fā)生了變化。
剛工作時，總是喜歡關注細節(jié)，會為自己又學會哪些知識點或寫出了一段自認為還不錯的代碼而沾沾自喜。
10年后的今天，我更傾向于從整體上或宏觀上去看待一件事情或一個事物，甚至去研究它的起因，變化過程或趨勢，然后嘗試著去推測它的未來。
但這并不是說，我全然放棄了對細節(jié)的追求。其實從宏觀上觀察有時會更利于對細節(jié)的理解。細節(jié)在關鍵時刻還是很重要的，畢竟有句話叫“細節(jié)決定成敗”。
無論各行各業(yè)，隨著時間的推移，唯一不變的就是變化，無非是有的變化的猛烈，有的變化的輕柔罷了。
那么問題來了，“宏觀”和“細節(jié)”在變化面前，哪個能夠堅持的久一些，或者說變化的慢一些？
如果把“宏觀”看作是整體架構或結構，把“細節(jié)”看作是實現(xiàn)方式或處理方法，你會優(yōu)先關注哪一個呢？
細節(jié)還能決定成敗嗎？能，當然能。但是宏觀同樣關乎著命運，甚至影響著未來的走向。
從某種意義上講，宏觀應該受到的關注度更高一些，但至少應該和細節(jié)持平。因為“宏觀”通常和整體結構對應，“細節(jié)”通常和局部處理對應。
整體結構一旦確定下來，后期改起來很麻煩，因為牽扯到的方面太多。但是局部處理因涉及范圍較小，后期更換處理方法會相對容易一些。
無論是從理論還是實踐來看，實現(xiàn)細節(jié)是變化最頻繁的。所以我們應該做的是把整體結構設計良好，具體某個地方的實現(xiàn)細節(jié)根據(jù)實際情況而定。
不過很多人總是會陷入去關注細節(jié)，讓細節(jié)占據(jù)自己的大部分思維，往往忽視了從宏觀整體上的把握，或在此上面投入的精力不夠。
程序 = 數(shù)據(jù)結構 + 算法
只要是計算機專業(yè)的，或半路轉行但愛學習的，都知道這樣一個公式，程序 = 數(shù)據(jù)結構 + 算法。這個公式是老外很早提出的，不過基本上所有人都是認可的。
我之前還看到有老外說過，在數(shù)據(jù)結構和算法這兩者中，數(shù)據(jù)結構要更重要一些，它的重要性是要大于算法的。我個人是比較同意這個觀點的。
比如，有這樣一道題目，給你一個單鏈表，要逆向輸出一下。拿到這個題目后，不管最終如何實現(xiàn)，至少要去想一想。
現(xiàn)在把這個題目改一下，給你一個雙向鏈表，也逆向輸出一下。拿到這個題目后，根本就不用想，直接從尾部向前輸出即可。
可以看到，數(shù)據(jù)結構變了之后，實現(xiàn)方法一下子就簡單了很多。所以數(shù)據(jù)結構的重要性是要大于算法的?？梢哉f是數(shù)據(jù)結構決定了算法。
就像人們常說的，雖然條條道路通羅馬，但有些人一出生就在羅馬。就算你的排序算法再快，都不可能比已經(jīng)有序根本就不用排序的還快。當然，這是極限思維的運用。
說起數(shù)據(jù)結構，很多人第一反應就是大學數(shù)據(jù)結構這門課里講的東西，線性表啊，樹啊，圖啊等這些。
說起算法，很多人也肯定認為就是書上講的那些，冒泡排序啊，快速排序啊，二分查找啊，深度優(yōu)先/廣度優(yōu)先遍歷啊等這些。
怎么說呢，這些其實都是非常學院派的說法，如果是一個學生或剛參加工作時間不長，可以這樣來理解。
一旦到實際應用當中，相當于進入了工程界，脫離了學術圈，很多事情都要重新?lián)Q個立場或角度去看待。
所以數(shù)據(jù)結構指的是數(shù)據(jù)的存儲方式或描述方式，我們自己定義的接口啊、類啊這些都叫數(shù)據(jù)結構，并不只是List或Map這些才是。
同樣，算法就是指解決問題的方法，我們平常寫的一些代碼也可以稱為算法，并不只是像排序算法、哈希算法或選舉算法這些才是。
好了，現(xiàn)在可以想一想我們寫的程序代碼，大部分都是什么樣子的？不就是定義數(shù)據(jù)，獲取數(shù)據(jù)，傳遞數(shù)據(jù)，操作數(shù)據(jù)，存儲數(shù)據(jù)嘛。
定義數(shù)據(jù)就是類，獲取數(shù)據(jù)就是查詢數(shù)據(jù)庫或從客戶端提交，傳遞數(shù)據(jù)就是本地方法的參數(shù)或遠程調(diào)用時數(shù)據(jù)的協(xié)議傳輸，操作數(shù)據(jù)就是各種運算/轉換/排序等，存儲數(shù)據(jù)就是類對象或容器對象或數(shù)據(jù)庫等。
定義數(shù)據(jù)和存儲數(shù)據(jù)就是數(shù)據(jù)結構呀，操作數(shù)據(jù)就是算法呀，所以，程序 = 數(shù)據(jù)結構 + 算法。
如果數(shù)據(jù)結構經(jīng)過精心設計，那么算法就會變得很簡單，如果再處理好數(shù)據(jù)的獲取與傳遞，那最終寫出來的程序，一定是非常棒的代碼。
不信自己試試看。
軟件 = 邏輯抽象 + 合理實現(xiàn)
從程序角度，軟件的實現(xiàn)都是從邏輯抽象開始，無論是橫向的分模塊還是縱向的分層，或者說分子系統(tǒng)，只不過是不同的抽象方法運用而已。這個邏輯抽象是非常非常重要的，凡是存活時間長的軟件，都是經(jīng)過良好邏輯抽象的。
因為隨著時間的推移，所有事物都在變化，良好的抽象更能抵抗變化，或更能適應變化，所以活的時間就會更久一些。
邏輯抽象是一個很復雜的問題，里面涉及很多哲學的思想或權衡的問題。比如，自動化程度高的軟件，定制性不強，不容易滿足用戶的個性化需求。定制性強的軟件，必定自動化程度不高，會造成用戶難以上手，不容易普及推廣。
大家想想Hibernate的消亡以及Mybatis的興起，就是一個定制化大于自動化的結果。Linux用作服務器操作系統(tǒng)，需要專人維護。Windows用作日常辦公系統(tǒng)，每個人都會用。平板電腦則走進千家萬戶，連3歲小孩都玩的很溜。無所謂好與壞，定位不同罷了。
所以抽象是一個綜合問題，充滿著哲學、權衡與取舍。沒有特別統(tǒng)一的標準，也沒有嚴格意義的對與錯。只有你更關注什么，或更期望什么。
抽象完了之后，一定要能合理實現(xiàn)才行。不能為了抽象而抽象，最后無法實現(xiàn)，一切不能落地的，都是空談。比如抽象一個腦機接口，把大腦和計算機連接起來，通過意識交流，這恐怕暫時真的實現(xiàn)不了。
總的來說，就是這樣：
一、合理抽象，劃分好子系統(tǒng)/模塊，定義好功能邊界、交互方式，這樣整體結構非常清晰。
二、精心設計數(shù)據(jù)結構，定義好類或接口，這樣會使代碼寫起來變的簡單，而且后期容易改。
三、其實就是既從宏觀整體把握，又著眼于具體實現(xiàn)細節(jié)，可稱之為有勇有謀。
當然，這是理想情況，實際上是這樣：
day 1
老板：“來來來，我有個需求給你說下”。
我：“好的”。
day 2
老板：“昨天的那種方式不好，按這種方式實現(xiàn)吧”。
我：“好的”。
day 3
老板：“昨天的那種方式好像還有點問題，按這種新的方式實現(xiàn)吧”。我：“好的”。
day 4
老板：“昨天的那種方式好是好，可能別人一時不太好接受，要不還是按最開始的方式實現(xiàn)吧”。
我：“好的”。
day 5
老板：“多長時間能做好”。
我：“投入5個人，大概2個月吧”。
老板：“我給你20個人，半個月能弄好吧”。
我：“這個。。?！薄?/p>
老板：“哦，對了，以后再招人，35以上的不要了啊”。
我：“好的”。
咦，莫非老板是在暗示我，因為明年我就35啦。
以上內(nèi)容純屬娛樂，請各位老板不要當真哦。哈哈，祝賀自己畢業(yè)10年啦！
總結
以上是生活随笔為你收集整理的毕业10年，我有话说的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Elastic Search 上市了，S
- 下一篇： SELECT COUNT(*) 底层究竟