作為一個程式設計師，經常需要讀一些開源專案的原始碼。同時呢，讀原始碼對我們也有很多好處:
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 日誌檔案分割的演算法，在理解業務流程時，不建議馬上去理解演算法，可以放在後面自己另外定個目標理解。
以上就是我多年來一直沿用的程式碼閱讀套路。
總結下
首先，閱讀程式碼之前，我們應該對專案的全域性做一個瞭解。我們可以從官方文件、民間部落格之類的去加快了解全域性的速度。最好能參考一些架構圖、時序圖，如果沒有現成的圖，最好能自己畫出一些來。
然後，我們把專案執行起來，執行起來才能有助於我們後續的除錯，才能有助於我們快速的理解那些難懂的程式碼段。
再後，把我們的目標細化成一條條業務流程。沒有這些業務流程，我們一下子去讀大片大片的程式碼，第一沒有清晰的脈絡，第二也沒有可及的任務目標……結果就是一片混亂。
最後，才開始去真正的讀程式碼。而讀程式碼，我們應該有技巧的讀，要知道如何跳過某些程式碼，要知道如何技巧的找到後續呼叫流程，還要知道如何把一些困難去集中攻克。
正是通過這種套路，我讀程式碼不僅速度快，而且理解夠深入。
另外，程式碼讀的多了，還有一大好處：當我在設計專案架構的時候，寫一套框架的時候，不自覺就會浮現出類似的專案或者程式碼塊來。
總之，讀程式碼令我獲益頗多，這也是我職業生涯比較順利的重要原因之一，也在此希望幫助到後來者。
如果你覺得這篇文章對你有幫助，請幫忙點個贊，一個小小的點贊也算是對我原創的支援。
你好，我是四猿外。
一家上市公司的技術總監，管理的技術團隊一百餘人。
我從一名非計算機專業的畢業生，轉行到程式設計師，一路打拼，一路成長。
我會把自己的成長故事寫成文章，把枯燥的技術文章寫成故事。
歡迎關注我的公眾號，關注之後還可以獲取演算法、高併發等乾貨學習資料。
我建了一個讀者交流群，裡面大部分是程式設計師，一起聊技術、工作、八卦。歡迎加我微信，拉你入群。
