在《想讀項目源碼？可爲什麼總是讀不下去？》一文中，我們聊了閱讀源碼的錯誤方法。
本篇是《如何高效閱讀源碼》專題的第二篇，來聊一聊「能提高源碼閱讀效率的15個小技巧」！
１５個小技巧包括：
-
瞭解作者開發項目的目的
-
先熟練的使用項目
-
閱讀官方文檔
-
理解項目中的概念
-
瞭解項目技術背景
-
沒必要讀最新版本的代碼
-
不需要讀完所有的源碼
-
版本間比較閱讀
-
自頂向下梳理
-
自底向上歸納
-
先做減法，再做加法
-
從接口找關係
-
畫圖輔助閱讀
-
設計模式輔助閱讀
-
debug只是輔助
下面來一個個的闡述。
瞭解作者開發項目的目的
我們都知道「軟件是工具」，是爲了解決某個或某些問題的：
-
IM解決了人們在網上溝通的問題
-
淘寶解決了人們在網絡上購物的問題
-
支付寶解決了無錢包支付的問題
瞭解了一個項目的目的，也就清楚了項目所需要解決的問題。如果你熟悉這個問題所對應的領域，你就能大概知道這個項目有哪些功能模塊。比如淘寶是購物的，那它至少得有客戶管理、商家管理、店鋪管理、商品管理、商品購買、購物車等等模塊。
即使你不熟悉，你在通過該項目的學習後，在後面閱讀其它類似項目時，也能有事半功倍的效果。
先熟練的使用項目
在閱讀源碼之前，你需要能熟練的使用項目，不僅僅是寫個demo跑一下！你需要在實際項目中去應用。你需要能夠摸清開源項目有哪些功能。你越熟悉項目，你閱讀源碼的難度就越小。
就像組裝電腦一樣，你連主板、顯卡、電源都還傻傻分不清楚，你怎麼去組裝電腦呢？更別說去自己做一個電腦了！
閱讀官方文檔
可能大家都喜歡通過實踐的方式去了解一個項目，因爲更直觀。但是，實際上了解項目最好的方法是閱讀官方文檔。對於一個項目來說，最瞭解這個項目的人是誰呢？當然是作者本人。文檔就是作者通過文字的方式告訴你項目的結構、具體解決的問題以及怎麼解決的。好的項目都會有比較完善的文檔。
另外通過實踐的方式瞭解項目是一個摸索的過程，可能會有遺漏。而文檔能給你一個全面的瞭解，能夠彌補這些遺漏。
理解項目中的概念
一個項目一般都會有一些自己的概念或者基於某些理論、模式來構建，理解了這些概念、理論和模式，能幫你更好的理解項目代碼。
比如你不瞭解NIO以及Reactor模型，那你讀Netty源碼可能就非常的喫力。你不瞭解生產者、消費者、Broker、主題、分區、副本這些概念，你讀Kafka源碼就很喫力。
瞭解項目技術背景
你有沒有發現其實很多項目的迭代，其核心功能並沒有發生什麼樣的變化，變化的可能只是實現方式的不同。頻繁變化的實際上不是需求，而是實現需求的技術！
就以「移動網絡的技術發展對娛樂所產生的影響」來說。
在我剛上大學的時候，手機還是2G的，當時的娛樂方式就是看看文字小說、聽聽mp3、看看mp4！因爲2G網速的限制，當時所做的應用有這麼幾類：
-
省流量的瀏覽器，能自動屏蔽圖片，加速網站的打開
-
音頻視頻轉換壓縮軟件，方便拷貝到手機上
-
方便的將mp3、mp4拷貝到手機上的軟件
然後3G出來了，每個月的流量也按G來算了，圖片什麼的所消耗的流量也就不那麼在乎了，所以省流量的瀏覽器的作用就越來越小了，取而代之的是功能齊全的瀏覽器，能自動適配手機，快速打開各種圖片。但是聽歌和看視頻還是以拷貝爲主，因爲畢竟一個月流量也下不了幾部電影，且3G速度還不支持高清視頻的在線播放。
接着4G來了，每個月也不限流量了，於是聽歌、看視頻都能在線看了，優酷、土豆這類視頻類網站開始多了起來。而視頻轉換類軟件以及文件拷貝類軟件就很快銷聲匿跡了。
現在5G要來了，它會以什麼樣的方式來影響我們的生活呢？現在還不得而知。不過你可以發現，無論技術怎麼變，我們的娛樂方式其實沒怎麼變化過，無非就是看看小說、聊聊天、看看視頻、聽聽歌，但是隨着技術的發展，實現的方式產生了變化。
項目的發展也是類似的，核心的功能並沒有多少變化，主要是實現技術的變化。所以在閱讀源碼的時候，瞭解一下當時的技術背景，知道當時的技術限制，才能更好的理解代碼爲什麼這麼寫。
這就像很多人剛進入一家新公司，抱怨說公司的代碼太爛了，覺得還不如自己寫的。如果你瞭解一下當時的情形，可能會發現這麼寫是最優的。
沒必要讀最新版本的代碼
很多人讀源碼都喜歡下最新版本的代碼來讀，因爲裏面使用了最新的技術。但是，新版本的項目無論從功能還是代碼量上，都比老版本多得多。
以Linux內核爲例，目前Linux內核的代碼量已經超過了2500萬行，就算你一目十行，那也需要250萬秒，也就是說你要不眠不休看將近29天才能看完！
實際上無論發佈了多少版本，它要解決的問題基本不變。所以你可以找一個相對老一點的版本來閱讀，理解了它的核心功能以後，再慢慢的進行必要的額外功能的源碼閱讀。
不需要讀完所有的源碼
不知道你讀書的時候有沒有這種心理，就是書裏的每個字都讀完了，你才認爲讀完了一本書，如果沒有讀完，你心裏就特別的糾結？其實沒必要，書是作者在闡述自己的觀點，你只要get到他的點，並且有自己的看法，那麼你實際上就已經收穫了書裏的精華了，沒必要每個字都讀完。
其實書裏的很多話都是廢話，或輔助，僅僅是爲了更好的闡述那個核心觀點。源碼也是一樣，大部分的代碼都是爲了輔助核心代碼來完成核心邏輯的，沒必要一字不落的將所有代碼都讀完，效益比不高。你需要學習的是設計思路。
版本間比較閱讀
前面說，項目的不同版本可能技術上、實現上有差異。通過比較閱讀的方式，能夠發現這些差異，再結合自己的思考：
-
爲什麼有這些差異？
-
哪種實現方式好？
-
哪種實現方式不好？
-
好在哪裏？
-
不好在哪裏？
-
......
你就能更好的理解項目設計思路。同時，如果你已經讀完了一個版本的源碼，那麼基於這個版本的源碼再去讀新版本的源碼會更加的容易。
自頂向下梳理
越上層的模塊，功能越多，但數量越少。我們可以從頂層的模塊梳理出大致的流程關係，然後通過不斷的深入，來梳理細化流程。就像思維腦圖一樣。
後面的文章會具體的講解如何梳理這些模塊。
自底向上歸納
思維腦圖的一個問題就是「只管拆分，不管歸納」！歸納其實是非常重要的一環。當你梳理了細化的流程後，需要將細化流程整合歸納到整體流程中，通過不斷的歸納，你才能理解整體的流程。
後面的文章會具體的講解如何歸納總結，將細化的流程整合到完整的流程中。
先做減法，再做加法
前面說了，無論項目代碼多大、版本怎麼變化，核心的功能是基本不變的。所以我們先自頂向下的去不斷的剔除非核心的組件/包/類，找到核心的模塊/包/類。梳理出核心流程後，在覈心流程的基礎上再進行擴展，引入其它流程，以構成完整的項目流程。
這也是本專題將要介紹的方法，後面會詳細說明和演示。
從接口找關係
個人認爲「接口」這個詞並不好，應該叫「協議」更合適。接口定義了一套可供外部訪問的方法，其實就是交互的協議，外部對象、模塊或者系統需要按照這個「協議」來訪問我們的系統，所以我們可以從接口的調用關係，來梳理出模塊之間的調用關係。
後面的文章中將具體演示梳理方法。
畫圖輔助閱讀
有研究表明，我們接收的大部分信息都是通過眼睛接收的。繪圖能加強我們的理解。同時，繪圖相當於是有了存檔，當再次看到繪製的流程圖或結構圖時，能快速的喚起你對項目的理解。
設計模式輔助閱讀
之前寫了一篇文章「從架構層面看設計模式」，通過對策略模式的講解，闡述了設計模式對架構的影響。如果你很熟悉設計模式，你就能從代碼中的設計模式梳理出代碼結構，也就能加快你對源碼的理解。
debug只是輔助
從「想讀項目源碼？可爲什麼總是讀不下去？」這篇文章中，你應該能體會到直接使用debug的問題了。所以不要一上來就debug，debug是在你理解了項目結構和流程後的一個驗證手段，或者確認某些具體細節的方法。如果一上來就進行debug，你就會陷入「想讀項目源碼？可爲什麼總是讀不下去？」這篇文章中提到的死循環中。
通過後面文章的學習，相信你能學會正確的使用debug的方式。
總結
本文梳理了15個能提高源碼閱讀效率的小技巧。下面我們將正式進入源碼閱讀流程的講解部分。