債務這個詞，相信大家已經都對其深有體會了，特別是像我一樣作為“房奴”的人，每個月都要去銀行還錢，那就是債務啊。

　　在軟件開發的過程中，我們往往也會借債，人們稱之為技術債務，其實也就是為了快速地解決問題，而采取的不規范的方案。比方說把某個條件寫死，再比方說采用一些捷徑達到目的，而這只是特殊情況，無法應用在其他模塊中。

　　對于房貸，大家肯定每個月都會記著去還，但是對于技術債務，大家似乎就不那么關心了，的確這個東西不一定是誰借誰還，可能一個人的代碼中產生了技術債務，然后由于負擔太重，閃人了，那沒有辦法，這筆債務就會壓在后來工作接替者身上，古語說：父債子償，不知道這應該叫什么。

　　然而，技術債務其實最終的承擔者還是系統的所有者，或者說系統的開發商。而且，技術債務有一個致命的特點，與我們的房貸不同，而與一種很可怕的借款——我們稱之為高利貸——相同，那就是會利滾利。試想一下，如果我們在一個類中欠下了技術債務，然后之后的程序又對這個類進行了擴展和修改，再后的程序對擴展后的程序又做出了更大的擴展，或者說后來的程序在一些功能的寫法上參照了欠下債務的類，那么這個債務就會產生非常大的利息，甚至于超過了債務本身。用不了太多時間，我們就會發現，已經無力償還這份技術債務了。

　　上面所提到的還只是在功能上的技術債務，我覺得技術債務遍布于我們的系統開發過程之中。比方說：

　　在代碼規范上也存在技術債務，如果一個程序員為了快速開發或者修改一個功能，在開發的時候沒有遵守代碼規范，那么此時就會欠下代碼規范方面的債務。如果不盡快償還的話，那么之后的基于該程序的修改，也會有很大的可能不遵守代碼規范，這也正是破窗子理論的體現。這樣下去，程序的可維護性就會大大降低，直至不可維護。

　　在文檔上也存在技術債務。現在很多的開發團隊中還是存在技術文檔的，像詳細設計什么的。如果一次開發中，由于時間緊，只修改了代碼，而沒有修改相關的文檔，那么必定就會造成文檔和實際代碼功能上的不一致。這樣做的后果就是，在一段時間之后，我們會發現文檔根本就不足以作為參考，因為有些時候不僅不會幫助我們，而且還會造成誤導，從而大家對文檔都失去了信心。

　　從上面的種種我們可以看出，欠下技術債務，而疏于修改，后果會非常嚴重，那么我們應該怎么做呢？其實道理很簡單，首先是盡量不要欠下技術債務，其次就是一旦迫不得已欠下了債務，就應該以最快的速度償還。我們在銀行借的房貸，5年還和20年還，利息會相差很多，對于技術債務，也是同樣，如果盡快償還，那么不會付出太大的代價，而且是在我們的能力承受范圍之內的，但是如果拖的時間太長，債務就會變得越來越多，直至我們無力償還。

　　所以，作為程序員，除了關心自己生活中的債務之外，也請對技術債務提高警惕！