Brian Sletten — Fairfax, Virginia, USA

技術債的本質#

在財務世界，**債務（debt）**是一種有用的工具——用未來的盈餘換取現在的資金。善用短期債務可以平滑現金流的波動；但若管理不當，就會成為越背越重的枷鎖。

軟體開發也有完全相同的邏輯。Ward Cunningham 提出了「技術債（technical debt）」的概念：在衝刺迭代（iteration）末期或截止日期前，開發者若時間不夠，可以先採用捷徑，讓程式碼「夠用」但不夠理想——等同於向未來借了時間。

補充： 技術債本身並不邪惡。在可控的情況下短期借用時間，是合理的工程決策。問題在於：借了不還。

技術債的滾雪球效應#

如果技術債不被償還：

• 程式碼品質持續惡化
• 每次修改都越來越痛苦
• 最終開發者會舉手宣告需要「重寫（start over）」——這等同於宣告軟體破產

常見的技術債來源包括：

• 快速修補（hacks）：能跑但不優雅的解法
• 文件不足
• 不當的相依關係（inappropriate dependencies）
• 偏離原始設計意圖的捷徑

如何有紀律地管理技術債#

技巧： 在每次迭代結束時，請開發人員明確列出這次欠下的技術債，並估算清償所需的時間。不必立即還清，但要記錄在案、排入後續迭代計畫。

確保提出的是具體的程式問題，而不是籠統的「需要一些時間」——這不是偷懶的機會，而是維持程式碼庫健康的紀律。

重點： 將每次迭代的工作負荷設計為兼顧「新業務功能」與「償還技術債」兩者並行，才能避免技術債失控，同時持續滿足客戶的功能需求。

向業務利益相關方溝通#

技術債的比喻對非技術的業務利益相關方（business stakeholders）非常有說服力。

• 用「貸款」解釋為何程式碼會隨時間變得難以維護
• 用「最低還款額」說明定期維護的必要性
• 用「破產」說明長期積累技術債的後果

現代軟體分析工具（如程式碼覆蓋率分析、耦合分析、風格偏差偵測）也能自動識別技術債的所在位置，讓管理更有依據。

注意： 若開發者宣稱需要「從頭重寫整個系統」，這幾乎都是技術債長期積累、未受管理的後果。定期少量還款，遠勝過一次巨額破產。

附註：迭代（Iteration） — 敏捷團隊選定的短期開發週期（通常 1 至 4 週），每個週期完成一個可交付的功能並獲取客戶回饋。

附註：快速修補（Hack） — 能解決問題但不夠理想的程式碼，通常需要在未來有時間時重新整理。