為什麼要重構而非重寫#

很多人想重寫整個 code base，但原因往往不好：原始碼可能是 prototype、課堂作業、趕工的 demo，久而久之變成一團亂麻。整個體系變得極其脆弱，再也不可能添加代碼。老程式設計師憤而辭職，新人根本弄不懂，只好層層包裹舊代碼。

Joel 反對推倒重來。他選擇花 3 個月時間徹底把代碼整理一遍，採用**重構（refactoring）**的精神，而非推倒重寫。

重構的三條規則#

Joel 為這次練習制定了嚴格的規則：

1. 不添加任何新功能
2. 無論何時向原始碼庫提交代碼，都要保證程式依然能完善地運行
3. 所做的只是合乎邏輯的變換（logical transformation），幾乎都是機械性的，不會改變代碼行為

FogBugz 的重構實踐#

FogBugz 誕生六年來，從一個 ASP 編程練習，逐漸演變成公司內部使用的 bug 追蹤系統。代碼中存在大量問題：

• SQL 語句散布在 HTML 代碼中
• HTML 寫得不規範，針對老式瀏覽器
• 軟體內部代碼「混亂無序」，根本無法解讀
• 想為故障追蹤的主表增加一欄，就需要修改 50 個地方

具體的重構工作#

• 將所有 HTML 修改成 XHTML（<BR> 改為 <br />，屬性加引號，標籤配對）
• 移走所有格式標籤（<FONT> 等），改用 CSS 樣式表
• 從表現層代碼中移走所有 SQL 語句和程序邏輯
• 改善設計類別結構，消除重複代碼
• 將英語說明文字從代碼中移出，建立多國語言支持
• 重構 ASP 站點結構，做到全站只有一個入口

重構的優點#

重構方法相較於推倒重寫，有以下關鍵優勢：

• 耗時大大少於一次徹底的重寫（假設重寫需要一年，重構只需 3 個月，節省了 49 個工作週）
• 沒有引入任何新的錯誤：因為每一步都是簡單的邏輯變換
• 任何時候都可以停下來交付程式
• 工作進度完全可預測：每小時整理的代碼行數穩定
• 在現有代碼中加入新功能變得容易多了

經過 3 個月的重構，幾乎每一行代碼都不一樣了，但對最終使用者來說表面差別並不大。整個程序的結構已經完全不同，所有的錯誤追蹤功能與 HTML 的使用者介面已經完全分離。