在《想讀專案原始碼？可為什麼總是讀不下去？》一文中，我們聊了閱讀原始碼的錯誤方法。１５個小技巧包括：
下面來乙個個的闡述。
我們都知道「軟體是工具」，是為了解決某個或某些問題的：
了解了乙個專案的目的，也就清楚了專案所需要解決的問題。如果你熟悉這個問題所對應的領域，你就能大概知道這個專案有哪些功能模組。比如**是購物的，那它至少得有客戶管理、商家管理、店鋪管理、商品管理、商品購買、購物車等等模組。
即使你不熟悉，你在通過該項目的學習後，在後面閱讀其它類似專案時，也能有事半功倍的效果。
在閱讀原始碼之前，你需要能熟練的使用專案，不僅僅是寫個demo跑一下！你需要在實際專案中去應用。你需要能夠摸清開源專案有哪些功能。你越熟悉專案，你閱讀原始碼的難度就越小。
就像組裝電腦一樣，你連主機板、顯示卡、電源都還傻傻分不清楚，你怎麼去組裝電腦呢？更別說去自己做乙個電腦了！
可能大家都喜歡通過實踐的方式去了解乙個專案，因為更直觀。但是，實際上了解專案最好的方法是閱讀官方文件。對於乙個專案來說，最了解這個專案的人是誰呢？當然是作者本人。文件就是作者通過文字的方式告訴你專案的結構、具體解決的問題以及怎麼解決的。好的專案都會有比較完善的文件。
另外通過實踐的方式了解專案是乙個摸索的過程，可能會有遺漏。而文件能給你乙個全面的了解，能夠彌補這些遺漏。
乙個專案一般都會有一些自己的概念或者基於某些理論、模式來構建，理解了這些概念、理論和模式，能幫你更好的理解專案**。
比如你不了解nio以及reactor模型，那你讀netty原始碼可能就非常的吃力。你不了解生產者、消費者、broker、主題、分割槽、副本這些概念，你讀kafka原始碼就很吃力。
你有沒有發現其實很多專案的迭代，其核心功能並沒有發生什麼樣的變化，變化的可能只是實現方式的不同。頻繁變化的實際上不是需求，而是實現需求的技術！
就以「流動網路的技術發展對娛樂所產生的影響」來說。
在我剛上大學的時候，手機還是2g的，當時的娛樂方式就是看看文字**、聽聽***、看看mp4！因為2g網速的限制，當時所做的應用有這麼幾類：
方便的將***、mp4拷貝到手機上的軟體
專案的發展也是類似的，核心的功能並沒有多少變化，主要是實現技術的變化。所以在閱讀原始碼的時候，了解一下當時的技術背景，知道當時的技術限制，才能更好的理解**為什麼這麼寫。
這就像很多人剛進入一家新公司，抱怨說公司的**太爛了，覺得還不如自己寫的。如果你了解一下當時的情形，可能會發現這麼寫是最優的。
很多人讀原始碼都喜歡下最新版本的**來讀，因為裡面使用了最新的技術。但是，新版本的專案無論從功能還是**量上，都比老版本多得多。
以linux核心為例，目前linux核心的**量已經超過了2500萬行，就算你一目十行，那也需要250萬秒，也就是說你要不眠不休看將近29天才能看完！
實際上無論發布了多少版本，它要解決的問題基本不變。所以你可以找乙個相對老一點的版本來閱讀，理解了它的核心功能以後，再慢慢的進行必要的額外功能的原始碼閱讀。
不知道你讀書的時候有沒有這種心理，就是書裡的每個字都讀完了，你才認為讀完了一本書，如果沒有讀完，你心裡就特別的糾結？其實沒必要，書是作者在闡述自己的觀點，你只要get到他的點，並且有自己的看法，那麼你實際上就已經收穫了書裡的精華了，沒必要每個字都讀完。
其實書裡的很多話都是廢話，或輔助，僅僅是為了更好的闡述那個核心觀點。原始碼也是一樣，大部分的**都是為了輔助核心**來完成核心邏輯的，沒必要一字不落的將所有**都讀完，效益比不高。你需要學習的是設計思路。
你就能更好的理解專案設計思路。同時，如果你已經讀完了乙個版本的原始碼，那麼基於這個版本的原始碼再去讀新版本的原始碼會更加的容易。
越上層的模組，功能越多，但數量越少。我們可以從頂層的模組梳理出大致的流程關係，然後通過不斷的深入，來梳理細化流程。就像思維腦圖一樣。
後面的文章會具體的講解如何梳理這些模組。
思維腦圖的乙個問題就是「只管拆分，不管歸納」！歸納其實是非常重要的一環。當你梳理了細化的流程後，需要將細化流程整合歸納到整體流程中，通過不斷的歸納，你才能理解整體的流程。
後面的文章會具體的講解如何歸納總結，將細化的流程整合到完整的流程中。
前面說了，無論專案**多大、版本怎麼變化，核心的功能是基本不變的。所以我們先自頂向下的去不斷的剔除非核心的元件/包/類，找到核心的模組/包/類。梳理出核心流程後，在核心流程的基礎上再進行擴充套件，引入其它流程，以構成完整的專案流程。
這也是本專題將要介紹的方法，後面會詳細說明和演示。
個人認為「介面」這個詞並不好，應該叫「協議」更合適。介面定義了一套可供外部訪問的方法，其實就是互動的協議，外部物件、模組或者系統需要按照這個「協議」來訪問我們的系統，所以我們可以從介面的呼叫關係，來梳理出模組之間的呼叫關係。
後面的文章中將具體演示梳理方法。
有研究表明，我們接收的大部分資訊都是通過眼睛接收的。繪圖能加強我們的理解。同時，繪圖相當於是有了存檔，當再次看到繪製的流程圖或結構圖時，能快速的喚起你對專案的理解。
之前寫了一篇文章「從架構層面看設計模式」，通過對策略模式的講解，闡述了設計模式對架構的影響。如果你很熟悉設計模式，你就能從**中的設計模式梳理出**結構，也就能加快你對原始碼的理解。
從「想讀專案原始碼？可為什麼總是讀不下去？」這篇文章中，你應該能體會到直接使用debug的問題了。所以不要一上來就debug，debug是在你理解了專案結構和流程後的乙個驗證手段，或者確認某些具體細節的方法。如果一上來就進行debug，你就會陷入「想讀專案原始碼？可為什麼總是讀不下去？」這篇文章中提到的死迴圈中。
通過後面文章的學習，相信你能學會正確的使用debug的方式。
《原始碼閱讀》原始碼閱讀技巧,原始碼閱讀工具
檢視某個類的完整繼承關係 選中類的名稱，然後按f4 quick type hierarchy quick type hierarchy可以顯示出類的繼承結構，包括它的父類和子類 supertype hierarchy supertype hierarchy可以顯示出類的繼承和實現結構，包括它的父類和...
閱讀原始碼那些事
看spring的原始碼的時候如果我們一直追究所有的細節那會讓我們會越陷越深，掉入細節的無底洞，稍不留神腦迴路跟不上就會矇圈。因此，我們要學會找原始碼中的關鍵部分看，弄懂主要流程和本次看原始碼的目的的那部分就行。等我們對spring整體有了乙個很好的理解之後，再回頭看之前不懂的 就會豁然開朗。對於框架...
原始碼閱讀技巧篇
說到讀原始碼，讓我想起來了讀書，古語有云 讀破萬卷書，下筆如有神 就拿rocketmq來說，它是如何實現高效能 高可用。之前寫過高可用的一些思考和理解裡面的特性他應該都滿足，rocketmq就是把這些很多零散的知識點整合運用之後寫出的非常牛逼的專案。依舊拿讀書來說，我們應該讀什麼書呢？讀名著，讀大師...