技術債

軟體系統容易累積雜質，也就是內部品質的缺陷，使得修改和擴充系統比理想狀況更困難。技術債是 Ward Cunningham 創造的比喻，用來構思如何處理這些雜質，並將其視為一種財務債務。新增功能所需的額外工作量就是支付債務的利息。

想像一下，我的程式碼庫中有一個令人困惑的模組結構。我需要新增一個新功能。如果模組結構很清楚，那麼我需要花四天才能新增這個功能，但有了這些雜質，我需要花六天。兩天的差距就是債務的利息。

債務比喻最吸引我的地方，在於它構思了我如何處理這些雜質。我可以花五天時間清理模組結構，移除那些雜質，比喻上就是償還本金。如果我僅針對這一個功能這麼做，那沒有好處，因為我需要花九天而不是六天。但如果我有另外兩個類似的功能即將推出，那麼我事先移除雜質會比較快。

這樣說來，這聽起來像是一個簡單的數字運算問題，任何有試算表的經理都應該能找出答案。遺憾的是，由於我們無法衡量生產力，這些成本沒有一個是客觀可衡量的。我們可以估計完成一個功能需要多長時間，估計如果移除雜質會變成什麼樣子，以及估計移除雜質的成本。但我們對此類估計的準確度相當低。

有鑑於此，通常最好的方法就是做我們通常對待財務債務所做的事，逐步償還本金。在第一個功能中，我會花額外的幾天時間來移除一些雜質。這可能足以將未來增強功能的利率降低到一天。這仍然需要額外的時間，但透過移除雜質，我讓日後變更此程式碼的成本更低。這種漸進式改善的優點是，它自然而然地表示我們會花更多時間在移除我們經常修改的區域中的雜質，而這些區域正是程式碼庫中我們最需要移除雜質的區域。

將此視為支付利息與償還本金，有助於決定要處理哪些雜質。如果我有一個程式碼庫中的可怕區域，一個難以變更的夢魘，如果我不必修改它，那就不成問題。只有當我必須使用軟體的那個部分時，我才觸發利息支付（這是比喻失靈的地方，因為財務利息支付是由時間流逝觸發的）。因此，雜亂但穩定的程式碼區域可以保持原樣。相反地，高度活動的區域需要對雜質採取零容忍的態度，因為利息支付會造成癱瘓。這一點尤其重要，因為雜質會累積在開發人員不注意內部品質的情況下進行變更的地方 - 變更越多，雜質累積的風險越大。

債務的比喻有時被用來合理化忽視內部品質。論點是，阻止雜質累積需要時間和精力。如果有緊急需要的新功能，那麼或許最好負債，接受未來必須管理此債務的事實。

這裡的危險在於，大多數時候這種分析做得不好。雜質會產生快速影響，減慢非常需要的新功能的速度。這樣做的團隊最終會將所有信用卡刷爆，但仍比他們投入更多精力於更高的內部品質時所做的時間還晚。在這裡，比喻常常讓人們誤入歧途，因為動態並未真正符合財務貸款的動態。負債以加速交付只在您低於DesignStaminaHypothesis的設計回報線時才有效，而團隊在幾週而不是幾個月內就會達到該線。

經常有不同的爭論，關於不同種類的技術債務是否應視為債務。我發現思考債務是否故意取得，以及是否審慎或魯莽，對我很有幫助，這讓我想到技術債務象限。