如何快速讀懂開源代碼？

---

從使用入手，模塊開發到源碼閱讀 以nginx為例

1 使用入手 ， 張宴 的 實戰Nginx

2 模塊開發 ， 陶輝 的 深入理解Nginx : 模塊開發與架構解析

3 源碼閱讀 ， 陶輝 的 深入理解Nginx : 模塊開發與架構解析

從低版本到高版本 以linux為例

1 linux0.1 趙炯 的 Linux內核完全注釋

2 linux2.6 毛德操 的 Linux內核源代碼情景分析（上冊）

3 linux3.0 最新版本代碼

從高層結構到模塊實現 或者從模塊實現到高層結構

1 Linux內核設計與實現

2 Linux內核設計與實現

按照代碼運行流程 以linux網路為例

1 Linux內核網路棧源代碼情景分析

最後一種 造輪子大法

誰用誰知道，也是最高效的，自己一步一步實現，然後對比源代碼實現。

---

無聊更新一發。

最近在重寫mongo的bson，看了mongo的代碼以後，以前在leveldb里看不懂的一個部分頓時豁然開朗(之後整理一篇小博客)。所以得到的經驗就是，如果一個項目的代碼看不懂，找不到官方文檔，也找不到網上對這個謎之模塊的源碼分析，那基本可以放棄了，除非你對自己的能力非常自信。

==========

整個大二都在讀源碼，剛開始跟題主描述的一樣，傻傻地每行讀。一開始讀redis的時候還每行抄，自己做注釋，讀libevent的時候也是。當然啦，這樣很不聰明。(現在libevent還沒讀完。。)

後來多讀書了，對一些技術有了深入的了解，就覺得以前的代碼突然變得開化了，可理解了。看muduo的時候就感覺很多東西沒必要細看，自己造個輪子就能體會到設計細節和編程的技巧。在看些google的小輪子，比如glog的時候，也看的快了許多。簡單的比如pimpl模式，如果不知道這個模式，就想不到為什麼要專門定義一個impl類，自然不知道類跟類之間是什麼關係了。

再後來寫lexer和parser的時候讀的是flex和bison的源碼。我依然naive，順便花功夫配了個vim，因為那個源碼用ide看不是很舒服。這時候我就破罐子破摔了，完全不追求全部看懂，大概看它的介面(因為英文不好，寫代碼的時候不會起名字)，和部分演算法的設計思路。甚至連原本敬而畏之的google/re2，也可以理解其中的一些技巧了。

其實你說怎麼能像大牛那樣讀源碼呢？我覺得就是打好基礎，多讀書，多寫代碼。

當然啦，我再過十年能成為大牛就謝天謝地了，不過還是要以之為目標去奮鬥。

---

為什麼人們都願意「重新造輪子」?一個重要的原因就是:讀別人的代碼比自己寫還難！

開源代碼不適合新手學習，除非是那種具有良好文檔的，而且深入淺出的優秀代碼。

但這幾乎是不可能的。因為：

1、文檔的寫作是很枯燥的；

2、開源代碼是免費的，其作者沒有義務為你解釋服務；

3、開源代碼更傾向於使用一些「複雜」的「新」技術，而不是樸實的保守的舊技術。

如果題主英語好，情況可能會好一點，因為有限的開源代碼文檔資料絕大部分都是英文的。

如果題主有興趣的話，我開源了兩個項目，正在進行中：英雄帖：開源項目招募英才。但不得不說，寫文檔真是件苦逼的事！

---

讀代碼和寫代碼一樣，你得先明確目標。漫無目的的讀代碼是不會有結果的，就如你自己都不知道寫什麼功能的情況下，能寫什麼代碼？

既然明確你想了解的具體功能，接下去就簡單了，你只要找到這個功能的切入點，按代碼順序讀下來就可以了，讀代碼的速度取決於你對整體代碼的熟悉程度，剛上手肯定會慢一點

整個過程中最關鍵的是找切入點，我看了很多新手程序員根本找不到他想看的功能該如何看起，那就需要一些技巧了，找一些不會變的關鍵api來作為索引的關鍵字，比如網路相關的肯定有recv，文件相關的也就是fread這樣的一系列函數。

---

先看代碼的整體結構，實現類，介面類，模型類，工具類區別開來。花10分鐘時間把每個文件大概看下。

之後跟著程序跑一次，從入口走，進入庫的核心實現類後觀察他實例化了哪些類，這些類分別都做了些什麼...

最後一層層滿滿的把源碼拆開閱讀，很快就能理解。一定要有耐心，有的源碼比較難懂，往往看了幾遍後還沒有頭緒，相信多讀繼續，每次肯定有新收穫

---

看得慢，看不懂，要嘛是看少了，要嘛是水平不夠。

沒捷徑，多看，努力提升理論水平。

熟讀唐詩三百首，多看豬跑。

對於沒多少經驗的新手，建議從兩個角度讀，全局或者局部。

了解全局的時候，關注執行流程、層次、調用之類的，對細節不求甚解，看不懂的，底層的，跳過就是。

讀細節的時候，就只讀系統內自己關注的某個點，甚至某個具體的方法或者函數，一行一行慢慢啃。

---

題主，我個人感覺讀開源分兩種情況：

1. 工作中需要解決一類問題

2. 為了學習

如果為了解決一類問題，這個時候你的目的是很明確的，直接在源碼中找尋相關的部分讀就好。我當時為了解決連接不提供JMXURL的MBeanServer問題時，去看OpenJDK的源碼，其源碼東西很多，但這一塊因為目的明確，可以直接到其Attach機制實現的部分去了解，順帶著看JConsole的實現，就解決了問題。

而如果是為了學習，就需要慢慢來讀，開源項目一般都不小，不能急著想一氣讀完。那樣和讀課文一樣看過之後，也是吸收不到東西的。而藉助其文檔，了解整個項目的大概，架構，組件等一系列內容，再分別去看，效果可能會好一些。甚至讀的過程中，某一些點感覺很不錯，自己馬上上手mock一個，興趣可能會大增吧。 比如你在讀Tomcat源碼，則先了解其各個容器，組件劃分等。之後各個組件間的關聯，可以跑起來跟一下就會有個大概印象。

另外，也可以從開源項目的testcase入手，都是按功能點寫的。

至於題主提到的類有多個繼承這一類的，可以在看的時候一邊看一邊畫個類圖，也方便後續的使用。如果給別人講，甚至可以直接拿類圖開始說。

---

直接去找寫源碼的人，請他「簡略」的說說他的思路（語氣一定要好，別人不欠你的），一般來說，肯開源的人是不介意話花幾分鐘介紹一下自己的思路和想法的

---

單步調試，可以看到程序流程，比純粹瞎猜好多。

---

好像沒人說這個。。。應該先打開它的trace或debug日誌，跑起來，然後跟蹤日誌，可以最快的熟悉代碼

---

先去掌握了設計模式，再去看優秀的開源代碼

---

根據我的經驗，把握粒度很重要，每行每行讀是不現實的，這樣容易造成只見樹木不見森林，但是又不能讀的太粗糙，否則錯過很多精華部分，以c代碼為例，我一般是先以文件為單位，看看每個文件大致是幹嘛的，然後再以函數為單位，這時不關心函數的具體實現細節，而是將注意力放在函數介面上，大致理解下函數的意圖，控制流的流動等，然後覺得哪個函數比較重要，在看看其實現。。。

如果一上來就一行一行的啃就圖樣圖森破了，上述過程完成之後，如果還有餘力，最好親手實現一下，正所謂知者行之始，行者知之成，知行合一，如果能自己寫一個，就說明真的掌握了。。。

---

1、導入代碼至開發環境，運行起來

2、樣例代碼做為入口，逐步斷點調試

3、把工程、包名、類在word中按層次整理，分析寫出用途和主要技術點

4、畫程序流程圖或者時序圖

5、嘗試代碼擴展、以及打包構建

---

乃們需要Source Insight

（盜版狗逃竄）

---

讀代碼切勿一開始就鑽進一些細節。就像工作中接觸一個新項目，新人也是從解bug 開始。帶著目標問題去讀，效果更好。

要掌握一個整體架構，不妨自己動手畫出一張完整的類圖，對於理解代碼架構非常有幫助。

一些主要的業務邏輯，繼續畫些流程圖順序圖，就一目了然了。

最後才是語法方面的問題。我認為好的代碼一定也是閱讀起來超爽的......

---

先搞清楚代碼的業務流程，什麼設計模式都是看懂代碼以後的事了

---

vs2013/2015可以自動生成代碼圖，會好理解一些

---

熟悉一個開源項目，做好的辦法是為項目貢獻代碼。

僅僅抱著讀代碼的想法的話，沒有主線，太細節的地方也不太容易明白。

我覺得從項目Issues里比較簡單的開始，為項目貢獻代碼。這樣在解決問題的同時，也熟悉了項目，目標明確。

---

直接開始調試，先大致搞清楚程序跑得流程；然後不好調試的部分，比如網路，添加log，通過讀日誌分析程序行為。

最後，挑感興趣的部分，直接讀代碼。

---

絕大多數項目以及剩餘項目中的絕大部分代碼都沒有讀的價值。

自己能寫出來的代碼沒必要讀。

---

好的來開源項目都有文檔啊。看完了再看一下開發計劃和版本歷史啥的。

---

我是先看文件名(有文檔看文檔，命名規則很急很關鍵)、再看Region，接著看函數名和用到的數據結構(至少能知道這些東西大體是用來做什麼的)，然後把鍵盤一砸，媽了個雞!進入植物人狀態，點開函數看代碼實現和函數調用關係。

找到一個好的切入點、把眼光收攏到一處，找到設計者思路中的某一段，之後再鋪展開來就比較順暢了。

另外：同求利器

---

我也是，看到那麼多類，看著就煩死了，所以，我依然是個菜鳥。不過我也有自己的閱讀方法。開源項目的代碼結構文件布局應該都不錯，在了解項目的主題功能後，我都是先看文件夾結構，猜測每個文件夾下的文件可能是幹嘛的，文件名字應該都挺達意。我只說vs，它好像可以畫出所有類的引用關係圖，然後挑選繼承關係在最上層的開始閱讀。如果項目功能模塊分的比較開，那更好了，一個模塊一個模塊的讀。

閱讀中最怕數據model了，變數都是啥意思，怎麼用，能幹嘛，真是煩死了。

---

推薦閱讀：