如何較好地理解別人寫的程序？

---

理解代碼並不是一個「讀」的過程。而是一個：

1. 假設，
2. 設計驗證方法，
3. 驗證，如果驗證失敗重新假設。

的過程。

提出假設需要對代碼進行第一步的閱讀。設計驗證方法包括：

1. 對代碼進行一定的修改，並驗證所期待的結果；
2. 用 debugger 驗證系統內部狀態。

所以理解代碼最好是以加入新功能或者 fix bug 為目的，因為可以天然的選擇上面第一步的目標，而不用設計一些「artificial」的目標。

不要期待能理解一個產品的整個 code base。否則你就不是在前人的基礎上增加價值，而是重複前人的工作了 —— 試想你也不會總是試圖理解自己寫完的已經封裝良好的代碼。

---

第一步：建立第一印象。

自行下載（源代碼）、編譯、安裝、運行、玩弄這個程序。

第二步：

當有人為你講解的時候，建議先從整體上了解這個程序：

1. 了解這個程序的功能，用於解決什麼問題？

2. 了解這個程序的輸入和輸出。比如從形式（WS or DB）、格式 (XML or JSON)和使用的框架（WCF or Remoting）
3. 了解程序中的模塊（如果有分的話），最好有一張整體設計圖供參考。並理清圖中模塊與代碼之間的對應關係。
4. foreach(模塊 in 程序)
5. 了解本模塊的輸入和輸出
6. 了解本模塊與其它模塊之間的依賴關係，包括：
7. 依賴什麼？（數據？事件？）
8. 為什麼依賴？（要完成的功能需要這個？還是沒擦乾淨的屁股？）
9. 依賴關係如何建立的？
10. 對本模塊執行第4步
11. 分析模塊間冗餘的依賴關係，尋找可能的模塊構建方案。（先不用看代碼，這步只是要了解這個程序內部是怎麼完全他需要完成的功能的）

如果沒有人為你講解，但是代碼寫得不錯，建議從源代碼結構和測試代碼入手：

1. 良好的代碼有著明晰的代碼結構。單看文件名、文件夾名就可以把模塊分出來。（當然，依賴關係不明）（此條並不適用於C、C++代碼，這幫程序員的命名風格多半停留在Dos時代。）
2. 從測試就可以了解每個模塊的功能。（不過比較花時間）
3. 從JIRA或是BugTrace之類的地方找些簡單的Bug。嘗試修掉。

一般而言，編寫良好的代碼不太會出現看不懂的情況。（代碼即文檔）（C語言除外）

如果看不懂了（又覺得自己IQ並沒有小於120）那你是不是了解代碼中用到的所有語言特性、技術或框架，如C#的Expression Tree，Spring，WPF，Structs，WCF之類，先去了解這些代碼中用到的東西再回來看代碼。如果你已經了解這些知識，卻還是看不懂。

參考下面步驟。

沒有人為你講解，現有代碼又非常爛

1. 如果你有信心和能力：向領導反映情況，說看代碼的時間足以讓你寫個新的出來了。並向用戶了解程序需求。（永遠不要小瞧爛代碼的破壞力。）
2. 如果你沒有信心，但是有能力：向領導說明情況，讓來他做決定。但是要讓他明白，修Bug可能只要1分鐘，但是找到Root cause的位置可能要1個月。
3. 如果你有信心，但是沒有這個能力：向領導說明情況，讓他做好充分的心理準備你無法如期達成目標。你要做的心理準備是，如果他覺得渾身不適，可能會Fire你。
4. 如果你沒有信心也沒有這個能力：向領導承認錯誤，並嘗試讓他給你換個職位。

---

@馮東已經說的很好了，我再強調一下裡面的一個關鍵字"debugger"

---

如果有條件：

1.與原作者直接交流。

2.參考設計文檔。

了解作者如何思考並解決關鍵問題。

只有代碼時：

1.從程序的初始化代碼開始讀起，並添加trace印證自己的想法。

2.或從外部介面開始讀起，比如界面上的響應代碼或某一層次的API。

3.從自己感興趣的部分讀起，比如要實現這個功能一定要如何如何。

另外：

閱讀代碼時多留意數據結構和abstract/interface設計，儘可能用事實驗證想法。

---

跟(debug)著讀。

---

看API文檔, 看設計圖(依賴關係), 然後再去看程序. 如果僅僅是用好別人的工具的話, 盡量不要用自己的思維方式去強套作者的思維方式, 儘可能不去改原作者的程序, 與他平心靜氣的溝通, 了解那麼的做的真實意圖和他擔憂的細節.

---

捨棄偏見，捨棄觀點。看就是了。

---

Agree with 馮東"s point.

對於業務邏輯複雜的代碼，如果有對應的功能測試代碼可以運行，可以對著case去讀代碼。

對codebase有了大體的了解之後，可以在基礎上做一些改動或者bug fix，但是最好遵行之前code owner的風格，這樣對自己理解代碼也有更大的好處。

---

只看 core 和 util 命名的源代碼文件，以及特定業務流程源代碼文件

---

UML圖,沒有的話就看代碼圖,看依賴調用關係,分析出邏輯線路,然後再針對性地去看某一點

---

推薦閱讀：