1 - 初始能力

讓閱讀思路清晰連貫，保持在程序的流程架構和邏輯實現上，不被語法、編程技巧和業務流程等頻繁地阻礙和打斷。

• 語言基礎：熟悉基礎語法，常用的函數、庫、編程技巧等；
• 了解設計模式、構建工具、代碼風格；
• 了解業務背景和邏輯；

即便此時，還不具備完全理解代碼的能力，但通過接觸這些代碼，至少可以熟悉項目的樣貌。

2 - 工具使用

• Source Insight - 具有強勁的代碼瀏覽和分析功能
• Doxygen - 項目文檔工具
• grep命令 - 用于全局搜索
• 利用代碼結構分析功能或插件生成UML圖
• Python Call Graph - 生成python函數調用關系圖
• 代碼轉換成流程圖 - 在線工具
• 瀏覽器插件Octotree - 直觀顯示Github項目樹形結構
• 瀏覽器插件Git History - 直觀顯示Github項目歷史記錄
• ......

3 - 準備動作

明確問題與需求:

• 為什么要閱讀源代碼？要解決什么具體問題？要達到怎樣的程度和效果？
• 當前狀態（初始能力、資源投入等）如何？是否足夠支撐開始并完成這樣的代碼閱讀？
• 沒有目標和無法完成的閱讀，就難以獲得實際的收獲；

對于知名項目，收集規整已有的代碼分析資料；

確認輔助信息來源：官方文檔、項目文檔、搜索引擎等；

確認代碼版本（早期版本或當前能夠理解的版本）和編碼風格；

......

4 - 一些方法和注意事項

“因地制宜，因人而異”。
問題需求、資源投入、項目狀態的不同，適用的閱讀方法和工具自然也就不同。
直接啃代碼的方式適合解決具體的細節問題，簡單粗暴，速度快效果好。
但如果想完整而深入地了解一個有規模和難度的項目，又該如何進行呢？

一些方法：

• 閱讀“README”；
• 通過查看提交和版本日志，研讀所關注的功能和優化；
• 搭建測試環境并運行Demo或示例，觀察運行狀態，從外部了解核心功能和運行方式，形成總體認知；
• 善用文檔：quickstart、tutorial等內容中的示例往往是非常有效的了解途徑；
• 整體把握，分層閱讀：先整體后局部，借助工具生成UML圖或流程圖等，從整體了解代碼結構和調用關系，確定閱讀的層次和順序；
• 尋找程序入口，根據實際情況確定閱讀的切入點；
• 逐行或者逐個函數跟蹤變量值；
• 為代碼寫注釋，解釋各個函數的使用方法，各個變量的用途，以及任何其它方面的內容，只要能幫助理解代碼即可。必要時形成文檔；
• 問題列表：記錄疑問和問題并歸納成表，解決問題的過程也就是代碼逐漸清晰的過程；
• 查看單元測試，編寫測試用例，拋異常，Debug所關注的執行過程，觀察現象和日志，明確調用關系和執行路徑；
• 它山之石，可以攻玉。借鑒代碼，解決當前實際問題。
• ......

注意事項：

• 帶著問題與需求閱讀代碼，圍繞根本和主干，沒有必要通讀源碼，更不應該沉陷于細節；
• 必要時略過難以理解的地方，不過度糾結于某一行某一段；
• 理解項目作者的思考方式，
• 低頭專注代碼，抬頭思考架構，從整體的角度來看待局部實現的過程；
• ......

5 - 下一步

• 迭代式理解
  軟件是成長起來的，而不是搭建完成的。
  對項目代碼的理解，只是當時的理解，受限于當時的技能水平，知識結構，資源投入，甚至是身心狀態。
  經過一段時間磨礪和成長，回頭再閱讀同樣的項目代碼，往往會有新的發現和理解。

• 改善適用性
  “學以致用”是獲得知識技能的最有效途徑之一。
  實現自己的需求和想法，最終形成更適合的版本。
  在現有“輪子”的基礎上去制造“一個更完善輪子”，在這樣的二次開發過程中，可以驗證代碼理解。

• 獲得建議與批判
  落后的起源是“故步自封”、“自以為是”和“自欺欺人”。
  歸納并分享你的理解，會獲得更全面更專業更中肯的建議與批判。
  爭議之中，也恰恰隱含著成長與改變的線索與機遇。

6 - 多余的話

每個人都是某一方面的菜鳥，某一細節的白癡。
It’s not the languages that matter but what you do with them.（編程語言這東西并不重要，重要的是你用這些語言做的事情。）

轉載于:https://www.cnblogs.com/anliven/p/7545983.html

總結

以上是生活随笔為你收集整理的Tools - 一些代码阅读的方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。