在 legacy code 中工作時，常常面對一個根本問題：看不懂程式碼。程式碼可能很長、命名不佳、結構混亂，讓你不敢貿然修改。本章提供幾個實用的技術來幫助你理解程式碼。

Notes/Sketching（筆記與畫圖）#

最基本也最有效的方法：拿一張紙或白板，邊讀邊寫邊畫。

• 畫出類別之間的關係圖
• 記錄呼叫的流程
• 標記你不確定的部分
• 寫下你的假設和疑問

不需要正式的 UML 圖或任何標準格式。重點是邊讀邊思考的過程，而不是產出漂亮的圖。即使最後把筆記丟掉，你在繪製過程中已經理解了很多。

Listing Markup（程式碼標記）#

直接在程式碼列印稿或螢幕上標記：

• 圈出重要的部分：關鍵的條件判斷、變數賦值
• 畫線連結相關區塊：哪段程式碼呼叫哪段
• 用不同顏色或符號標記：例如標記「這裡我不確定」或「這裡可能有 bug」
• 標記 responsibilities：在 margin 寫下每段程式碼的職責

這個技術特別適合處理大型方法——它幫助你在視覺上分解一個巨大的方法。

Scratch Refactoring（試驗性重構）#

Scratch refactoring 是一個強大的理解技術：大膽地重構程式碼，但不打算保留這些改變。

做法#

1. 確保你的改動可以輕易撤銷（使用版本控制）
2. 開始重構：提取方法、重新命名、移動程式碼
3. 不用擔心測試——目的是理解而非改善
4. 理解完成後，撤銷所有改動
5. 帶著新的理解，用正確的方式重新進行改變

Scratch refactoring 的關鍵是：這些改動不會被保留。 因此你可以更大膽，不需要擔心破壞東西。提取方法時不用想完美的命名，只要能幫助你理解程式碼結構就好。

為什麼有效#

• 重構迫使你仔細閱讀每一行程式碼
• 提取方法的過程迫使你思考「這段程式碼在做什麼」
• 重新命名迫使你為行為賦予意義
• 即使最後撤銷了，你的腦中已經建立了程式碼的心智模型

一定要在版本控制下進行 scratch refactoring。最簡單的方式是在開始之前確認所有變更已 commit，結束後直接 revert。千萬不要不小心保留了 scratch refactoring 的結果——它們沒有測試保護，可能引入 bug。

Delete Unused Code（刪除未使用的程式碼）#

如果你在理解程式碼的過程中發現有些程式碼從未被呼叫，最好的做法是刪掉它。

• 未使用的程式碼會增加閱讀和理解的負擔
• 它會誤導你以為某些功能還在運作
• 版本控制會保留歷史——如果將來需要，隨時可以找回來

許多人不敢刪除程式碼，因為「也許以後會用到」。但這種心態的代價是：每個讀到這段程式碼的人都要花時間理解它，卻發現它其實沒在用。版本控制系統就是你的安全網——放心地刪除吧。

總結#