閱讀源碼很重要，以logback為例，分享一個小白都能學會的讀源碼方法
- 2021 年 6 月 17 日
- 筆記
作為一個程式設計師，經常需要讀一些開源項目的源碼。同時呢，讀源碼對我們也有很多好處:
1.提升自己
閱讀優秀的程式碼，第一可以提升我們自身的編碼水平，第二可以開拓我們寫程式碼的思路，第三還可能讓我們拿到大廠 offer。無論那種情況，優秀的程式碼就是提升我們開發水平的資糧，而把這些優秀的程式碼讀懂、讀透並不很容易。
2.修復 Bug
有些時候，我們用的一些開源組件，出現了一些預想不到的問題。而這時候，也沒有前人經驗可借鑒，也沒有文檔可供參考，只能靠自己修復。閱讀程式碼，理解項目，才能順利修復問題。如果閱讀程式碼水平不夠，修復 Bug 這事兒就成了個棘手的事兒，影響咱們的工作。
3.增加新功能
在工作中，我們會遇到翻遍開源庫也沒有特別合適的組件的情況。這就只能對現有的組件進行改造，而這種改造的前置條件就是去理解開源組件。這時候，我們只能去閱讀程式碼。
讀源碼好處很多，但是，讀源碼本身不是件簡單的事。
相反，這是件非常困難的事情。一般來說，讀程式碼比較困難的情況體現在:
- 程式碼讀起來太枯燥，讀了一會兒就犯困、犯糊塗；
- 程式碼讀了很長時間，結果發現不知道得到了什麼，花了時間卻什麼也沒學到，讀了個寂寞；
- 一個開源組件，讀程式碼就花了好幾天，就這也才弄懂了一兩個文件里的程式碼，結果耽誤了正常工作。
自我工作以來，長期和各種開源組件打交道，也被迫讀了許多的程式碼。在經歷了以上種種困難之後，花費了好幾年的時間，我才算總結了一套自己的打法，才算能真正的去快速的讀懂、讀透許多開源組件。
恰好也有許多讀者朋友問起我該如何讀程式碼，所以，我決定把我總結的一些套路寫出來，望能給大家一些幫助，能更快的提升自己。
那我們來看看我個人讀程式碼的一些辦法。
一、縱覽全局
閱讀程式碼之前，首先我們要用上帝視角去看源碼，用上帝視角目的在於去了解這個組件的全貌。
全貌包括：
1. 開源項目的主要用途
我們要知道項目主要是用來幹嘛的，因為這是項目的終極目標。
所有開源項目的源碼本身都是為了這個終極目標才寫出來的。
例如，對於 logback 而言，它的用途就是打日誌。而它所有的程式碼無論多複雜，終極目標就是要讓 logback 能健壯高效的列印出日誌來。
2. 項目的架構
了解項目架構的價值在於，能了解系統的層次結構，就能理出項目的核心脈絡。有了核心脈絡，我們就能把有限的時間用在閱讀最有價值的程式碼上。
如果項目的官方文檔有架構圖，那麼就從官方的架構圖去了解項目的整體架構。如果文檔中沒有架構圖，就去搜一下有沒有民間大神畫出來，如果還沒有，可以根據官方文檔的描述，自己畫出來架構圖。
以 logback 為例，由於官方沒有提供架構圖，我根據文檔大概畫了一個架構圖。
二、把玩無厭
摸清楚了系統的核心脈絡，我們還需要把項目運行起來。
運行項目有兩個目的:
1. 知道這個項目運行前有哪些必須的前置條件
還是回到 logback 的例子上。
當我們能成功運行 logback 後，其必然存在了一個 logback.xml 文件，否則無法運行。
這個 logback.xml 文件其實對於我們看源碼非常重要，它點出了 logback 需要的關鍵元素。
並且，如果讀源碼遇到了困惑，明白了這個配置文件，就能有效幫助我們跨過障礙。後面談到如何具體的讀源碼時再細說。
上面是一個基本的 logback 配置，裡面列出了 logback 運行需要的關鍵組件。
2. 讀程式碼出現疑惑，可以通過調試去解開自己的困惑
我們讀的開源項目往往都很複雜。最典型的有三種情況:
- 方法變數不知其意
- 邏輯跳轉繞來繞去
- 封裝對象層次太深
而以上的情況，都只能通過程式碼調試才能解決。
三、抽絲剝繭
全貌、核心脈絡知道了，項目運行起來了，你心裡說，這下我要讀程式碼了吧？
錯，你還差一步，那就是細化目標。
我前面說過，我們讀源程式碼的目的有三類:
- 提升自己
- 修復 bug
- 添加新功能
但是，這些目的過於模糊了。提升自己，那讀哪些程式碼能提升自己？修復 bug，讀哪些程式碼能修復 bug？添加新功能，讀哪些程式碼能把新功能加上？
所以，得把這些有效的程式碼選出來。如何選呢？
當我們從事開發工作，聽得最多的一件事就是把問題分解：把大問題分解成小問題，分而克之。
選擇並閱讀有效程式碼也是一樣的。
對於過大的程式碼量，過多的功能，我們緊要的一件事兒就是把比較模糊的目標分解成能具體落地的精準的小目標。這些小目標對應到項目中，其實就是項目的一個一個的業務流程。
比如我們想給 logback 添加個新功能，能讓公司的日誌列印出統一的固定格式。看看我們如何做:
1. 縱向分解
縱向分解就是在我們已知的架構圖上分解出來一條條縱向的業務流程。
由於我們想統一公司的日誌格式，那肯定就需要在列印到文件前，把日誌內容格式化好。所以，業務流程就應該選擇從應用日誌調用 logback 列印日誌開始，一直到日誌內容輸出到目標文件結束的業務流程。
2. 橫向擴展
橫向擴展定下了我們如何組合業務流程，從而可以完整的達成咱們開始定下的大目標。
比如，這裡就可以定下在看完 logback 列印日誌的流程後，再去看看 logback 的日誌是如何切換的。
四、騰龍入海
好了，現在我們終於要開始看程式碼了。
但是看程式碼也是要講究技巧的，並不是上來就瞎翻瞎看。
1. 請將我心照明月
首先，我們曾經細化了目標，抽出了一條完整的業務流程。有此之後，我們就可以把業務流程和程式碼邏輯給映射起來。
看看logback的情況:
2. 一入侯門深似海
業務關係映射完畢，我們就能開始讀程式碼了。在讀程式碼的時候，我們還需要掌握幾個技巧:
技巧一：程式碼一定跳著看
有件事我們得明白，不是所有的程式碼都值得仔細看的。我們最優先的，就是看正向流程的，核心的程式碼，其餘程式碼皆可以跳過。
可以跳過的程式碼大概有:
-
判斷異常輸入的程式碼——這類程式碼對咱們理解系統意義不大，等到以後想提升自己編碼能力的時候，可以回頭專門找一些優秀的程式碼集中學。
-
出錯處理和異常狀態處理的程式碼——和上面理由一樣。
-
數據處理的程式碼——往往就是解析輸入數據，包裝輸出數據，有些時候還用 DTO 或者 DAO 方式去傳遞數據。這些程式碼有些很複雜，也很長，讀了之後，耗費精力、擾亂思維不說，往往對掌握項目原理毫無幫助，務必跳過。
-
底層交互的程式碼——老實講，底層交互技術含量是很高的，需要很多的底層知識。一時半會兒也無法彌補，而且一旦讀不懂了，對信心打擊很大，建議跳過。
技巧二：調用關係需確定
在看程式碼的時候，有一些方式會嚴重我們讀程式碼。
如果你一旦讀程式碼發現你找不到後續流程了，就得考慮考慮，作者是不是用了非順序調用方式去調用後續方法或者對象。
一般來說，開發人員常用以下幾種方式做非順序調用:
- 通過中間件繼續後續流程，比如 MQ
- 通過非同步方式繼續後續流程，比如 Future 模式、Promises 模式
- 通過回調方式繼續後續流程
- 通過代理委託方式繼續後續流程，比如動態代理
- 通過依賴注入方式繼續後續流程，比如 Spring 的 autowired 註解
這些非順序調用會嚴重影響我們閱讀程式碼。而對於這幾種情況，解決的辦法大概有兩種:
- 直接猜——其實後續流程我們在做業務流程映射到實際的程式碼對象的時候已經大概知道了，如果是介面，我們看看實現類不多，就可以大概挨個看下，一般都能猜著是哪個。
- 運行起來調試下——這種辦法是很普遍的，對任何不確定的任何事情，其實都可以用這個方式。
技巧三：超難演算法放最後
對於某些開源項目，它會採用很多經典的演算法。很經典，當然也很難。
但是，對於理解整體項目來說，這些演算法會嚴重阻礙我們的進程。我建議這些演算法，可以先記下來位置。在後續集中就著演算法資料，慢慢理解。
上面是 logback 日誌文件分割的演算法，在理解業務流程時，不建議馬上去理解演算法，可以放在後面自己另外定個目標理解。
以上就是我多年來一直沿用的程式碼閱讀套路。
總結下
首先，閱讀程式碼之前，我們應該對項目的全局做一個了解。我們可以從官方文檔、民間部落格之類的去加快了解全局的速度。最好能參考一些架構圖、時序圖，如果沒有現成的圖，最好能自己畫出一些來。
然後，我們把項目運行起來，運行起來才能有助於我們後續的調試，才能有助於我們快速的理解那些難懂的程式碼段。
再後，把我們的目標細化成一條條業務流程。沒有這些業務流程，我們一下子去讀大片大片的程式碼，第一沒有清晰的脈絡，第二也沒有可及的任務目標……結果就是一片混亂。
最後，才開始去真正的讀程式碼。而讀程式碼，我們應該有技巧的讀，要知道如何跳過某些程式碼，要知道如何技巧的找到後續調用流程，還要知道如何把一些困難去集中攻克。
正是通過這種套路，我讀程式碼不僅速度快，而且理解夠深入。
另外，程式碼讀的多了，還有一大好處：當我在設計項目架構的時候，寫一套框架的時候，不自覺就會浮現出類似的項目或者程式碼塊來。
總之，讀程式碼令我獲益頗多，這也是我職業生涯比較順利的重要原因之一，也在此希望幫助到後來者。
如果你覺得這篇文章對你有幫助，請幫忙點個贊，一個小小的點贊也算是對我原創的支援。
你好，我是四猿外。
一家上市公司的技術總監，管理的技術團隊一百餘人。
我從一名非電腦專業的畢業生，轉行到程式設計師，一路打拚，一路成長。
我會把自己的成長故事寫成文章，把枯燥的技術文章寫成故事。
歡迎關注我的公眾號，關注之後還可以獲取演算法、高並發等乾貨學習資料。
我建了一個讀者交流群，裡面大部分是程式設計師，一起聊技術、工作、八卦。歡迎加我微信，拉你入群。
