重構：第一個範例 (Refactoring: A First Example) #
在本書開篇，Martin Fowler 並不急著定義重構的抽象概念，而是透過一個簡單範例，展示重構的實際操作流程。
本章的核心精神在於：重構是由一連串微小且獨立的變動所組成。 透過這種小步快跑（Small Steps）的方式，我們可以確保程式碼在結構改善的同時，隨時保持可運作的狀態。
重構的標準執行步驟 #
作者在範例展示了嚴謹的重構順序，確保每步驟都在控制中：
| 核心重構行動 | 目的與原則 | 關鍵注意事項/技巧 |
|---|---|---|
| 準備測試程式碼 (Check) | 重構的第一步和最關鍵的安全網。確保重構後的程式邏輯與原先一致 | 確保能自動化驗證修改後的程式是否運作正常 |
| 拆解並提取函式 (Extract Function) | 將冗長的程式碼依據「完整的行為」拆解成獨立的小區塊 | 原則： 每做完一個小幅度的拆解，就必須執行測試，確保功能未被破壞 |
| 變數重新命名 (Rename Variable) | 提升程式碼的可讀性 | 技巧： 例如將函式的回傳值統一命名為 result，讓讀者能一眼識別其用途 |
| 優化區域變數 (Remove/Query Variable) | 調整或移除不必要的區域變數 | 過多的暫存變數往往是提取函式的阻礙，容易讓程式碼依賴性過高 |
| 拆分階段 (Split Phase) | 將邏輯依據不同的任務階段進行實體隔離 | 範例： 將「計算邏輯」與「格式化輸出」拆分成兩個獨立的檔案或模組，降低耦合度 |
| 引入多型 (Polymorphism) | 使用資料類型 (Type) 來區隔相異的計算情境 | 建立多型計算器 (Calculator) 來處理對應的任務，取代原本冗長的條件判斷式 (Switch/If-else) |
判斷程式碼好壞的關鍵，在於它是否清楚明瞭（Human-readable）以及是否易於修改（Modifiable）
關於命名 #
- 函式名稱即文件： 一個命名良好的函式，應該讓閱讀者不需要看內文就能理解其功能。這也是自我記錄（Self-documenting）程式碼的基礎。
關於重構時機 #
- 困難是重構的信號： 當你想要新增功能，卻發現因為現有結構複雜而困難重重時，這就是個訊號：先重構，再開發 。 先將結構整理好，新功能的加入就會變得順理成章。
進行重構的過程中，不需過度考慮效能問題。
先專注讓程式碼結構清晰、易於理解。效能優化應是在重構完成後，針對特定瓶頸進行的獨立步驟。