重構觀念入門：為什麼優秀工程師都在持續重構？

Martin Fowler 的經典名著《重構：改善既有程式碼的設計》連續兩年蟬聯電腦書暢銷榜，足見重構對開發者的重要性。但什麼是重構？簡單說：在不改變外部行為的前提下，透過調整程式碼結構，提升軟體品質、效能、擴充性與維護性。

為什麼不一開始就設計完美？

許多人會問：專案伊始為何不花更多時間把設計做好？現實是：

• 不存在完美預見未來的設計：架構師只能掌控大方向，細節無法盡知。
• 需求永遠在變：使用者往往在軟體成型後才開始「品頭論足」。
• 設計腐敗是常態：缺乏重構，程式碼會像斷線風箏、脫韁野馬般失控。

因此「測試優先、持續重構」成為現代開發鐵律，像黃河護堤般守護軟體品質。

重構能帶來什麼具體價值？

1. 持續修正與改進設計

重構與設計互補。有了重構，前期設計只需「合理」而非「最優」；沒有重構，設計必然腐化。重構本質是整理程式碼，讓發散傾向的代碼歸位。

2. 讓程式碼更易被人理解

Fowler 名言：「任何傻瓜都能寫出電腦看懂的程式，只有寫出人類易讀的程式才是優秀工程師。」晦澀命名、缺乏註解、混亂排版，都會讓接手者想當逃兵。命名即文檔，善用隱喻命名（依功能意象命名），像命名新生兒般嚴謹對待每個代碼元素。

3. 發現隱藏缺陷

重構迫使你深度理解舊代碼。許多工程師都有「寫完自己都不懂邏輯」的經驗，這其實是常態。重構過程中能發現邏輯漏洞、邊界條件疏漏，重構出更健壯的代碼。

4. 長遠提升開發效率

解決問題覺得異常複雜時，往往是設計拙劣導致。良好設計是成功一半；停下來重構雖暫緩速度，卻帶來不可低估的後發優勢。

何時該動手重構？識別「代碼壞味道」

Kent Beck 提出的「代碼壞味道」即是重構信號。當開發經理發現隊伍「變形」時，就是整頓時刻：

• 重複代碼：同類別重複 → 提煉方法；跨類別重複 → 提煉新類。絕不重複建設。
• 過大類別、過長方法：抽象層級不當、邏輯過度耦合。拆分小方法，分而治之。
• 牽一髮動全身：微小修改引發連鎖反應，抽象層級不足或功能過度分散。
• 類別間過度通訊：A 頻繁存取 B 內部資料，或許應合併。
• 過度耦合的資訊鏈：層層轉呼叫像輸油管，檢視可移除的中介層或提供直接呼叫。
• 各自為政：團隊溝通不足導致功能重複（如專案出現三個字串處理類）。
• 不完美設計：隨專案演進浮現，唯有勇於修改才是出路。
• 缺乏必要註解：記憶曲線陡峭，事後補註解極難。微軟代碼註解詳盡程度堪稱標竿。

結語

重構不是大動手術，而是日常整理習慣。下次看到壞味道，別猶豫——動手重構，讓代碼保持健康、可讀、可維護。