作為一個程式員，經常需要讀一些開源專案的原始碼，同時呢，讀原始碼對我們也有很多好處:

1.提升自己

閱讀優秀的代碼，第一可以提升我們自身的編碼水平，第二可以開拓我們寫代碼的思路，第三還可能讓我們拿到大廠 offer，無論那種情況，優秀的代碼就是提升我們開發水平的資糧，而把這些優秀的代碼讀懂、讀透并不很容易，

2.修復 Bug

有些時候，我們用的一些開源組件，出現了一些預想不到的問題，而這時候，也沒有前人經驗可借鑒，也沒有檔案可供參考，只能靠自己修復，閱讀代碼，理解專案，才能順利修復問題，如果閱讀代碼水平不夠，修復 Bug 這事兒就成了個棘手的事兒，影響咱們的作業，

3.增加新功能

在作業中，我們會遇到翻遍開源庫也沒有特別合適的組件的情況，這就只能對現有的組件進行改造，而這種改造的前置條件就是去理解開源組件，這時候，我們只能去閱讀代碼，

讀原始碼好處很多，但是，讀原始碼本身不是件簡單的事，

相反，這是件非常困難的事情，一般來說，讀代碼比較困難的情況體現在:

• 代碼讀起來太枯燥，讀了一會兒就犯困、犯糊涂；
• 代碼讀了很長時間，結果發現不知道得到了什么，花了時間卻什么也沒學到，讀了個寂寞；
• 一個開源組件，讀代碼就花了好幾天，就這也才弄懂了一兩個檔案里的代碼，結果耽誤了正常作業，

自我作業以來，長期和各種開源組件打交道，也被迫讀了許多的代碼，在經歷了以上種種困難之后，花費了好幾年的時間，我才算總結了一套自己的打法，才算能真正的去快速的讀懂、讀透許多開源組件，

恰好也有許多讀者朋友問起我該如何讀代碼，所以，我決定把我總結的一些套路寫出來，望能給大家一些幫助，能更快的提升自己，

那我們來看看我個人讀代碼的一些辦法，

一、縱覽全域

閱讀代碼之前，首先我們要用上帝視角去看原始碼，用上帝視角目的在于去了解這個組件的全貌，

全貌包括：

1. 開源專案的主要用途

我們要知道專案主要是用來干嘛的，因為這是專案的終極目標，

所有開源專案的原始碼本身都是為了這個終極目標才寫出來的，

例如，對于 logback 而言，它的用途就是打日志，而它所有的代碼無論多復雜，終極目標就是要讓 logback 能健壯高效的列印出日志來，

2. 專案的架構

了解專案架構的價值在于，能了解系統的層次結構，就能理出專案的核心脈絡，有了核心脈絡，我們就能把有限的時間用在閱讀最有價值的代碼上，

如果專案的官方檔案有架構圖，那么就從官方的架構圖去了解專案的整體架構，如果檔案中沒有架構圖，就去搜一下有沒有民間大神畫出來，如果還沒有，可以根據官方檔案的描述，自己畫出來架構圖，

以 logback 為例，由于官方沒有提供架構圖，我根據檔案大概畫了一個架構圖，

二、把玩無厭

摸清楚了系統的核心脈絡，我們還需要把專案運行起來，

運行專案有兩個目的:

1. 知道這個專案運行前有哪些必須的前置條件

還是回到 logback 的例子上，

當我們能成功運行 logback 后，其必然存在了一個 logback.xml 檔案，否則無法運行，

這個 logback.xml 檔案其實對于我們看原始碼非常重要，它點出了 logback 需要的關鍵元素，

并且，如果讀原始碼遇到了困惑，明白了這個組態檔，就能有效幫助我們跨過障礙，后面談到如何具體的讀原始碼時再細說，

上面是一個基本的 logback 配置，里面列出了 logback 運行需要的關鍵組件，

2. 讀代碼出現疑惑，可以通過除錯去解開自己的困惑

我們讀的開源專案往往都很復雜，最典型的有三種情況:

• 方法變數不知其意
• 邏輯跳轉繞來繞去
• 封裝物件層次太深

而以上的情況，都只能通過代碼除錯才能解決，

三、抽絲剝繭

全貌、核心脈絡知道了，專案運行起來了，你心里說，這下我要讀代碼了吧？

錯，你還差一步，那就是細化目標，

我前面說過，我們讀源代碼的目的有三類:

1. 提升自己
2. 修復 bug
3. 添加新功能

但是，這些目的過于模糊了，提升自己，那讀哪些代碼能提升自己？修復 bug，讀哪些代碼能修復 bug？添加新功能，讀哪些代碼能把新功能加上？

所以，得把這些有效的代碼選出來，如何選呢？

當我們從事開發作業，聽得最多的一件事就是把問題分解：把大問題分解成小問題，分而克之，

選擇并閱讀有效代碼也是一樣的，

對于過大的代碼量，過多的功能，我們緊要的一件事兒就是把比較模糊的目標分解成能具體落地的精準的小目標，這些小目標對應到專案中，其實就是專案的一個一個的業務流程，

比如我們想給 logback 添加個新功能，能讓公司的日志列印出統一的固定格式，看看我們如何做:

1. 縱向分解

縱向分解就是在我們已知的架構圖上分解出來一條條縱向的業務流程，

由于我們想統一公司的日志格式，那肯定就需要在列印到檔案前，把日志內容格式化好，所以，業務流程就應該選擇從應用日志呼叫 logback 列印日志開始，一直到日志內容輸出到目標檔案結束的業務流程，

2. 橫向擴展

橫向擴展定下了我們如何組合業務流程，從而可以完整的達成咱們開始定下的大目標，

比如，這里就可以定下在看完 logback 列印日志的流程后，再去看看 logback 的日志是如何切換的，

四、騰龍入海

好了，現在我們終于要開始看代碼了，

但是看代碼也是要講究技巧的，并不是上來就瞎翻瞎看，

1. 請將我心照明月

首先，我們曾經細化了目標，抽出了一條完整的業務流程，有此之后，我們就可以把業務流程和代碼邏輯給映射起來，

看看logback的情況:

2. 一入侯門深似海

業務關系映射完畢，我們就能開始讀代碼了，在讀代碼的時候，我們還需要掌握幾個技巧:

技巧一：代碼一定跳著看

有件事我們得明白，不是所有的代碼都值得仔細看的，我們最優先的，就是看正向流程的，核心的代碼，其余代碼皆可以跳過，

可以跳過的代碼大概有:

• 判斷例外輸入的代碼——這類代碼對咱們理解系統意義不大，等到以后想提升自己編碼能力的時候，可以回頭專門找一些優秀的代碼集中學，
  

• 出錯處理和例外狀態處理的代碼——和上面理由一樣，
  

• 資料處理的代碼——往往就是決議輸入資料，包裝輸出資料，有些時候還用 DTO 或者 DAO 方式去傳遞資料，這些代碼有些很復雜，也很長，讀了之后，耗費精力、擾亂思維不說，往往對掌握專案原理毫無幫助，務必跳過，
  

• 底層互動的代碼——老實講，底層互動技術含量是很高的，需要很多的底層知識，一時半會兒也無法彌補，而且一旦讀不懂了，對信心打擊很大，建議跳過，
  

技巧二：呼叫關系需確定

在看代碼的時候，有一些方式會嚴重我們讀代碼，

如果你一旦讀代碼發現你找不到后續流程了，就得考慮考慮，作者是不是用了非順序呼叫方式去呼叫后續方法或者物件，

一般來說，開發人員常用以下幾種方式做非順序呼叫:

• 通過中間件繼續后續流程，比如 MQ
• 通過異步方式繼續后續流程，比如 Future 模式、Promises 模式
• 通過回呼方式繼續后續流程
• 通過代理委托方式繼續后續流程，比如動態代理
• 通過依賴注入方式繼續后續流程，比如 Spring 的 autowired 注解

這些非順序呼叫會嚴重影響我們閱讀代碼，而對于這幾種情況，解決的辦法大概有兩種:

• 直接猜——其實后續流程我們在做業務流程映射到實際的代碼物件的時候已經大概知道了，如果是介面，我們看看實作類不多，就可以大概挨個看下，一般都能猜著是哪個，
• 運行起來除錯下——這種辦法是很普遍的，對任何不確定的任何事情，其實都可以用這個方式，

技巧三：超難演算法放最后

對于某些開源專案，它會采用很多經典的演算法，很經典，當然也很難，

但是，對于理解整體專案來說，這些演算法會嚴重阻礙我們的行程，我建議這些演算法，可以先記下來位置，在后續集中就著演算法資料，慢慢理解，

上面是 logback 日志檔案分割的演算法，在理解業務流程時，不建議馬上去理解演算法，可以放在后面自己另外定個目標理解，

以上就是我多年來一直沿用的代碼閱讀套路，

總結下

首先，閱讀代碼之前，我們應該對專案的全域做一個了解，我們可以從官方檔案、民間博客之類的去加快了解全域的速度，最好能參考一些架構圖、時序圖，如果沒有現成的圖，最好能自己畫出一些來，

然后，我們把專案運行起來，運行起來才能有助于我們后續的除錯，才能有助于我們快速的理解那些難懂的代碼段，

再后，把我們的目標細化成一條條業務流程，沒有這些業務流程，我們一下子去讀大片大片的代碼，第一沒有清晰的脈絡，第二也沒有可及的任務目標……結果就是一片混亂，

最后，才開始去真正的讀代碼，而讀代碼，我們應該有技巧的讀，要知道如何跳過某些代碼，要知道如何技巧的找到后續呼叫流程，還要知道如何把一些困難去集中攻克，

正是通過這種套路，我讀代碼不僅速度快，而且理解夠深入，

另外，代碼讀的多了，還有一大好處：當我在設計專案架構的時候，寫一套框架的時候，不自覺就會浮現出類似的專案或者代碼塊來，

總之，讀代碼令我獲益頗多，這也是我職業生涯比較順利的重要原因之一，也在此希望幫助到后來者，

如果你覺得這篇文章對你有幫助，請幫忙點個贊，一個小小的點贊也算是對我原創的支持，

你好，我是四猿外，

一家上市公司的技術總監，管理的技術團隊一百余人，

我從一名非計算機專業的畢業生，轉行到程式員，一路打拼，一路成長，

我會把自己的成長故事寫成文章，把枯燥的技術文章寫成故事，

歡迎關注我的公眾號，關注之后還可以獲取演算法、高并發等干貨學習資料，

我建了一個讀者交流群，里面大部分是程式員，一起聊技術、作業、八卦，歡迎加我微信，拉你入群，

標籤：其他

上一篇：Java面試題(二)：JDK、JRE和JVM的關系

下一篇：Java 中的 Unsafe 魔法類，到底有啥用？