如何從菜鳥程式員成長為(僞)高手

1.摘要

最近有一些畢業不久的同僚問我：“你工作的時候有沒有什麼竅門？怎麼才能快速成為高手？”

想起當初剛入職，新人教育訓練的時候，也跟其他同僚讨論過這個問題：如何才能成為業界大牛？當時自己隻是覺得興趣是最好的老師，思路方法什麼的沒有多想。

加入微網誌平台架構部的時間也不短了，趁着快過春節總結了一下自己入職微網誌以來的工作情況，從網際網路開發的半個門外漢，到如今能設計一些架構、排查一些問題、分享一些經驗，收獲頗多，感想頗多,也逐漸意識到思路和方法的重要性，在此跟大家分享一下。主要分為學、做、想三方面。

2.學會學習

學習無疑是程式員最為重要的素質之一，尤其是網際網路這種日新月異的行業，把學習當做工作的一大半也不為過。

2.1.自主學習

最近發現身邊的人并不是不想學習，隻是每天都在糾結自己到底學什麼好：簡單的沒挑戰，複雜的看不懂；舊技術怕過時，新技術沒方向……

講講自己畢業後的經曆，畢業之後去了個不大不小的公司，工作主要是做一些XX管理系統之類的東西，沒什麼挑戰，也用不上什麼技術，基本上前端用個extjs後面套個sql server就解決了。工作穩定了幾年，業餘時間除了wow沒别的事情做，覺得這麼閑下去不是辦法，于是之後一年的時間裡，用上班摸魚和下班休息的時間學了這些東西：

• 閑着無聊想做個小遊戲，發現遊戲相關的書大多是英文的，看不懂，一咬牙翻譯了《Real-time rending 3rd》的前幾章，剛開始前言都看不懂，隻能一個詞一個詞的翻字典，一句話要琢磨幾個鐘頭到底作者說的到底是什麼意思。翻譯了幾百頁英文書之後，發現自己看英文書沒什麼障礙了，于是開始每天用休息和摸魚的時間看書。
• 看完遊戲引擎的書之後，把irrlicht引擎的代碼看了一遍，然後自己山寨了一個3d渲染的場景管理器，還有個樸素的渲染引擎。
• 給自己的遊戲引擎寫了個基于腳本語言的解釋器，為此看了不少編譯原理和虛拟機的書，了解了程式究竟是什麼東西，這是我覺得收益很大的一件事情。
• 看編譯原理的書的時候發現作業系統的知識有些欠缺，又去看了linux核心相關的書。之後買了個開發闆天天修改核心玩，畢業以後又一次了解了核心的cpu排程、記憶體管理和檔案系統，了解了應用是怎麼跑在作業系統上，作業系統又是怎麼運作在硬體上的，這也是收益很大的一件事情。
• 看完作業系統又順着看網絡相關的書，之後把lighthttpd的代碼看了一遍，用c寫了個linux下的http伺服器，把幾種網絡程式設計模型挨個實作了一遍。
• 實作http伺服器的過程中覺得自己編碼能力還是有欠缺，把代碼大全翻了一遍，順着又去看了設計模式的書，并且用自己的了解把每個模式用文字重新描述了一遍。
• 中間還看了很多語言和架構相關的書，就不一一列舉了。可以參考這裡。

我把學習的方向分為三類：

1. 為了工作，滿足目前工作所必備的知識
2. 為了提升，與目前工作相關的知識（深度）
3. 拓展視野，與目前工作無關的知識（廣度）

學習（1）之後隻是個熟練工，2和3才是提升自己的途徑，伴随着知識儲備的提升，接觸新事物時更容易找到相似的知識加以類比，加快了解，也更容易掌握本質。如果每天都在糾結“到底學什麼”，那麼隻能說明還是學的太少了。（真正沒什麼可學的大牛們應該不會讀到這裡吧……）

是以，如果覺着沒什麼東西可以學的時候，那麼可以考慮一下學一下更有深度的知識（比如虛拟機或編譯器），或者完全不同的知識（新的語言或目前比較火的方向），甚至完全不相幹的知識（單純練習英文閱讀，學習ppt排版之類）吧。随着知識儲備增加，自己的不足和未來的學習的方向也會更加明确起來。

2.2.向曆史學習

以微網誌為例，在微網誌發展的過程中經曆了不少波折，并逐漸衍生出了目前的系統架構。很多新人最喜歡問的問題便是“現線上上是怎麼做的？”

這個問題不錯，但是還不夠好。在程式員的世界裡罕有能解決所有問題的“銀彈”，目前的做法用不了多久也會被替換掉，如果想了解一件事情，那麼就多關注一下“它是怎麼變成今天這樣的”吧。學會用發展的眼光看問題，了解一些經曆過的經驗教訓，收獲會比單純學會一件什麼事情多的多。

那麼，如何向曆史學習？

• 公司内部的資料庫、wiki等大都會有舊時的資料，剛入職時大多不會太忙，這些資料庫簡直是挖不完的寶藏
• 部門内部分享，比如我當初入職時經常去聽“微網誌XXXX架構演化曆程”之類的内部分享
• 多問一下自己”它為什麼不那麼設計“
• 老員工憶苦思甜吹牛逼的時候多奉承幾句_(:з」 ∠)_

2.3.向他人學習

這裡有兩個極端，

• 有的人喜歡自己悶頭搗鼓，什麼也不問，這必然是不利于自己提高的；
• 也有人碰到問題就問，這也有問題，浪費他人時間不說，更關鍵的是說明這人向他人學習的思路錯了，要學習他人的并不是具體某個知識（要學知識看書就能解決了），而是學習别人的思維方式。

但是思維方式這種東西很難通過交流的方式學到，後來我發現有個很簡單的學習方式：口頭禅。舉幾個例子，大家體會一下：

“這個其實是兩個問題”

“有沒有更好的方案”

“能不能舉個例子”

“能不能給個一句話總結”

除了口頭禅，很多牛人都會有非常鮮明的思維方式和處事原則，如果有幸與業界的大牛共事，那麼恭喜你，隻要多交流、多觀察、多思考，那麼提升速度會提升好幾個數量級。

3.多做有意義的事情

有的人每天時間浪費在跟問題本身無關的事情上，比如我要設計架構的時候還要考慮架構圖怎麼畫，寫完代碼還要反複部署測試好幾輪才pass，查bug的時候把時間浪費在掃日志上。人的精力總是有限的，把時間浪費在這些事情上面，讓自己提高的時間就變得少了。

3.1.練習，更多的練習

這裡有個誤區：“做有意義的事情”不等于“隻做自己沒做過的事情”。

對于程式員來說，寫代碼是基本功中的基本功，編碼的規範、設計的權衡、甚至順手的IDE快捷鍵都要靠平日的試錯和積累，很難通過幾本書或者幾天教育訓練領悟到。

曾經目睹一些人寫代碼一年之後開始做一些小項目的設計，然後就迫不及待的把重心全都轉移到設計甚至架構上，這種沒有基礎能力支撐做出的設計和架構最多隻能算是進階意淫，大多沒等落地就荒廢了，意義不大。究其原因，大多是設計出來的東西“不好做”或者“不好用”，就像是隻看過一遍課本就去參加高數考試，現實嗎？（學霸們我錯了……）

舉個例子，幾年前在看設計模式的過程中，用qt做了個看漫畫的應用，把能用的模式都試了一遍，當然有很多用的不合适的地方，正是這些不合适的地方讓我對面向對象程式設計和設計模式的思考深入了很多，如何權衡靈活性和複雜性也有了新的認識。之後在設計很多系統的時候少走了很多彎路，既保證了時間點又保證了品質。如果當時指望着“用的時候再說”，大概已經被項目坑的不能自理了。

3.2.善用工具

工具能解決的事情就用工具去解決，好的工具能節約大把的時間用在更有意義的事情上。

工具的範疇很廣，比如linux的各種指令、比如團隊内部的各種系統、比如順手的應用、甚至包括上下班騎的自行車。隻要能節約時間、提高效率，那就值得一試。

在這裡我列舉幾個大幅度提升了我的效率的東西：

• 雙屏顯示器
• 順手的鍵盤
• google（不是baidu！不是bing！）
• mac
• mac上的應用：idea、alfread、omnifocus、甚至synergy和istats menus之類跟開發本身關系不大的應用。

我更傾向于把“使用工具”作為一種生活态度：是否希望讓自己的生活專注于有意義的事情。如果你認同這個觀點，那麼想一想投入和回報比例，還是很可觀的。

（當然，為了不花錢而自己破解應用的大神也是極叼的……）

3.3.提高時間的使用率

時間是所有期待提升自己的人最寶貴的資源，效率再高，沒時間做也沒意義。

網上有個流傳挺廣的圖：打擾程式員的成本。事實上我每天的工作時間非常碎片化，來到公司之後可能不斷的接電話、被問問題、被拉去開會、回複郵件等等；也經常會有時間不夠用或者沒事做的困惑，這裡分享一下心得：

• GTD可以整合很多碎片時間。除了把事做完之外，把上下文相關的事情集中在一起完成也很有幫助。比如把幾件想去其他辦公室做的事情整合成一趟完成。
• 減少無意義的時間浪費，比如家住在公司邊上可以每天節省幾個小時的時間用來學習或者做别的事情。（但如果節省下來的時間用來刷微網誌，那就沒有必要了。）
  • 另外一個很有趣的現象：一個軟體的注冊費就10幾刀，貴些的幾百刀，把日常用到的所有工具的費用全加起來都頂不上一個腎6貴，但是很多人還是堅持着沒有破解不用的觀念，為了幾百塊錢浪費了大把時間。
• 加班可以創造很多時間，并且能有效減少被打擾的幾率，但是也會給身體和精神帶來很大負擔。是以加班做的事情必須能對個人進步産生足夠多的收益。如果加班隻是用來處理無意義的工作的話，那應該是日常工作出了什麼問題。
• 事情可以分成緊急重要、緊急不重要、重要不緊急、不重要不緊急四類，在todo清單裡随時要有重要不緊急的事情。

4.學會思考

4.1.深究

當有什麼問題解決不了的時候，很多人會有畏難或者拖延的情緒，典型口頭禅就是“就這麼湊合着用吧”或者“先這樣吧，以後有時間再研究”，說這些話的人大多并不是真的那麼忙，甚至有人一邊刷着微網誌一邊跟我說沒時間研究……(你tm在逗我？)

要克服畏難情緒其實很簡單，找一個具體的似懂非懂的問題，想盡辦法把問題研究清楚，體會幾次解決問題時的愉悅感，建立自信。

大部分問題其實沒有什麼高深的科學原理，甚至隻要翻幾頁書就解決了，但是遇到問題不深究，久而久之會形成自我暗示：這些問題是我懂的，那些是我不懂的，自己反而把自己進步的路給堵上了。

說到如何深究，也有幾條心得：

• 遇事多想為什麼，并且要反複問為什麼。很多貌似了解了的問題過一陣再重新想想，往往會發現之前還有沒考慮到的地方
• 問題要有明确答案，哲學之類的就别糾結了
• 查找資料時選權威的書籍或者網站，避免被誤導
• 找人讨論，或者直接拉小夥伴入夥，既可以互相交流，又可以互相監督
• 分享你的成果
• 不要所有事情全都深究，會給自己太多壓力

4.2.多說，多寫，多交流

平常工作中有一個感受，有交流和寫作習慣的人思路會更清晰一些，能接觸到的觀點也會多一些。這方面其實屬于我的弱項，大概總結幾個觀點。

• 隔一段時間最好能書面形式總結一下最近的工作，比如說寫個心得感悟，或者持續更新自己的履歷
• 寫作的時候有兩個難點：對要說明的事情做總結和抽象，形成觀點統一、調理清晰的主線；從對方的視角考慮，把事情說明白，避免自言自語。
• 找人讨論之前自己先要有個基本完整的思路，否則大部分的時間都要耗在解釋原理之類的上網查反而更快的事情上。
• 讨論之後要有一句話就能說明白的結論和描述清晰的時間點。
• 有些人喜歡糾結于“這個不是我的問題，為什麼要我處理”之類的事情。在我看來這是很好的機會。既能增長見識，又能展示水準，還能留個認真負責的好名聲，何樂而不為呢。

5.最後

最後分享一下關于我了解的程式員的自我修養，在我看來，可以總結為：負責任，重名聲。

負責任，說的更具體些：寫的代碼自己有沒有測過、做的架構自己有沒有用過、設計的架構自己有沒有認真權衡過。