高效閱讀源代碼指南

最近一年裏，我閱讀了很多開源項目的源代碼，以前也和朋友討論過閱讀源代碼時遇到的一些問題。我以爲有必要寫一篇博文分享一下本身的經驗。

序章：準備工做

一般狀況下，咱們不會平白無故拿到一份源代碼，我是說，當想要閱讀源代碼時，必定是抱着某種目的進行下去的，這個目的會貫穿整個研究過程，好比：

• 想研究某個東西的實現
• 想學習做者的代碼風格和項目組織
• 想參考實現並用其餘語言移植項目

等等。因此在最初的時候，明確本身閱讀源代碼的目的很是關鍵。

在明確了目的以後，就能夠正式開始深挖代碼了。不過在此以前，仍是要提醒一下：工欲善其事，必先利其器。

能夠用來寫代碼的工具備不少，如包括Vim、Emacs、SublimeText、Atom等在內的Text Editor，還有包括Visual Studio和JetBrains全家桶在內的IDE。Text Editor在編寫代碼時有無與倫比的優點，方便的快捷鍵、一流的檢討速度、高度可配置的編輯環境等等，無疑能極大程度上提升程序員的手速，然而這些亮點都不是在閱讀代碼時候所必須的；閱讀代碼時，不少時候須要搞清楚函數之間的調用關係，這時候就須要有強大的代碼靜態分析工具和一個便捷的斷點調試工具，這也正是IDE的優點。

所以我鄭重推薦在閱讀代碼時使用IDE，固然若是是較小的項目加之已經調教成IDE的Vim/Emacs，也是沒什麼問題的。

接下來，就真的能夠開始深挖代碼了。

第一步：自頂向下理清代碼組織關係

代碼組織結構

不少時候這一點根本就不是問題，由於項目的構建無非是經過構建工具、框架或最佳實踐來作的，實在不行還能夠查閱開發文檔。

Code Breakdown Structure

這是我認爲最重要的一個步驟，然而我也吃驚地發現，並非每一個人都能重視這個步驟並處理得很好。

所謂Code Breakdown Structure的說法，自己源自軟件工程中Work Breakdown Structure。WBS把軟件需求按照業務的角度逐級下分，而這份產物可以直接影響到項目代碼裏的數據模型。

固然，項目代碼裏的結構，不只僅受到了實際需求的影響，也受到了構建工具和設計模式的影響，好比可以應用在全局的MVC模式，或者應用在局部場景的單例模式、狀態模式等等，更會受到程序語言相關層面的直接影響；但不管是怎樣的軟件模式、怎樣的編程範式，閱讀源代碼時仍舊須要搞清楚不一樣的代碼組織在整個項目裏的角色是什麼，須要分別知道數據層、工具函數、頂層抽象、抽象實現和具體的功能性代碼分別是什麼、在哪裏。在整理這部份內容的時候，一般會在腦海中造成清晰的思路，但若是能夠的話，請把這些東西用紙筆畫出來。

若是想要研究的是具體的功能實現，就須要在上面的基礎上更進一步，着眼於功能性的代碼，對每一個功能實現畫出活動圖和時序圖。

總之這一步裏包含了不小的工做量，但搞清楚這些東西，是繼續進行下去的基礎。

第二步：有針對性地深挖代碼

這是閱讀代碼的核心步驟，是最複雜的一個步驟，也是我沒法在此篇文章中展開的步驟。由於每一個人閱讀代碼的目的不盡相同，每一個人研究問題的習慣也有很大差別。

研究問題的時候，一般會有大量本身改代碼、打斷點、作編譯的機會，請盡情享受解決本身目標問題的思惟過程，而且不要忘記如下重要的輔助資源：

• 開發文檔
• 開發日誌（Issues, Mails）
• 主要開發成員的博客（若是有的話）
• 相關領域的資料，包括書籍和論文
• 與同類開源項目產品的實現相比較
• 與原做者、開發組進行溝通：IRC、Maillist、Gitter等

第三步：自底向上理解局部代碼在全局中的重要性

不管是把眼光聚焦在對問題的解決方案上，仍是在代碼組織、設計模式上，能針對結果作進一步抽象，纔是最好的。

這裏面蘊含的機會是：

• 一旦理解了做者的解決方法，對本身理解這種解決方案自己和背後的業務模型都有提高。
• 一旦發現了更好的解決方案，本身就有機會提PR。

儘管要作好這一步，須要較強的領域技術背景，但若是能堅持嘗試這麼作的話，會受益不淺。

接下來的事情

閱讀完一份源代碼，找到了本身須要的東西，讓本身的能力獲得提高。接下來的事情固然是：

• 多運動，讓本身大腦放鬆一下
• 多陪陪父母妻兒(沒有妹子的話就去找)
• 閱讀下一份開源代碼