閱讀優秀項目源碼很重要,分享一個讀源碼的方法,小白都能學會

作爲一個程序員,經常需要讀一些開源項目的源碼。同時呢,讀源碼對我們也有很多好處:

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 日誌文件分割的算法,在理解業務流程時,不建議馬上去理解算法,可以放在後面自己另外定個目標理解。

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

總結下

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

然後,我們把項目運行起來,運行起來纔能有助於我們後續的調試,纔能有助於我們快速的理解那些難懂的代碼段。

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

最後,纔開始去真正的讀代碼。而讀代碼,我們應該有技巧的讀,要知道如何跳過某些代碼,要知道如何技巧的找到後續調用流程,還要知道如何把一些困難去集中攻克。

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

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

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


你好,我是四猿外,一家上市公司的技術總監,管理的技術團隊一百餘人。

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

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

歡迎關注我的公衆號,關注後回覆【666】可領取我整理的一些珍藏技術資料。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章