閱讀源代碼的能力算是程序員的一種底層基礎能力之一，這個能力之所以重要，原因在於：
- 不可避免的需要閱讀或者接手他人的項目。比如調研一個開源項目，比如接手一個其他人的項目。
- 閱讀優秀的項目源碼是學習他人優秀經驗的重要途徑之一，這一點我自己深有體會。
讀代碼與寫代碼是兩個不太一樣的技能，原因在於“寫代碼是在表達自己,讀代碼是在理解別人”。因為面對的項目多，項目的作者有各自的風格，理解起來需要花費不少的精力。
我從業這些年泛讀、精讀過的項目源碼不算少了，陸陸續續的也寫了一些代碼分析的文章，本文中就簡單總結一下我的方法。
先跑起來
開始閱讀一份項目源碼的第一步，是先讓這個項目能夠通過你自己編譯通過並且順利跑起來。這一點尤其重要。
有的項目比較復雜，依賴的組件多，搭建起一個調試環境並不容易，所以並不見得是所有項目都能順利的跑起來。如果能自己編譯跑起來，那么后面講到的情景分析、加上調試代碼、調試等等才有展開的基礎。
就我的經驗而言，一個項目代碼，是否能順利的搭建調試環境，效率大不一樣。
跑起來之后，又要盡量的精簡自己的環境，減少調試過程中的干擾信息。比如，Nginx 使用多進程的方式處理請求，為了調試跟蹤 Nginx 的行為，我經常把 worker 數量設置為1個，這樣調試的時候就知道待跟蹤的是哪個進程了。
再比如，很多項目默認是會帶上編譯優化選項或者去掉調試信息的，這樣在調試的時候可能會有困擾，這時候我會修改 makefile 編譯成 -O0 -g，即編譯生成帶上調試信息且不進行優化的版本。
總而言之，跑起來之后的調試效率能提升很多，而在跑起來的前提之下又要盡量精簡環境排除干擾的因素。
明確自己的目的
盡管閱讀項目源碼很重要，但是並不見得所有項目都需要從頭到尾看的清清楚楚。在開始展開閱讀之前，需要明確自己的目的：是需要了解其中一個模塊的實現，還是需要了解這個框架的大體結構，還是需要具體熟悉其中的一個算法的實現，等等。
比如，很多人看 Nginx 的代碼，而這個項目有很多模塊，包括基礎的核心模塊（ epoll 、網絡收發、內存池等）和擴展具體某個功能的模塊，並不是所有這些模塊都需要了解的非常清楚，我在閱讀 Nginx 代碼的過程中，主要涉及了以下方面：
- 了解 Nginx 核心的基礎流程以及數據結構。
- 了解 Nginx 如何實現一個模塊。有了這些對這個項目大體的了解，剩下的就是遇到具體的問題查看具體的代碼實現了。
總而言之，並不建議毫無目的的就開始展開一個項目的代碼閱讀，無頭蒼蠅式的亂看只會消耗自己的時間和熱情。
區分主線和支線劇情
有了前面明確的閱讀目的，就能在閱讀過程中區分開主線和支線劇情了。比如：
想了解一個業務邏輯的實現流程，在某個函數中使用一個字典來保存數據，在這里，“字典這個數據結構是如何實現的”就屬於支線劇情，並不需要深究其實現。
在這一原則的指導下，對於支線劇情的代碼，比如一個不需要了解其實現的類，讀者只需要了解其對外接口，了解這些接口的入口、出口參數以及作用，把這部分當成一個“黑盒”即可。
順便一提的是，早年間看到一種 C++ 的寫法，頭文件中只有一個類的對外接口聲明，將實現通過內部的 impl 類轉移到 C++ 文件中，比如：
頭文件：
// test.h
class Test {
public:
void fun();
private:
class Impl;
Impl *impl_;
};
C++文件：
void Test::fun() {
impl_->fun()
}
class Test::Impl {
public:
void fun() {
// 具體的實現
}
}
這樣的寫法，讓頭文件清爽了很多：頭文件中沒有與實現相關的私有成員、私有函數，只有對外暴露的接口，使用者一目了然就能知道這個類對外提供的功能。
“主線”和“支線”劇情在整個代碼閱讀的過程中經常切換，需要閱讀者有一定的經驗，清楚自己在這段代碼的閱讀中哪部分屬於主線劇情。
縱向和橫向
代碼閱讀過程中，分為兩個不同的方向：
- 縱向：順着代碼的順序閱讀，在需要具體了解一個流程、算法的時候，經常需要縱向閱讀。
- 橫向：區分不同的模塊進行閱讀，在需要首先弄清楚整體框架時，經常需要橫向閱讀。
兩個方向的閱讀，應該交替進行，這需要代碼閱讀者有一定的經驗，能夠把握當前代碼閱讀的方向。我的建議是：過程中還是以整體為首，在不理解整體的前提之前，不要太過深入某個細節。把某個函數、數據結構當成一個黑盒，知道它們的輸入、輸出就好，只要不影響整體的理解就暫且放下接着往前看。
情景分析
假如有了前面的基礎，已經能夠讓項目順利在自己的調試環境跑起來了，也明確了自己想了解的功能，那么就可以對項目代碼進行情景分析了。
所謂的“情景分析”，就是自己構造一些情景，然后通過加斷點、調試語句等分析在這些場景下的行為。
以我自己為例，在寫 《 Lua 設計與實現》 時，講解到Lua虛擬機指令的解釋和執行過程中，需要針對每個指令做分析，此時用的就是情景分析的方法。我會模擬出來使用該指令的 Lua 腳本代碼，然后在程序里斷點調試這些場景下的行為。
我慣用的做法，是在某個重要的入口函數上面加上斷點，然后構造觸發場景的調試代碼，當代碼在斷點處停下，通過查看堆棧、變量值等等來觀察代碼的行為。
例如，Lua 解釋器代碼中中，生成 Opcode 最終都會調用函數 luaK_code，那么我就在這個函數上面加上斷點，然后構造我想要調試的場景，只要在斷點處中斷，我通過函數堆棧就能看到完整的調用流程：
(lldb) bt
* thread #1: tid = 0xb1dd2, 0x00000001000071b0 lua`luaK_code, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
* frame #0: 0x00000001000071b0 lua`luaK_code
frame #1: 0x000000010000753e lua`discharge2reg + 238
frame #2: 0x000000010000588f lua`exp2reg + 31
frame #3: 0x000000010000f15b lua`statement + 3131
frame #4: 0x000000010000e0b6 lua`luaY_parser + 182
frame #5: 0x0000000100009de9 lua`f_parser + 89
frame #6: 0x0000000100008ba5 lua`luaD_rawrunprotected + 85
frame #7: 0x0000000100009bf4 lua`luaD_pcall + 68
frame #8: 0x0000000100009d65 lua`luaD_protectedparser + 69
frame #9: 0x00000001000047e1 lua`lua_load + 65
frame #10: 0x0000000100018071 lua`luaL_loadfile + 433
frame #11: 0x0000000100000eb9 lua`pmain + 1545
frame #12: 0x00000001000090cd lua`luaD_precall + 589
frame #13: 0x00000001000098c1 lua`luaD_call + 81
frame #14: 0x0000000100008ba5 lua`luaD_rawrunprotected + 85
frame #15: 0x0000000100009bf4 lua`luaD_pcall + 68
frame #16: 0x00000001000046fb lua`lua_cpcall + 43
frame #17: 0x00000001000007af lua`main + 63
frame #18: 0x00007fff6468708d libdyld.dylib`start + 1
情景分析的好處在於：不會在一個項目中大海撈針似的查找，而是能夠把問題縮小到一個范圍內展開來理解。
“情景分析”這一概念不是我想出來的名詞，比如有這么幾本分析代碼的書籍，如： 《Linux內核源代碼情景分析》，《Windows內核情景分析》。
利用好測試用例
好的項目都會自帶不少用例，這類型的例子有：etcd、google 出品的幾個開源項目。
如果測試用例寫的很仔細，那么很值得好好去研究一下。原因在於：測試用例往往是針對某個單一的場景，獨自構造出一些數據來對程序的流程進行驗證。所以，其實跟前面的“情景分析”一樣，都是讓你從大的項目轉而關注具體某個場景的手段之一。
厘清核心數據結構之間的關系
雖然說“程序設計=算法+數據結構”，然后我實際中的體會，數據結構更加重要。
因為結構定義了一個程序的架構，結構定下來了才有具體的實現。好比蓋房子，數據結構就是房子的框架結構，如果一間房子很大，而你並不清楚這個房子的結構，會在這里面迷路。而對於算法，如果屬於暫時不需要深究的細節部分，可以參考前面“區分主線和支線劇情”部分，先了解其入口、出口參數以及作用即可。
Linus 說：“爛程序員關心的是代碼。好程序員關心的是數據結構和它們之間的關系。”
因此，在閱讀一份代碼時，厘清核心的數據結構之間的關系尤其重要。這個時候，需要使用一些工具來畫一下這些結構之間的關系，我的源碼分析類博客中有很多這樣的例子，比如 《Leveldb代碼閱讀筆記》、《Etcd存儲的實現》 等等。
需要說明的是，情景分析、厘清核心數據結構這兩步並沒有嚴格的順序關系，不見得是先做某事再做某事，而是交互進行的。
比如，你如果現在剛接手某個項目，需要簡單的了解一下項目，可以先閱讀代碼了解都有哪些核心數據結構。理解了之后，如果不清楚某些情景下的流程，可以使用情景分析法。總而言之，交替進行直到解答你的疑問為止。
多問自己幾個問題
學習的過程中離不開交互。
如果閱讀代碼只是輸入 （Input），那么還需要有輸出 （Output）。只有簡單的輸入好比喂東西給你吃，而只有更好的消化才能變為自己的營養，而輸出就是更好消化知識的重要手段。
其實這個思想很常見，比如學生上課 （Input） 了需要做練習作業 （Output），比如學了算法 （Input） 需要自己編碼練習 （Output），等等。簡而言之，輸出是學習過程中的一種及時反饋，質量越高學習效率越高。
輸出的手段有很多，在閱讀代碼時，比較建議的是自己能夠多問自己一些問題，比如：
- 為什么選擇這個數據結構來描述這個問題？類似的場景下，其他項目是怎么設計的？都有哪些數據結構做這樣的事 ？
- 如果由我來設計這樣的項目，我會怎么做？
等等等等。越是主動積極的思考，就越有更好的輸出，輸出質量與學習質量成正比關系。
寫自己的代碼閱讀筆記
我從開始寫博客，就是寫不少各種項目的代碼解讀類文章，網名 “codedump” 也源於想把 code 內部的實現原理 dump 出來”之意。
前面提到學習質量與輸出質量成正比關系，這是我自己的深刻體會。也因為如此，所以才要堅持閱讀源碼之后寫自己的分析類筆記。
寫這類筆記，有以下幾個需要注意的地方。
雖然是筆記，但是要想象着在向一個不太熟悉這個項目的人講解原理，或者想象一下是幾個月甚至幾年后的自己回頭來看這個文章。在這種情況下，會盡量的把語言組織好，循循善誘的解釋。
盡量避免大段的貼代碼。我認為在這類文章中，大段貼上代碼有點自欺欺人：就是看上去自己懂了，其實並不見得。如果真要解釋某段代碼，可以使用偽代碼或者縮減代碼的方式。記住：不要自欺欺人，要真的懂了。如果真的想在代碼上加上自己的注釋，我有一個建議是 fork 出來一份該項目某個版本的代碼，提交到自己的github上，上面隨時可以加上自己的注釋並且保存提交。比如我自己注釋的 etcd 3.1.10 代碼： etcd-3.1.10-codedump，類似的我閱讀的其他項目都會在 github 上 fork 出一個帶上 codedump 后綴的項目。
多畫圖，一圖勝千言，使用圖形展示代碼流程、數據結構之間的關系。我最近才發現畫圖能力也是很重要的能力，自己在從頭學習如何使用圖像來表達自己的想法。
寫作是很重要的基礎能力，我一個朋友最近教育我，大體的意思是說：如果你在某方面的能力很強，如果再加上寫作好、英語好，那么將極大放大你在這方面的能力。而類似寫作、英語這樣的底層基礎能力，不是一撮而就的，需要長時間保持練習才可以。而寫博客，對於技術人員而言，就是一種很好的鍛煉寫作的手段。
PS：如果很多事情，你當時做的時候能想到今后面對這個輸出的人是你自己，比如自己寫的代碼后面要自己維護、自己寫的文章后面給自己看，等等的，世界會美好很多。比如寫技術博客這些事情，因為我在寫的時候考慮到以后看這份文檔的人可能就是我本人，所以在寫的時候會盡量的清晰、易懂，力圖我自己一段時間后再看到自己的這份文檔時，能夠馬上回憶起當時的細節，也正是因為這樣，我很少在博客里貼大段的代碼，盡可能的補充圖例。
總結
以上是我簡單總結的一些閱讀源碼時候的手段和注意方法，大體而言有那么幾點吧：
- 只有更好的輸出才能更好的消化知識，所謂的搭建調試環境、情景分析、多問自己問題、寫代碼閱讀筆記等都是圍繞輸出來展開的。總而言之，不能像一條死魚一樣指望着光靠看代碼就能完全理解它的原理，需要想辦法跟它互動起來。
- 寫作是人的基礎硬實力之一，不僅鍛煉自己表達能力，還能幫助整理自己的思路。對程序員而言鍛煉寫作能力的手段之一就是寫博客，越早開始鍛煉越好。
最后，如同任何可以習得的技能一般，閱讀代碼這種能力也需要長時間、大量的反復練習，下一次就從自己感興趣的項目開始鍛煉自己的這種技能吧。
作者：codedump
來源：https://www.codedump.info/post/20200605-how-to-read-code-v2020/
更多精彩好文請掃碼關注我們微信公眾號，新鮮資訊不迷路~
