在開篇，Martin Fowler 不急著定義重構，
而是透過一個簡單範例，展示重構的實際流程。
本章核心精神在於：重構是由一連串微小且獨立的變動所組成。
透過小步快跑（Small Steps），我們可確保改善程式碼結構時，隨時保持可運作狀態。
標準重構步驟#
作者在範例展示了嚴謹的重構順序，確保每步驟都在控制中：
flowchart LR
A["1️⃣ 準備測試<br/>(Check)"] --> B["2️⃣ 拆解函式<br/>(Extract)"]
B --> C["3️⃣ 變數命名<br/>(Rename)"]
C --> D["4️⃣ 優化變數<br/>(Remove/Query)"]
D --> E["5️⃣ 拆分階段<br/>(Split Phase)"]
E --> F["6️⃣ 引入多型<br/>(Polymorphism)"]| 重構行動 | 目的 | 技巧 |
|---|---|---|
| 準備測試 (Check) | 建立安全網，確保邏輯一致 | 自動化驗證 |
| 拆解函式 (Extract Function) | 依「完整行為」拆解成小區塊 | 每次拆解後執行測試 |
| 變數命名 (Rename Variable) | 提升可讀性 | 回傳值命名為 result |
| 優化變數 (Remove/Query Variable) | 移除不必要的區域變數 | 減少暫存變數降低依賴 |
| 拆分階段 (Split Phase) | 依任務階段進行隔離 | 分離計算與輸出邏輯 |
| 引入多型 (Polymorphism) | 用類型區隔計算情境 | 取代冗長的 Switch/If-else |
判斷程式碼好壞的關鍵，在於它
是否清楚明瞭（Human-readable）以及是否易於修改（Modifiable）
關於命名#
函式名稱即文件： 一個命名良好的函式，應讓閱讀者不需看內文就能理解其功能。
這也是自我記錄（Self-documenting）程式碼的基礎。
關於重構時機#
困難是重構的信號： 當你想新增功能，卻發現因現有結構複雜而困難重重時，
這就是個訊號：先重構，再開發 。先將結構整理好，新功能的加入就會順理成章。
重構過程中，不需過度考慮效能問題。
先專注讓程式碼結構清晰、易於理解。效能優化應在重構完成後，針對特定瓶頸進行的獨立步驟。