閱讀大型開源軟件的四個技巧
最近的一段時間里，我在研究 Android 配套工具和 Android Studio 相關(guān)的實現(xiàn)，以及它們?nèi)绾闻浜贤瓿梢粋€ APK 的構(gòu)建。因為整個系統(tǒng)各個模塊之間的關(guān)系過于復(fù)雜，除此，不同模塊之間也包含了大量的代碼 —— 無論是從行數(shù)上，還是從函數(shù)長度上來說。（PS：順便吐槽一句，?@google.com?的一部分人寫的代碼也是又臭又長）
從總體的思路上來說，在進(jìn)入代碼閱讀之前，我們需要：
理解代碼背后的業(yè)務(wù)流程 理解架構(gòu)設(shè)計的思想
從而我們才能理解主流程（脈絡(luò)）。針對于此，我們會發(fā)現(xiàn)一些不同的模式：
借鑒他人。從他人的學(xué)習(xí)筆記中，理解整體的思路和過程。如 Android APK 的構(gòu)建，Android 資源如何優(yōu)化，從中理清代碼閱讀的思路。 源碼學(xué)習(xí)。 借助測試調(diào)試。 fork 主流程。
它們并不是互相獨立的，往往是結(jié)合一起使用的。
借鑒他人
這種模式，可以實現(xiàn)快速地學(xué)習(xí)。它存在的一些明顯的缺點是：
學(xué)到的東西是二手加工過的。 部分的代碼可能與真實的情形脫節(jié)。
所以，它適用于你想快速了解某一部分的功能，從而了解全貌，隨后我們就可以深入某一部分進(jìn)行了解。
在這種模式之下，我推薦：通過購買、閱讀書籍的方式來學(xué)習(xí)。如果能買到書便是一件幸運的事，因為它已經(jīng)經(jīng)過了系統(tǒng)性的加工。唯一的問題可能是上面的代碼有些老舊。但是，它更加的系統(tǒng)化、完整，方便我們理解，并減少搜索資料的成本。
為什么不是網(wǎng)上找資料？：
找資料需要投入時間成本 資料不一定詳細(xì)
如果你能直接找到詳細(xì)的資料，畢竟花費的時間足夠短的話，那么也是沒問題的。
源碼學(xué)習(xí)
源碼學(xué)習(xí)是一個需要花費大量時間和精力的事情，除非萬不得已，否則我也不想用這種方式。因為，我們會缺少大量的上下文，這些上下文可能導(dǎo)致我們理解出現(xiàn)一些誤差。
前期準(zhǔn)備：
合適的工具。最好是~~收費的（?）~~能用上的。 合適的存儲空間。像 Android 這樣的系統(tǒng)，clone 下來就要 120G，編譯的話，估計得達(dá)到 200G 吧；而像 Android Studio 的源碼，clone 下來也要 60G。 尋找閱讀的模式。 嘗試去構(gòu)建應(yīng)用。它不一定可行，但是如果可以的話，會節(jié)省你大量的時間。
源碼學(xué)習(xí)是一個非常重的學(xué)習(xí)模式。我們要花費大量的時間：
在代碼間跳轉(zhuǎn) 梳理業(yè)務(wù)邏輯
所以，還有一些不錯的犯懶的姿勢：
通過書籍來加強(qiáng)。我一直覺得對于學(xué)習(xí)來說，閱讀書籍是最理想的方式。因為尋找資料需要成本，而多數(shù)的書都會起到一個索引的目的。 尋找相似的輪子。一個有意思的技術(shù)，必然有很多公司、很多人都研究過。他們都會嘗試去創(chuàng)造類似的輪子。唯一的問題是，我們要學(xué)習(xí)到什么程度，如果只是理解的話，那么看看別人重復(fù)的輪子也是可以的；如果是為了深入的話，那么還得回過頭去看看源碼
借助測試調(diào)試
對于調(diào)試來說，我們還會面臨的一個挑戰(zhàn)是：諸如我這樣的入門級 MBP 配置，對于大型系統(tǒng)來說編譯根本不夠用。應(yīng)對這種問題的一個比較良好的姿勢是：通過 IDE 調(diào)試測試來完成對部分代碼的調(diào)試。（PS：這種方式也適用于業(yè)務(wù)代碼的開發(fā)）
如果我們可以在應(yīng)用的入口中創(chuàng)建某一模塊對應(yīng)的測試，那么我們就可以快速調(diào)試整個應(yīng)用了。
fork 主流程
對于我來說，我覺得只閱讀源碼是一種只為了解決一時問題的方式。同時，像我這樣的凡人，對于某些知識和內(nèi)容，只要不使用，我可能隔個十天半個月，我就忘光了（雖然我一直覺得這是一件好事）。
邊閱讀代碼，邊 fork 項目，我們還會有一些挑戰(zhàn)：
語言的熟練度和模式。對于熟悉的語言來說，比如日常編寫業(yè)務(wù)代碼的時候，我們并不需要理解于諸如類加載器、元編程、字節(jié)碼這一類的復(fù)雜模式。 新的框架、工具或語言的學(xué)習(xí)成本。比如，我在過程中就遇到需要理解和學(xué)習(xí) Gradle 插件的一些構(gòu)建機(jī)制。 代碼中大量的、無用的異常處理的代碼。 別人的代碼都是 ?。（PS：一個月后自己的代碼也是屎）
所以，還有一些模式：
劃分模塊邊界。尋找架構(gòu)圖，通過架構(gòu)圖來劃分模塊。 切片化運行。一個模塊，一個模塊來理解整個系統(tǒng)。如 IDEA 插件的編寫、IDEA 插件與 Gradle 如何交互，Gradle 插件的原理與編寫，Gradle 如何調(diào)用其它命令行工具，命令行工具的原理與編寫。 通過測試運行。如針對于 ApkAnalyser 這樣的工具，我們可以通過單元測試而非構(gòu)建一個 CLI 的方式來運行。 選擇另外一門語言。因為別人用 Java、Groovy、Kotlin 編寫的應(yīng)用，如果你用 Rust、Go 再寫一遍的話，那么你就能一次學(xué)到兩個東西了：一個是新的編程語言，一個是這個開源項目的代碼。
README 輸出
為了方便我們查閱和其他/她人使用，我往往會把相關(guān)的內(nèi)容記錄到項目的 README 上。
相關(guān)的文檔資料
相似的開源項目
過程中的內(nèi)容產(chǎn)出
代碼簡要說明
……
這樣一來，其他/她人在學(xué)習(xí)的過程中還能 GET 到相似的思路。
結(jié)論
最后，簡單做一些成本對比：
| 模式 | 成本 | 性價比 | 主要場景 |
|---|---|---|---|
| 借鑒他人 | 低 | 高 | 學(xué)習(xí) |
| 閱讀源碼學(xué)習(xí) | 高 | 低 | 理解思想 |
| fork 主流程 | 高 | 低 | 理解、模仿 |
| 借助測試調(diào)試 | 較高 | 中 | 理解、模仿 |
一些結(jié)合模式：
閱讀二手資料，根據(jù)二手資料理解主脈絡(luò) 編寫主流程調(diào)用鏈，理解架構(gòu)設(shè)計理想 借助開源軟件的測試調(diào)試，理解參數(shù)及流程 ……
你呢，你有什么好用的模式？