大家好，我是Z哥。

之前寫了一篇關(guān)于閱讀源碼到底有多少價(jià)值的文章《閱讀源碼的真正價(jià)值》，反響還不錯(cuò)。

在文中我向你闡明了閱讀源碼5個(gè)價(jià)值。

面試

在工作中更快地上手新項(xiàng)目

給自己創(chuàng)造用新技術(shù)的機(jī)會(huì)

完善知識(shí)體系

學(xué)習(xí)別人的設(shè)計(jì)思路

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

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

其實(shí)從整個(gè)程序員群體來(lái)看，很少有人去學(xué)習(xí)這些項(xiàng)目的源碼，大部分人都僅僅停留在 API 使用階段。

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

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

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

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

有時(shí)我們閱讀源碼會(huì)配合著調(diào)試。但是有些源碼的環(huán)境依賴比較多，一旦我們?cè)诓渴瓠h(huán)境的時(shí)候遇到了各種詭異的問題，但是查了很多資料依舊未能解決的時(shí)候，就會(huì)失去耐心，促使我們放棄。

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

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

之所以出現(xiàn)這樣的情況，在我看來(lái)是因?yàn)闆]有找到明確的方向或者目標(biāo)太大，閱讀源碼是為了什么？為了提升自己，但是這個(gè)目標(biāo)太大了，大到你還沒有接收到正反饋就堅(jiān)持不下去了。

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

/01? 閱讀源碼的時(shí)機(jī)/

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

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

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

舉個(gè)例子，比如你看到網(wǎng)上很多文章都在說redis單線程的性能表現(xiàn)在某些場(chǎng)景下甚至比多線程的memcached還要好。

那么你可以帶著這個(gè)問題去找到對(duì)應(yīng)的源碼去學(xué)習(xí)，這比你漫無(wú)目的的在大量的源碼中亂逛，效果好得多。因?yàn)楫?dāng)你閱讀完源碼后你會(huì)獲得一個(gè)正反饋，就是你知道了問題的答案，這種收獲與成就感也會(huì)大大加深這次學(xué)習(xí)的效果。

所以，一定要有一個(gè)問題或者說目的，沒有目的就不要去閱讀源碼，還不如打游戲刷短視頻。因?yàn)槟愦蟾怕蕸]幾天就會(huì)全部忘記你看過的東西。

如果你只是想學(xué)習(xí)一下，實(shí)在想不到什么問題作為切入點(diǎn)，那么不妨從git倉(cāng)庫(kù)里的issue里找一個(gè)開始吧。

/02? 怎么讀/

01? 準(zhǔn)備工作

閱讀源碼之前首先你得掌握相關(guān)的基礎(chǔ)知識(shí)。比如，你要去讀Linux內(nèi)核的源碼，但是對(duì)C語(yǔ)言并不熟悉，這個(gè)事情自然沒法繼續(xù)下去。

在具備起碼的基礎(chǔ)知識(shí)后，先去官網(wǎng)看看是否有什么文檔，通過閱讀文檔可以對(duì)項(xiàng)目設(shè)計(jì)思路和演進(jìn)思路有一個(gè)大致的了解，這對(duì)你在實(shí)際閱讀源碼的時(shí)候可以起到事半功倍的效果。

還可以了解一下，是否有其他項(xiàng)目是該項(xiàng)目的衍生品。因?yàn)楫?dāng)你后續(xù)覺得閱讀該項(xiàng)目的源碼舉步維艱的時(shí)候，那么不妨試試從封裝它的上層入手。多一種選擇。

02? 從最早的穩(wěn)定版本開始看

coding和造房子一樣，結(jié)構(gòu)（架構(gòu)）在最開始一但確定好，后續(xù)幾乎無(wú)法推翻重改，所以建議你從第一個(gè)版本開始看，可以通過閱讀最少的代碼就能了解到整個(gè)項(xiàng)目大部分的內(nèi)容，包括它的核心設(shè)計(jì)思路。

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

03? 在IDE閱讀

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

Z哥建議你一定要把代碼放到IDE里閱讀，畢竟IDE里可以方便跳轉(zhuǎn)，查看定義，而且只要環(huán)境搭好還可以調(diào)試，比起在網(wǎng)頁(yè)上看效率高得多。

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

04? 盡量調(diào)試一下

盡可能編譯調(diào)試一下。因?yàn)樵赯哥覺得能調(diào)試的代碼，幾乎沒有看不懂的。

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

如果一份代碼你只能看不能調(diào)試，那可能讀到一些地方你只能猜這個(gè)地方的數(shù)據(jù)值和跳轉(zhuǎn)結(jié)構(gòu)是怎么樣的，而且很有可能你猜的是錯(cuò)的。但如果你能編譯運(yùn)行，那在需要的時(shí)候你可以修改，加日志等等來(lái)更好地觀察和驗(yàn)證你的想法，得到正確的理解。

05? 先從宏觀再到微觀

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

這樣當(dāng)你在后續(xù)經(jīng)過多次代碼跳轉(zhuǎn)之后，不至于暈頭轉(zhuǎn)向的。

同樣的，在你深入代碼細(xì)節(jié)之前，先從“宏觀”入手。先捋清楚與這相關(guān)的上下游完整的流程是如何映射在代碼里的，然后再開始深入其中的具體環(huán)節(jié)的實(shí)現(xiàn)。

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

06? 適當(dāng)跳過一些代碼

一個(gè)項(xiàng)目的源碼規(guī)模越大，里面的能跳過不讀的代碼也越多。

哪些是可以跳過的？

比如，針對(duì)數(shù)據(jù)的處理，json的序列化和反序列化、xml數(shù)據(jù)的讀取和寫入等代碼，這些代碼往往還特別冗長(zhǎng)。

07? 看一遍無(wú)法理解的代碼就畫圖

當(dāng)你看一遍甚至好幾遍都無(wú)法完全明白的代碼，說明它具有一定的復(fù)雜性。

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

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

08? 做筆記

我相信每個(gè)人都出現(xiàn)過這樣的情況：

• 這個(gè)問題我之前解決過，怎么解決來(lái)著？好像想不起來(lái)了……

• 這個(gè)問題我之前研究過，是怎么回事來(lái)著？好像想不起來(lái)了……

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

• ……
  

如果你當(dāng)時(shí)做了筆記，就不會(huì)出現(xiàn)這種情況了。而且，做筆記不僅僅可以用做后續(xù)的查閱，還可以幫助你更快地進(jìn)入前一天的閱讀狀態(tài)。

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

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

然后每天工作結(jié)束，稍做整理，并且將當(dāng)前遺留的未知問題記錄好，這樣你第二天很容易進(jìn)入到昨天的狀態(tài)中繼續(xù)進(jìn)行。

如果你打算將閱讀源碼作為一個(gè)長(zhǎng)期習(xí)慣去做，那么你平時(shí)儲(chǔ)備的通用知識(shí)多少又變得很重要，因?yàn)樗鼈兛梢栽陂喿x源碼的時(shí)候大大提升效率。

比如，設(shè)計(jì)模型、常用的算法等。當(dāng)你看到什么XXXbuilder、XXXfactory，你就心領(lǐng)神會(huì)了，自然能大大提高閱讀效率。

當(dāng)然，如果遇到你之前不懂的設(shè)計(jì)模式、算法，那么應(yīng)該停下來(lái)花點(diǎn)時(shí)間，將他們消化掉，這樣你的通用知識(shí)庫(kù)就又?jǐn)U大了一些。

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

我有時(shí)看代碼，也會(huì)反復(fù)好幾遍看不明白，感覺真是覺得搞不定了，然而，這意味著要么是你基礎(chǔ)知識(shí)沒準(zhǔn)備好，要么是你找錯(cuò)了入口，要知道，任何一份代碼，都有一條隱形的線串著，耐心點(diǎn)，總會(huì)找到。

好了，總結(jié)一下。

這篇呢，Z哥和你分享了我在閱讀源碼這件事上的一些經(jīng)驗(yàn)。

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

其次在讀的時(shí)候可以做以下8件事：

準(zhǔn)備工作

從最早的穩(wěn)定版本開始看

在IDE閱讀

盡量調(diào)試一下

先從宏觀再到微觀

適當(dāng)跳過一些代碼

看一遍無(wú)法理解的代碼就畫圖

做筆記

希望對(duì)你有所幫助。

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。