在《想讀專案原始碼？可為什麼總是讀不下去？》一文中，我們聊了閱讀原始碼的錯誤方法。
本篇是《如何高效閱讀原始碼》專題的第二篇，來聊一聊「能提高原始碼閱讀效率的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個能提高原始碼閱讀效率的小技巧。下面我們將正式進入原始碼閱讀流程的講解部分。