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