[程式碼異味 #6] 技術負債：Cunningham 所說的原始含義

核心答案： 技術負債是 Ward Cunningham 在 1992 年創造的詞，原本指的不是骯髒的程式碼，而是程式碼與目前理解之間的落差。

Cunningham 強調，負債策略要能奏效，程式碼反而必須保持乾淨。

開發者向非開發者解釋重構時，常會拿出一個詞：技術負債。

這是接續上一篇文章程式碼異味 #5的內容。

意思是：為了快速完成而借了債，利息正在增加，所以請給我們時間償還。

但最初創造這個詞的人曾多次說明，他的比喻正被錯誤使用，尤其是把骯髒的程式碼稱為負債。

1992 年，Ward Cunningham

「技術負債」這個說法是 Ward Cunningham 在 1992 年首次使用的，出現在 OOPSLA（Object-Oriented Programming, Systems, Languages & Applications，物件導向程式設計學會）的經驗報告中（論文）。

就是那位以發明 Wiki、以及作為極限程式設計早期人物而廣為人知的 Cunningham。

當時他正在開發金融軟體。困難之處在於領域本身。

你不可能在開始前就完全正確地理解金融商品的結構。因此，他選擇先根據當下的理解完成並推出產品，再把使用過程中學到的內容持續反映到程式碼裡。

他所說的負債就在這裡產生：目前程式碼所包含的理解，與團隊實際已經獲得的理解之間的差距。

一開始撰寫時正確的結構，等更了解領域後回頭看，可能已經不再合適。這就是負債；讓程式碼符合新理解，就是償還。

2009 年，他留下了一段短片，再次說明這個比喻並糾正誤解。重點如下（Debt Metaphor）。

背負負債是為了快速學習的策略，不是允許你寫出糟糕程式碼的許可。事實上，負債策略要能運作，程式碼必須乾淨。

因為程式碼一旦骯髒，連反映所學內容這件事本身都會變得不可能。

這就是重點：在原始概念中，即使是寫得好的程式碼也會產生負債。

因為隨著時間經過，我們理解世界的方式改變時，負債就會自動產生。

相較之下，今天許多人稱為技術負債的東西，其實只是隨便寫出的程式碼。按照 Cunningham 的論點，那與其說是負債，不如說只是混亂的狀態。

Fowler 的四象限

不過，如果劃線規定「只有真正的負債才算負債」，在實務上就很難使用。Martin Fowler 在 2009 年整理的四象限很好地填補了這個落差（Technical Debt Quadrant）。

它使用兩條軸線：有意還是偶發，以及魯莽還是謹慎。

	魯莽	謹慎
有意	「沒有時間設計」	「現在先上線，代價之後再承擔」
偶發	「什麼是分層？」	「現在才知道原本應該怎麼做」

四個格子的性質完全不同。

有意・謹慎是管理上的判斷。有截止日期，延遲就會錯失機會，同時也清楚知道之後必須付出成本，仍然做出選擇。

這是最精準符合負債比喻的格子。

但有一個條件：知道代價是什麼。

偶發・謹慎就是 Cunningham 所說的原始負債。已經盡力做好，六個月後對領域有了更深理解，才看見更好的結構。

即使沒有做錯任何事，也會發生。這個格子無法避免，因此除了建立償還週期之外沒有其他對策。

有意・魯莽是明知故犯地草率處理。雖然常被稱為負債，但因為沒有償還計畫，比起負債更接近損失。

偶發・魯莽是因為不知道而變成那樣。這裡的解法不是安排重構，而是學習。

即使是同樣骯髒的程式碼，也會因所在格子不同而採取不同對策。團隊談論負債時經常對不上焦點，很多時候是因為彼此想的是不同格子。

利息要用什麼支付

金融負債的利息是金錢，技術負債的利息則是未來的變更成本。如果新增相同功能，沒有負債時需要一天，有負債時需要三天，那多出的兩天就是利息。

採用這個定義後，可以得到一個結論：不會碰觸的程式碼，其負債利息是 0。

一個五年來沒有人修改的模組，即使再髒，只要未來也不會修改，就沒有償還的理由。相反地，每週都會碰觸的畫面裡，即使很小的負債也會持續產生利息。

很多團隊會以「有多糟」排序負債清單，但實際標準應該是「多久會碰一次」。

上一篇使用的 Git 變更頻率查詢在這裡同樣有用。經常變更的檔案與品質不佳的檔案重疊之處，就是利率最高的地方。

Adam Tornhill 將找出這個交集並排定優先順序的方法稱為以行為為基礎的程式碼分析。

這個比喻的限制

「技術負債」這個詞很方便，問題也正出在這裡。任何東西都可以塞進去。

Bug、過時的函式庫、不喜歡的設計、不是自己寫的程式碼，全都會被稱為負債。如此一來，這個詞就成了「想修理的東西」的同義詞，也失去了原本的解釋力。

只有通過兩個問題時，稱它為負債才有實用性。

1. **你為了得到什麼而背負它？**必須能說明你是爭取到時間，還是獲得了學習。如果什麼都沒得到，那不是負債，而是錯誤。
2. **要如何償還？**沒有償還計畫的債務，這個比喻就無法成立。

也有人反對這個比喻本身。因為「負債」一詞給人「總有一天還掉就好」的印象，掩蓋了實際上可能以複利膨脹到無法償還的情況。

有些人建議改稱污染或衛生問題，理由是它更接近必須持續清理的東西，而不是償還就能結束的東西。

不過，「負債」這個詞能長久存在是有原因的。它是少數能與開發之外的人溝通的比喻之一。

Cunningham 最初提出這個比喻時，也是為了向上司說明需要重新作業的情境。它不是精確術語，但作為翻譯工具仍然有價值。

實務上的管理方式

**可以列出清單，但不要把它埋在議題追蹤器裡。**只收集負債票券的待辦清單，通常沒有人會看。

另一種方法是留在程式碼附近。在相關檔案中簡短記下為什麼會變成這樣、需要什麼，下一個開啟該檔案的人一定會看到。

**碰到時順便償還。**你反正要修改該檔案時，就是利息產生的時點，也是脈絡仍在腦中的時點。

這就是童軍規則，也就是「離開時要比來時更乾淨」，作為負債管理方法確實有效的原因。

**決定不償還也是管理。**負債清單有一半不是償還對象，而是記錄對象。

明確決定不償還的項目，可以避免下次重複相同的討論。

**有意背負時，也要一起記下條件。**例如「上線後兩週內」、「使用者超過 1 萬人之前」。

沒有時間點的負債，也就沒有償還時間。

總結

• 技術負債是 Ward Cunningham 在 1992 年創造的詞，原本指的不是骯髒的程式碼，而是程式碼與目前理解之間的落差。
• Cunningham 強調，負債策略要能奏效，程式碼反而必須保持乾淨。
• Fowler 的四象限以有意性與謹慎程度分成四格。每一格的對應方式都不同。
• 利息是未來的變更成本。不會碰觸的程式碼，其負債利息為 0，因此沒有償還的理由。
• 如果無法說明得到了什麼、要如何償還，那就不是負債，而只是問題。

下一篇將討論當負債累積到難以承受時的選擇：修好繼續使用，還是重新打造。

這也是軟體業界產生最昂貴錯誤答案的地方之一。

來源與確認標準

• The WyCash Portfolio Management System — Ward Cunningham · 論文原文 · 確認 2026-08-17 · 依據：1992 年技術負債比喻的原始說明
• Debt Metaphor — Ward Cunningham · 作者原文 · 確認 2026-08-17 · 依據：2009 年 Ward Cunningham 對技術負債比喻的解說
• Technical Debt Quadrant — Martin Fowler · 作者原文 · 確認 2026-08-17 · 依據：以謹慎・魯莽與有意性區分的技術負債四象限

延伸閱讀

程式碼異味系列

• 上一篇：[程式碼異味 #5]散彈槍手術 vs. 發散式變更
• 上一篇：[程式碼異味 #4]上帝物件（God Object）完整整理
• 上一篇：[程式碼異味 #3]義大利麵程式碼：沒有人知道流程的程式碼