如何構建自己的知識體系

面試的時候，我會問面試者，你日常如何構建自己的知識體系，如何讓自己更高更快更強？多數工程師並沒有深入地思考過這個問題，基本上是零敲碎打，隨機性大，基本上是腳踩西瓜皮滑到哪裡算哪裡。
本著不能讓你白來一趟的精神，好為人師的我會娓娓道來：

第一階段 認真構建完整的知識體系

十幾年前我投身軟體行業的時候，光是講解資料庫原理、作業系統、TCP/IP、組網、演算法等等基礎知識的英文原版書摞起來就等身，認認真真看完，各種上手實踐，入行後，讀遍 C++各種經典著作，讀遍各種協議原文，認認真真打基礎。
很多工程師都說自己平常就是在某些 IT 門戶上看看推薦的博文或新聞，我說這屬於典型的零敲碎打，不夠刺激。
聊到這時，我會舉一個例子，為什麼要閱讀長篇小說，因為中短篇小說就像用針扎你，而長篇小說就像把你裝進一個沙袋裡吊起來，從四面八方用狼牙棒打你，酣暢淋漓。構建可用的知識體系，就得讀書，書是有體系結構的，你關心不關心，現階段你用到用不到，它都講到了，從頭到尾看幾遍，針扎得透透的。

何謂知識體系？
幾年前，前支付寶架構師姚建東曾經在我們公司做過技術人員如何規劃自己的分享講座，他是這麼論述的：
技術與技巧包括：

計算機基礎理論
計算機模型：記憶體/IO/時鐘/CPU……
演算法
專項技術領域：
資料探勘
資料管理
智慧推薦
搜尋
……
語言與工具
語言與相關體系
開發工具，分析工具，程式碼管理工具
HTML/CSS/JS/Ajax
常用框架與第三方類庫
除錯與測試
除錯方法和哲學
定位問題
BUG管理工具
單元測試
整合測試
效能測試
安全測試
相容性測試與方法
JS/Ajax測試與方法
服務層測試
Web層測試
網路與系統
TCP/IP協議與模型，HTTP/SMTP等協議
Linux系統，網路分析工具，系統分析工具
容量，流量與負載均衡
應用部署、規範、規劃
安全
監控與故障分析
磁碟與儲存
Shell
DNS與域名
快取，反向代理
圖片伺服器（海量小檔案）
需求挖掘與分析
需求文件格式
需求訪談
需求分析方法，需求分析工具
領域知識與經驗
系統分析與設計
UML語言與模型
分析模式
設計模式，領域驅動
系統分析文件格式
系統設計文件格式
功能性需求與非功能性需求
資料與系統
資料庫
可伸縮策略，擴充套件策略，備份，容災，效能，安全，高可用……
資料設計與正規化，SQL/NoSQL，Cache，分散式檔案
架構設計
架構模式，典型網際網路公司架構演進歷史
架構原則，常用策略
架構設計方法
非功能性理解
擴充套件性
伸縮性
穩定性
一致性
效能
吞吐量
容量預測與規劃
架構體系與相關技術
過程與管理
分析過程
研發過程
評審過程
測試過程
釋出過程
回滾過程
文件管理
知識管理
專案管理
以上其實就是一份從業基礎知識清單，你可以按圖索驥，閱讀相關書籍。

第二階段 順著一個Topic鑽進去，鍛鍊自己的預研能力

無論公司業務還是自己喜歡做的事，都可以抽象出通用性課題，然後以做論文的方式殺進去。這個事情得反覆操練，有意識操練。
做事方式為：

抽象出 Topic——如分散式鎖，分散式平行計算引擎，防CSRF的FormToken自動生成框架，定時任務管理與排程平臺，分散式跟蹤，等等
向功課好的學生學習——有針對性地深入瞭解業界其他公司是如何分析問題和解決問題的，彙總各種方案，站在巨人的肩膀上
分析特定應用場景，技術選型
兼顧高可用性和可伸縮，做設計評審
做測試自證靠譜，梳理知識點，開技術分享會
上線商用，總結經驗教訓，開經驗分享會
其中一個重點是彙總和分享。05年時，應電信級統一訊息業務需要，我去研究了 SIP 協議，做了各種試驗，分析報文，寫了一系列的幻燈片，做了公開分享，一時間還頗受歡迎：

SIP_to_Freshman_by_zhengyun.ppt
SIP之穿越NAT_by_zhengyun.ppt
SIP體系架構講義及訊息互動演示_by_zhengyun.ppt
SIP多方會話訊息之例項講解_by_zhengyun.ppt
SIP安全框架之認證[NTLM和Kerberos]_by_zhengyun.ppt
SIP訊息之逐項講解_by_zhengyun.ppt
為什麼要寫出來、講出來呢？因為有一個學習金字塔理論，如下圖所示：

我們讀過的事情能夠記住學習內容的10%，
我們聽過的事情能夠記住20%，
我們看過的事情能夠記住30%，
我們聽過和看過的事情能夠記住50%——如看影像/看展覽/看演示/現場觀摩，
我們說過的事情能夠記住70%——如參與討論/發言，
我們說過和做過的事情能夠記住90%——如做報告，給別人講，親身體驗，動手做。
這也就是我在《窩窩研發過去幾年做對了哪些事》中闡述的管理方法：我們從入職之後就有意識地訓練大家，讓大家能夠公開陳述、清晰表達。所以，試用期內，新人必須做一次技術分享和一次技術評審，面對各方的 challenge；預研的中間和結尾都要有分享會；平時也要定期組織技術講座。

第三階段 瘋狂回答技術問題

知識體系慢慢構建，與業務相關的抽象 Topic 也在探索中。
但這還不夠。
因為你親身接觸到的世界太小，可能不足以構成挑戰，你可能意識不到自己缺多少知識和技能，不利於你分析問題、提出問題和解決問題的能力培養。
所以，要主動出擊：
瘋狂回答問題。

我曾經在入行的頭幾年裡幾乎把我關注的垂直領域（包括語言領域和業務領域）裡的所有問題都回答了一遍。我對外宣揚知無不言言無不盡，放出郵件地址和 MSN（那時候 MSN 很高大上），很多網友都會發郵件或者加我好友，問各種開發疑難問題，平均每天都有幾個，然後我把解決問題的過程寫成微軟 KB（KnowledgeBase） 文體發表在我的部落格上。
你想想看，工作中的問題你平均每隔幾天才能遇到一個，而這麼做，每天你都會遇到幾個乃至於十幾個，第一讓你腦力激盪，第二接觸到更多新知。

05年到06年期間，我因工作需要學習了 JavaME（或古老的稱呼 J2ME），早年間 Symbian 手機上的客戶端開發。那段時間我天天掃中文論壇的帖子，力求回答所有問題，尤其是那些BUG 或故障。對於那些暫時沒有人解決的，如流媒體實時播放，如仿 OperaMini 二級選單介面，都上下求索，最後放出思路以及原始碼。
同時，我經常整理常見問題，梳理成冊併發布。譬如我整理過的 J2ME 疑難問題：

[J2ME Q&A]真機報告MontyThread -n的錯誤之解釋
[J2MEQ&A]WTK初始化WMAClient報錯XXX has no IP address的解釋
[J2ME Q&A]untrusted domain is not configured問題回應
[J2ME]“Cannot open socket for LIME events”錯誤解決
幾個月後，我成為 J2ME 中文論壇超級版主。通過這個歷程，我想告訴大家，回答網友問題，技巧得當的話，比如別老是重複回答新手問題，試著攻克那些疑難問題，或者離奇故障，絕對不會浪費你的時間。為什麼？
因為你要信奉：

你學過的每一樣東西，你遭受的每一次苦難，都會在你一生中的某個時候派上用場。
——佩內洛普·菲茲傑拉德 《離岸》

Everything that you`ve learnt and all the hardships you`ve suffered will all come in handy at some point in your life.

第四階段 RCA/總結

現在是你把經驗教訓變為財富的時刻了。
什麼是好的技術 Leader？
隨便一個業務需求或業務場景講出來，你立刻把它抽象為幾個模組/系統/Topic，然後侃侃而談，業界都是怎麼解決的，我們以前又是怎麼分析怎麼解決的，現在我們們這種情況下應該如何設計，可能會遇到什麼問題，我們應該做哪些預防設計，blabla。

怎麼做到這一點？
第一，寫 RCA 報告。
我以前說過，『窩窩從 2011 年開始，一直堅持每錯必查、錯了又錯就整改、每錯必寫，用身體力行告訴每一個新員工直面錯誤、公開技術細節、分享給所有人，長此以往，每一次事故和線上漏測都會變為我們的財富。這就是我們的 RCA（Root Cause Analysis）制度，截止到目前已經收集整理了近兩百個詳盡的 RCA 報告。』
RCA 報告格式為：

背景知識（Optional）
問題現象
影響範圍
問題原因
問題分析過程（Optional）
解決辦法
後續處理措施：如線上髒資料如何修復，如對使用者造成的影響如何彌補等（Optional）
經驗教訓
RCA型別：如程式碼問題、實施問題、配置問題、設計問題、測試問題
這樣，作為一名合格的老兵，你見過了足夠多的血，並且把它們變成了你的人生財富。第二，寫總結。
話說，要經常拉清單。
侃侃而談得有資料，這些都得是你自己寫才能印象深刻，關鍵時刻想得起來。