技術債務象限

過去幾個月來，關於 技術債務 的文章已經發表了一些，這引發了一個問題，即哪些類型的設計缺陷應該或不應該歸類為技術債務。

一個很好的例子是 Uncle Bob 的文章，其中提到 混亂並非債務。他的論點是，由不了解良好設計實務的人員產生的混亂程式碼不應該是債務。技術債務應該保留在人們經過深思熟慮後決定採用長期而言無法持續，但會產生短期利益的設計策略時，例如進行版本發布。重點是，債務會較快產生價值，但需要盡快償還。

在我看來，設計缺陷是否為債務的問題是錯誤的。技術債務是一種隱喻，因此真正的問題在於債務隱喻是否有助於思考如何處理設計問題，以及如何傳達這種思考。債務隱喻的一個特定好處是，它非常方便與非技術人員溝通。

我認為債務隱喻在兩種情況下都能發揮作用 - 差別在於債務的性質。混亂是一種魯莽的債務，會導致沉重的利息支付或長期的本金償還。我們有幾個專案，我們接手了一個負債很高的程式碼庫，發現這個隱喻在與客戶管理層討論如何處理時非常有用。

債務隱喻提醒我們在設計缺陷方面可以做出的選擇。如果利息支付足夠少，那麼為了達到版本發布而產生的審慎債務可能不值得償還 - 例如，如果它位於程式碼庫中很少觸及的部分。

因此，有用的區別不在於負債或非負債，而在於謹慎和魯莽的負債。

在我剛才概述的範例中，還有另一個有趣的區別。不僅謹慎和魯莽的負債有所不同，預謀和無意的負債也有所不同。謹慎的負債範例是預謀的，因為團隊知道他們正在承擔負債，因此會思考一下提前償還的回報是否大於償還的成本。不了解設計實務的團隊在不知不覺中承擔了魯莽的負債，甚至沒有意識到自己陷入了多大的困境。

魯莽的負債可能並非無意的。團隊可能知道良好的設計實務，甚至有能力實踐它們，但決定採取「快速且粗糙」的方式，因為他們認為自己無法負擔撰寫乾淨程式碼所需的時間。我同意 Uncle Bob 的說法，這通常是一種魯莽的負債，因為人們低估了DesignPayoffLine在哪裡。良好設計和乾淨程式碼的重點在於讓你更快地進行 - 如果沒有，像 Uncle Bob、Kent Beck 和 Ward Cunningham 這樣的人就不會花時間討論它了。

將負債分為魯莽/謹慎和預謀/無意，意味著一個象限，而我只討論了三個單元格。那麼，謹慎無意的負債存在嗎？雖然這種事情聽起來很奇怪，但我相信它是存在的 - 而且對於優秀的設計師團隊來說，這不僅是常見的，而且是不可避免的。

我最近和一位同事聊到他剛結束的一個專案。該專案交付了有價值的軟體，客戶很滿意，而且程式碼很乾淨。但他對程式碼不滿意。他覺得團隊做得很好，但現在他們了解設計應該是什麼樣子了。

我總是從最優秀的開發人員那裡聽到這句話。重點在於，當你在編寫程式時，你正在學習。通常情況下，在專案上編寫一年的程式後，你才能了解最佳的設計方法應該是怎樣的。也許應該計畫專案花一年時間建立一個系統，然後丟棄並重建，正如 Fred Brooks 所建議的那樣，但這是一個難以推銷的計畫。相反，你會發現，當你意識到設計應該是什麼樣子的時候，你同時也會意識到自己有筆無意的負債。這正是 Ward 在他的影片中所談到的那種負債。

支付利息與償還本金的決定仍然適用，因此這個比喻仍然有助於這個案例。然而，使用債務比喻的問題在於，我無法想像與承擔謹慎無意的財務債務的相似之處。因此，我認為很難向經理解釋這筆債務是如何產生的。我的觀點是，這種債務是不可避免的，因此應該是預期的。即使是最好的團隊在專案進行時也會負債 - 更有理由不要魯莽地用爛程式碼來過度載入它。

於 2014 年 11 月 19 日重新發布