根據我的經驗，所有偷過的懶都會補回來的！老老實實加班吧！該重構重構，該重寫重寫！當然，重寫基本是不可能的！

技術負債就好比修改和擴充套件軟體系統，每當新增新功能時，需要付出的額外努力就好像是債務利息一樣。那麼身為技術開發者，該如何償還技術負債？

軟體系統常常建立在內部質量有缺陷的程式碼之上，因此比理想情況下更難修改和擴充套件系統。技術負債是Ward Cunningham提出的一個比喻，形容這個問題就像金融債務一樣，新增新功能時，需要付出的額外努力就好像債務利息。

假設我的程式碼庫中有一個混亂的模組結構。此時，我需要新增一個新功能。如果這個模組結構清晰，那麼我只需要4天時間就可以新增好這個功能，但是如今這個模組的結構很混亂，所以我需要6天時間。多出來的這兩天就是債務利息。

關於債務的這個比喻最吸引我的地方在於，它讓我思考如何處理這個問題。假設我可能需要5天時間來清理這個模組化的結構，改好不健全的功能，這就相當於支付本金。如果只有這個功能需要用到這個模組，那麼就得不償失，因為我總共需要9天時間，如果我繼續容忍這個模組的話只需要6天。然而，如果有兩個相似的功能都用到了這個模組，那麼我肯定會首先改好這個模組來加快速度。

如此說來，聽起來這是個簡單的數字問題，凡是有電子表格的經理都應該能夠做出很好的選擇。遺憾的是，我們並不能很好地衡量我們的生產力，因此這些成本都無法客觀地衡量。我們可以估算完成一個功能需要多長時間，我們需要估算做新功能的時間（在改好模組後的情況下），以及改好這個模組的時間。然而，我們的估算的準確性非常低。

鑑於此，通常我們的做法是：揹負著負債繼續做新功能，並逐步支付本金。在做第一個功能的時候，我會花額外的幾天時間來修復一些不健全的功能。這可以將未來的利息降低到一天。雖然這之後我們仍然需要花費額外的時間，但是這些程式碼附帶的負債會降低。這種逐步改進的好處在於，如果我們頻繁地改動某個有待修改的負債，那麼就證明這些程式碼正是最需要被清理的區域。

這種用支付利息代替支付本金的方式，可以幫助我們決定優先解決哪個負債。假設有一個非常可怕的程式碼庫，修改這個程式碼庫簡直就是一個噩夢，如果我沒有必要動這個程式碼庫，那就不是個問題。只有當我用到這部分軟體時，才需要支付利息（這是這個比喻與金融上的負債不同的地方，因為金融的利息支付是由時間決定的）。因此，我們可以不必理會那些穩定的負債。相比之下，活躍度非常高的區域需要非常及時地修改，我們應該採取零容忍的態度，因為這部分債務的利息非常高。這一點非常重要，因為開發人員往往只知道一味地更改程式碼，卻不關注內部質量的時候，這些負債將不可避免地積累起來——程式碼變更越多，風險就越大。

有時，這種債務的比喻也可以判斷是否應該忽略內部質量。關鍵在於我們需要付出時間和精力才能阻止負債的積累。如果有些新功能非常迫切，那麼也許我們不得不繼續揹負債務，只有等到將來再來處理這筆負債。

然而，大多數時候我們的這種分析做得都不好。另一方面，技術負債的影響非常快，會迅速拖慢新功能開發的速度。不斷積累負債的團隊最終都會被自己的債務搞得一塌糊塗，大幅延遲交付，所以還不如趁早努力提高內部的質量。這個比喻往往會讓人誤解，因為這種發展趨勢與金融貸款並不完全相同。

人們經常會爭論是否應該將不同種類的質量問題視為債務。我覺得我們應該考慮這些債務是有意造成的，還是一時不小心造成的。