大家好，我是Z哥。

之前寫了一篇關于閱讀源碼到底有多少價值的文章《閱讀源碼的真正價值》，反響還不錯。

在文中我向你闡明了閱讀源碼5個價值。

面試

在工作中更快地上手新項目

給自己創造用新技術的機會

完善知識體系

學習別人的設計思路

那么今天我就和你來聊聊如何更好地閱讀源碼，畢竟閱讀源碼這件事做起來還是有一定難度的，特別是剛起步的時候。

而且有些巨型源碼庫，如果你不掌握一些高效的方式，那你閱讀起來會讓你絕望。就像往大海里投個石子，雖能掀起一絲漣漪，但海面很快就歸于平靜。

其實從整個程序員群體來看，很少有人去學習這些項目的源碼，大部分人都僅僅停留在 API 使用階段。

很多人對某個框架、項目的了解，最多停留在其它人對源碼的解讀之上。的確，在搜索引擎如此成熟、信息如此多的時代，如果要快速了解信息，以便解決眼前的問題，這的確是高效的方式。

相信有不少人肯定也嘗試過去github上閱讀那些開源框架的源碼，但是堅持不下去。在我看來原因主要是以下幾種，

花了好幾個小時，甚至好幾天，才看懂了1、2個文件里的代碼。但是畢竟還得工作呢，按這個進度的話，實在沒辦法拿出太多的時間放在源碼的閱讀上，還是算了吧。

第一個選擇閱讀的項目規模就比較大。一般這種大型項目，必然是經歷了多年的迭代而形成的。所以，不管從復雜度還是代碼量上都是“困難”級別的。當一次次遇到無法理解而放棄，換一個切入點但困難依舊的時候，你會覺得自己根本無法駕馭它，挫敗感會促使你放棄閱讀源碼這件事情。

有時我們閱讀源碼會配合著調試。但是有些源碼的環境依賴比較多，一旦我們在部署環境的時候遇到了各種詭異的問題，但是查了很多資料依舊未能解決的時候，就會失去耐心，促使我們放棄。

看了一段時間的源碼，但是感受不到自己獲得了什么，沒有成就感。漸漸地，閱讀源碼的熱情逐漸消失殆盡，感覺還是打游戲、刷短視頻更香。

不知道上面有你的影子嗎？

之所以出現這樣的情況，在我看來是因為沒有找到明確的方向或者目標太大，閱讀源碼是為了什么？為了提升自己，但是這個目標太大了，大到你還沒有接收到正反饋就堅持不下去了。

所以我覺得有效地閱讀源碼的步驟分為以下兩步，when和how，正好對應上一篇《閱讀源碼的真正價值》的why。

/01? 閱讀源碼的時機/

很多人看源碼之所以看不下去，間接說明了一個問題，并不是任何時候都適合閱讀源碼。

所以，我們的第一個問題就是要搞清楚“什么時候適合閱讀源碼”。

我親測有效的方法是，帶著問題去閱讀源碼，哪怕是一個個看似很小的問題。慢慢庖丁解牛，逐漸吃透整個項目。

舉個例子，比如你看到網上很多文章都在說redis單線程的性能表現在某些場景下甚至比多線程的memcached還要好。

那么你可以帶著這個問題去找到對應的源碼去學習，這比你漫無目的的在大量的源碼中亂逛，效果好得多。因為當你閱讀完源碼后你會獲得一個正反饋，就是你知道了問題的答案，這種收獲與成就感也會大大加深這次學習的效果。

所以，一定要有一個問題或者說目的，沒有目的就不要去閱讀源碼，還不如打游戲刷短視頻。因為你大概率沒幾天就會全部忘記你看過的東西。

如果你只是想學習一下，實在想不到什么問題作為切入點，那么不妨從git倉庫里的issue里找一個開始吧。

/02? 怎么讀/

01? 準備工作

閱讀源碼之前首先你得掌握相關的基礎知識。比如，你要去讀Linux內核的源碼，但是對C語言并不熟悉，這個事情自然沒法繼續下去。

在具備起碼的基礎知識后，先去官網看看是否有什么文檔，通過閱讀文檔可以對項目設計思路和演進思路有一個大致的了解，這對你在實際閱讀源碼的時候可以起到事半功倍的效果。

還可以了解一下，是否有其他項目是該項目的衍生品。因為當你后續覺得閱讀該項目的源碼舉步維艱的時候，那么不妨試試從封裝它的上層入手。多一種選擇。

02? 從最早的穩定版本開始看

coding和造房子一樣，結構（架構）在最開始一但確定好，后續幾乎無法推翻重改，所以建議你從第一個版本開始看，可以通過閱讀最少的代碼就能了解到整個項目大部分的內容，包括它的核心設計思路。

后期追加的很多代碼其實有不少都在完善最初設計沒考慮周全的地方以及異常處理，代碼量雖然增加了，但是重要性完全不同。

03? 在IDE閱讀

很多高手直接在git上看源碼，效果如何我不清楚，反正我是覺得不太靠譜。

Z哥建議你一定要把代碼放到IDE里閱讀，畢竟IDE里可以方便跳轉，查看定義，而且只要環境搭好還可以調試，比起在網頁上看效率高得多。

如果你實在要在git上直接閱讀，好吧，我也幫你一把，推薦你一個chrome插件：SourceGraph。為你提供接近IDE般的操作體驗。

04? 盡量調試一下

盡可能編譯調試一下。因為在Z哥覺得能調試的代碼，幾乎沒有看不懂的。

很多人在工作中修bug為什么喜歡直連生產環境調試？除了修bug效率高之外，還有一個原因就是它直觀的體現了一個完整的流程在代碼中是如何體現的。

如果一份代碼你只能看不能調試，那可能讀到一些地方你只能猜這個地方的數據值和跳轉結構是怎么樣的，而且很有可能你猜的是錯的。但如果你能編譯運行，那在需要的時候你可以修改，加日志等等來更好地觀察和驗證你的想法，得到正確的理解。

05? 先從宏觀再到微觀

在看具體的代碼之前，建議你先大致過一下整個項目的分層，知道解決方案里每一個項目的作用是什么。比如，這個專門存放全局工具類的項目，這個是數據訪問層，等等。

這樣當你在后續經過多次代碼跳轉之后，不至于暈頭轉向的。

同樣的，在你深入代碼細節之前，先從“宏觀”入手。先捋清楚與這相關的上下游完整的流程是如何映射在代碼里的，然后再開始深入其中的具體環節的實現。

另外，interface也是獲取宏觀信息很好的入口，當然前提是方法的命名比較規范或者有注釋。

06? 適當跳過一些代碼

一個項目的源碼規模越大，里面的能跳過不讀的代碼也越多。

哪些是可以跳過的？

比如，針對數據的處理，json的序列化和反序列化、xml數據的讀取和寫入等代碼，這些代碼往往還特別冗長。

07? 看一遍無法理解的代碼就畫圖

當你看一遍甚至好幾遍都無法完全明白的代碼，說明它具有一定的復雜性。

此時，你不要偷懶，老老實實地畫流程圖、時序圖等來幫助你梳理和記憶。它們最終為你省下的時間大概率比你花的時間多得多。

而且畫圖是把代碼具像化了，當你對著一張流程圖讀源碼，就好像拿著地圖走迷宮一般，確保自己走在預期的道路上。

08? 做筆記

我相信每個人都出現過這樣的情況：

• 這個問題我之前解決過，怎么解決來著？好像想不起來了……

• 這個問題我之前研究過，是怎么回事來著？好像想不起來了……

• 更甚之的情況是，早上覺得弄懂了數據流向，中午吃個飯就忘了。

• ……
  

如果你當時做了筆記，就不會出現這種情況了。而且，做筆記不僅僅可以用做后續的查閱，還可以幫助你更快地進入前一天的閱讀狀態。

這里建議用紙和筆就好。如果要用軟件的話，最好弄個雙屏，這樣可以避免頻繁地在查看源碼的應用和記錄筆記的應用之間的切換。

我建議你弄明白一個問題或者收獲一個新的信息就記錄一下。

然后每天工作結束，稍做整理，并且將當前遺留的未知問題記錄好，這樣你第二天很容易進入到昨天的狀態中繼續進行。

如果你打算將閱讀源碼作為一個長期習慣去做，那么你平時儲備的通用知識多少又變得很重要，因為它們可以在閱讀源碼的時候大大提升效率。

比如，設計模型、常用的算法等。當你看到什么XXXbuilder、XXXfactory，你就心領神會了，自然能大大提高閱讀效率。

當然，如果遇到你之前不懂的設計模式、算法，那么應該停下來花點時間，將他們消化掉，這樣你的通用知識庫就又擴大了一些。

總之，閱讀源碼還是一個比較費神的事情，要有耐心，遇到困難的時候更是如此。

我有時看代碼，也會反復好幾遍看不明白，感覺真是覺得搞不定了，然而，這意味著要么是你基礎知識沒準備好，要么是你找錯了入口，要知道，任何一份代碼，都有一條隱形的線串著，耐心點，總會找到。

好了，總結一下。

這篇呢，Z哥和你分享了我在閱讀源碼這件事上的一些經驗。

首先，一定要帶著問題或者目的去讀源碼，否則就別讀了，讀源碼光“看”是沒意義的。

其次在讀的時候可以做以下8件事：

準備工作

從最早的穩定版本開始看

在IDE閱讀

盡量調試一下

先從宏觀再到微觀

適當跳過一些代碼

看一遍無法理解的代碼就畫圖

做筆記

希望對你有所幫助。

源碼一開始讀不懂是正常的，讀不懂才要讀，想不明白才要想，這是進步和成長的開始。那些阻擋你的蹂躪你的而又殺不死你的，終將幫助你成長讓你變得更強大。

總結

以上是生活随笔為你收集整理的帮助阅读源码的8个技巧的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。