回顧15年程式設計師生涯，我總結的7點經驗

我和很多人交流過一個有趣的現象，那就是剛畢業到30歲這段時間，會覺得時間過得很慢，總覺得自己還很年輕，但是一旦過了30歲，時間就如白駒過隙，一年又一年飛逝而過。

我自己也是，眼瞅著畢業快15年了，15年間從一個剛畢業的菜鳥，成長為技術骨幹，做到架構師的職位，回頭看看，當年聽取親戚的一句話，誤入計算機行業，看來並沒有走錯，程式設計雖然枯燥辛苦，但是如果真的感興趣，你就能體會到其中的樂趣，並且獲得可觀的回報。

1.好奇心

劉慈欣在《朝聞道》中描繪過這麼一個情節：在古老的非洲大陸上，有個原始人無意中抬頭仰望星空，凝視的時間稍微長了一些，超過了外星人設定的閾值，立刻拉響了人類即將產生文明的警報。因為外星人認為，人類已經產生了對宇宙的好奇心，文明的產生，科技的發展不過是一瞬間的事情。

確實是這樣，好奇心驅動人類不斷向前，在短短的幾千年（相對於長達幾十萬年的原始時代）裡就登上了月球，並且努力向其他行星擴充。

對於程式設計師來說也是類似，如果你看到新技術，新產品沒有像小孩看到新玩具那樣兩眼放光，沒有想趕緊在自己電腦上玩玩的衝動，你就需要仔細考慮下是否真的對軟體開發有興趣？如果根本沒興趣，不要浪費時間，還是趁早轉行，有更多有前（錢）途的職業在等著你。

沒有好奇心，就不願意追本溯源，追求技術的本質。

沒有好奇心，就難於靜下心來，耐得住寂寞，遠離浮躁和程式碼奮鬥，更難於跨過這個苦逼行業帶來的種種挑戰，走到架構師這個位置了。

沒有好奇心，就不願意學習新技術，一個架構師，如果沒有對技術的敏感度和前瞻性，一直抱著一套技術架構不變，估計很快會被淘汰。

當然自制力強大的人除外，但話說回來，靠著自制力讓自己做自己不喜歡的事情，豈不非常痛苦？

我在上公司的一個關於Leader的培訓課的時候，老師一直在說Passion（激情），Passion，Passion，但我一直覺得沒有好奇心，沒有興趣，怎麼會產生Passion呢？

所以，對技術的好奇心/興趣，是一切的基礎。

2.養成計算機的思維方式

之前在“碼農翻身”公共號發過一篇文章，叫《學會程式設計，而不是學會Java》說的就是要能夠以計算機的方式去思考。

現在的計算機還很“弱智”，你不能這麼說：『電腦，我要建立一個像Java的ArrayList類似的類，有個get、add、remove方法，還有這個ArrayList的容量不是固定的，能夠自增長，快點給我寫出來！』

現在的電腦當然寫不出來。

相反你只能用計算機能理解的方式，用非常非常低階的計算機語言去告訴它做事情：建立一個類，分配一個固定大小的陣列用來存放資料，用一個數（size）來記錄陣列裡存了多少資料。如果陣列滿了，就需要增大陣列，並且把資料從老陣列複製到新陣列。

這裡邊有很多很多的煩人的細節需要你去處理，一不留神就會出錯—計算機程式設計就是這樣。

養成計算機的思維方式，流暢的把人類語言的需求轉化成計算機語言，這是程式設計師的基本功。

很多人會語法，也懂框架，但是在基本功上卻不過關，只能在初級程式設計師上踏步。

這個基本功的訓練就是資料結構和演算法，我的經驗是多做習題（大學時我把資料結構後面的習題都做了一遍），讓這個思維在腦子裡固化，以後的程式設計就可以信手拈來了。

3.紮實的基礎，並且能融會貫通

我很久之前參與過一點開源軟體的開發，有幸看到了一個老程式設計師的簡歷，讓我震驚的是他竟然在Altair這個最早的電腦上編過程式。

沒錯，Altair就是那個連顯示器和鍵盤都沒有，靠撥動開關來輸入，靠指示燈來輸出的所謂“個人電腦”，比爾蓋茲和保羅艾倫在上面寫了一個Baisc的直譯器，從此開始微軟之路。

如果有了在這樣的機器上程式設計的經歷，我相信這些老程式設計師對硬體，驅動，作業系統，應用軟體的理解要遠遠超過我們現在這些人。

我之前要寫文章遇到了一個問題：一個程式要讀取檔案，在底層用的是DMA的方式，DMA完成檔案讀取以後要通過中斷讓CPU去處理，但是CPU和中斷處理程式根本不知道程式的ID，它怎麼去和進行關聯，如何去喚醒那個等待的程式？這個問題讓我意識到其實我對計算機的基礎也並沒有融匯貫通。

我們大學裡都學過計算機組成原理、作業系統、編譯原理、計算機網路、資料庫、組合語言，能不能把這些知識融會貫通，打通任督二脈，在我們的腦海裡建立一個計算機運算的圖景？

把這些知識融為一體，我相信能超越絕大多數程式設計師。

現在的軟體開發封裝的層次已經非常高了，只要學會Java就能做一個程式設計工作了，隨著你做的越來越深，越來越專，這些基礎的問題就會浮現出來。

更重要的是，計算機軟硬體的基本思想在這幾十年裡其實變化不大，例如快取，增加抽象層等，有了這麼基本的思想的武裝，去學習新的東西不但學的快，理解的會更透徹。

4.要透徹的理解一個技術的本質

先舉個Ant中的例子，大部分人學習Ant只是學會怎麼使用，認識到Ant提供了很多內建的task來幫助我們方便的完成自動化的構建，例如命令。

<copytodir="../backup/dir">
<filesetdir="src_dir"/>
<filterset>
<filtertoken="TITLE"value="FooBar"/>
</filterset>
</copy>

很少人會思考為什麼Ant的task是以XML來描述的？為什麼Ant不提供一套Java類庫/API來讓程式設計師用，那樣不是更自然嗎？

這其中的一個重要原因就是XML可以自定義標籤，所以表達力無與倫比；如果用java，它的語法不允許自定義一個像copy、fileset這樣的關鍵字，只能定義一些類來模擬這些Copy、Fileset，就沒有這麼簡單明瞭，不信你嘗試一下。

Ant給我們的重要啟示就是，用XML來描述任務，能極大的擴充套件語言的能力。但是Ant的問題就是需要程式設計師處理太多的細節，指定原始碼路徑，指定編譯檔案的路徑，指定資原始檔的路徑，指定需要的jar包及其位置，很煩心。

於是Maven出來使用“約定優於配置”的方式解決了Ant的問題。

理解了技術的本質以後就能夠觸類旁通，就能夠快速學習，這在技術更新很快的軟體行業尤為重要。

只是學會使用是不行的，不但要知道how，還要知道why。

停下來，思考，才是進步的本質。

5.要能寫漂亮的程式碼

架構師不是高高在上，脫離程式碼只說不做的人。架構師首先是一個優秀的程式設計師，要能夠編寫專案或產品中的核心功能，隨時能夠捲起袖子去解決專案中的問題。

程式碼寫的不漂亮怎麼能拿得出手？怎麼能夠服人？

所謂漂亮程式碼不僅僅是清晰、易懂、優雅，更要實現功能，沒有Bug或者極少Bug。

其實如果程式碼簡單優雅，一般沒什麼問題。

寫出漂亮程式碼並不容易，需要思路清晰，有良好的程式設計基礎，有優秀的抽象能力，以及對一門語言的熟練掌握。

6.抽象的能力

抽象思考的能力怎麼強調都不為過。

現實的需求紛繁複雜，如果架構師不能夠把這些亂無頭緒的需求抽象成一些“概念”，在概念的層次進行思考，系統根本就無法設計。

但是抽象出概念以後還不夠，還要看看這個概念是不是正交的，能不能獨立變化，如果不能，考慮下新的概念抽象。

“正交”講的是線性無關，非常重要，就像一個點(x,y)，在x軸的變化不會影響y，y軸的變化不會影響x，這就是正交。

“正交”威力巨大，(x,y)可以表達二維平面的所有的點，如果增加一個z軸，不但能表達三維空間中所有的點，並且每個軸都可以獨立變化。

如果能做出正交的設計，這個系統的開發和維護會非常舒服，以為可以放心大膽的修改其中一個方面兒不會影響其他。

設計模式一直強調的『發現變化並且封裝變化』其實就是這個意思。

抽象能力的訓練沒有捷徑，就是經驗的積累，勤于思考和學習。例如：學習Android的程式設計師可以思考下Android是怎麼對未知的，紛繁複雜的應用程式進行抽象的？為什麼有Activity、Service、BroadcastReceiver、ContentProvider這四大元件？

7.技術領導力

我在IBM學到的重要一課就是：要用技術的影響力來領導人，而不是威權和職位。

換句大白話來說，就是要能讓技術人員服你。有了技術影響力，你在團隊發出的聲音才會被傾聽，被尊重。

但是影響力不是很快就建成的，這是個漫長的過程：你解決了一個技術難題，你提出的方案被證明可行….

這樣的事情會一點一滴的積累起你在別人心目中的形象，建立你的個人品牌，最終大家會給你貼上一個標籤：大牛。