本節對應原書第 8 章末段「The People」與全書貫穿的軼事彙整——強調償債最終靠的是人與文化。

為什麼「人」決定了一切#

「人是軟體專案真正的心臟與靈魂——軟體本身會反映出開發團隊的素質與承諾。」

工具能偵測壞味道、流程能規範重構節奏，但若團隊沒有「重構的意識」與「品質的承諾」，所有方法論都會失效。書中提出三種建立重構文化的方法。

訓練（training）#

Fred Brooks 在《人月神話》中建議用短期課程為未來任務培訓潛在從業者。

書中作者的經驗呼應此說法：

  • 聚焦的工作坊比一般授課更能提升設計意識。
  • 內容應涵蓋設計原則、設計壞味道、重構三大主軸。
  • 動手實作比純講授有效得多。

研討會與工作坊#

  • 邀請業界思想領袖演講可激起團隊熱情。
  • 內部重構工作坊讓專案團隊分享真實案例與教訓——比外來顧問的建議更貼近實務。

以身作則（leading by example）#

訓練與研討會固然重要，但最有效的方式是 role model 親身示範。

書中強調的反面案例：

一個 team-lead 或架構師若只口頭強調設計品質、自己卻不在程式碼中實踐——只會打擊團隊士氣。

結語：以身作則才是組織內形成品質文化最有效的方法。

全書貫穿的真實案例回顧#

整本書透過軼事與案例，把「壞味道 → 技術債」這條因果鏈具體化。整理幾則最具代表性的：

12 年產品的重構困境（第 1 章）#

  • 客戶端／伺服器邏輯共用一份程式碼、緊耦合、無介面。
  • 開發團隊根本沒聽過技術債——管理層怕影響交期。
  • 最終分階段重構，產品延遲半年、新功能縮水，但避免了技術破產。
  • 教訓：建立技術債認知是任何重構計畫的前提。

函式分解 vs. 物件分解（3.2 節）#

  • Diff 類別只有一個 findDiff() 方法 → 系統審查發現整個工具包都是「動詞 + 資料」結構。
  • 想全面重構時，因客戶端龐大，只能放棄。
  • 教訓：壞味道往往是更深問題的徵兆；越早察覺成本越低。

Image 類別的 SRP 爭辯（3.4 節）#

  • 50,000 行 / 120 個 public 方法的 Image 類別，團隊堅稱「都是與 image 有關 → 符合 SRP」。
  • 真正的責任是「一個變更原因」——後來拆出 ImageLoader、ImageRenderer、ImageProcessor、ImageWriter，變更被在地化。
  • 教訓：「責任」不是「功能的邏輯歸類」；是變更的原因。

醫療軟體的 40,000 行類別（5.2 節）#

  • 跨國團隊新增類別需經總部核可，流程冗長 → 開發者乾脆把所有功能塞進既有類別。
  • 教訓：流程設計者必須讓「正確的事」容易做。否則團隊會繞過流程，損失更大。

新創公司的相依糾纏（5.3 節）#

  • 架構師離職後，新人在交期壓力下開發 → 跨層相依、Business Logic 跑進 UI。
  • 最終發布前一刻仍能跑，但每改一行都可能弄壞別處。
  • 後來凍結開發、重構幾個月才得以繼續。
  • 教訓：必須有專責架構師守護整體結構；技術債若不定期償還，最終會把專案卡死。

多執行緒應用的重構崩潰（8.2 節）#

  • 「Extract method」後所有測試通過 → 上線幾月後崩潰。
  • 重構誤改了執行緒終止邏輯；多執行緒的不確定性使測試無法捕捉。
  • 教訓：自動化測試之外，人工 review 不可省略——尤其是關鍵或多執行緒模組。

結語：把重構變成日常#

這本書的核心訊息可以濃縮成一句話： 辨識壞味道 → 理解違反的原則 → 套用合適的重構 → 持續做。

培養「check-in code better than what you checked-out」的習慣，把重構併入日常的 bug fix 與功能開發——比任何「大爆炸式重構」都更可行、更可持續。

Backward Tools And Practices