無論你是否喜歡把它想成技術債務或是對衝期權，在我們的周圍都充斥著糟糕的程式碼，糟糕的決定，以及這些東西給我們每天的生活帶來的影響。但是這些決定所帶來的長期影響會是什麼？我們真的做了明智的選擇嗎？Martin Fowler談論了技術債務的四種型別：從魯莽的、故意的到偶然的、謹慎的。
故意不計後果的債務
故意不計後果的技術債務就是這樣的：開發者（或者他們的經理）會允許那些只可能帶來壞結果不可能帶來好結果的決定被通過—例如，放棄TDD或者不用任何設計。無論從什麼角度來看，這種做法都是非常不專業的。如果開發人員不能做出正確的選擇，那麼管理者就應該介入，並帶入一些能夠做明智選擇的人進來。Michael Norton將這稱為“令人討厭的行為，而不是技術債務”。如果我們不能從中受益，並且只是簡單地完成任務，寫一些糟糕程式碼，那麼這根本不是技術債務，這是垃圾。
不易察覺的債務
不易察覺的技術債務比較有趣。如果我們不知道有更好的東西，我們又怎麼會去做一些改變呢？工業標準和最佳的實踐都在不斷髮展。我確定曾經某段時間EJB被認為是很好的元件模型，但現在它絕對被認為是不折不扣技術債務。當前的最佳實踐方式很容易就變成未來的垃圾程式碼。
當開始時，如果我們就已經有了這個領域的知識，或者可能我們從未在這個領域工作過，沒有這個領域的知識，可能設計出來的東西會不太相同。有些時候技術債務是不可避免和必然發生的。
謹慎故意的債務
接下來是謹慎而有意的技術債務，這種情況下，我們會有意做一個決定來增加技術債務。這裡就有一個再普通不過的決定：
“不管怎樣，我們要達到這個季度的目標利潤。
我們的市場工作已經開始，所以我們必須在短的時間內搶佔市場。
我們已經承諾了交貨日期，所以沒有太多時間給我們去犯錯誤。”
有時，我們必須做一些妥協：通過降低工作成果的品質，我們可以更快的完成工作，但我們會稍晚時候付出代價。
不同於其它的技術債務，這是一種特殊的技術妥協。我們故意做決定讓程式碼質量比我們能夠達到的質量要差。我們知道這會在以後讓我們慢下來；我們知道我們需要回來重做，在所謂的“二期工程”裡完善它；但是為了在規定的時間內完成任務，我們接受妥協。
它始終都是正確的決定嗎？
1、 妥協在短期來看更快，但在長期來看其實更慢
在我們現在就需要的東西與後續可能產生的不明的債務之間做選擇時—顯而易見，我們始終都會選擇妥協。
2、每個妥協都看似渺小，但它們積累起來卻非常龐大
不管有多少人都經歷過“欠債”，技術債務都會積累起來。我們所做的每次妥協都會增加已有債務的代價。這意味著，每次妥協的代價可能很小，但積累起來後它們會產生巨大的影響。
一開始，我決定不重構一些程式碼。下一輪時，由於沒有很好的重構，很難測試程式碼，所以我跳過了一些單元測試。第三輪時，我的測試覆蓋率非常低，所以我沒有信心進行擴充套件性重構。現在，這段程式真的變得很難測試也很難修改。我的程式碼在一點一點地，越來越快地惡化。每個妥協都堆積在以前的妥協之上，而且將它們放大。每次妥協看似影響很小，但它們累加起來卻讓人大傷腦筋。
3、 長期的代價很難被量化
當我們同意不重構一段程式碼時，當我們同意留下一些半成品時，當我們同意為了急於通過測試而採用最小測試項時：這真的很難去估計長期的代價。當然，我們能夠估算如何做是正確的—我們知道什麼是“真理”。但是，我們如何去估計成本的支出？特別是當它們積累起來時。
我怎麼能估計為了解決複雜問題而浪費的時間？時間的損失有可能是因為一個非常難以追查的bug。額外花費的時間可能是因為下一次我無法很容易地重構程式碼；或者是因為下一次我不敢重構程式碼，但額外的債務使我不得不這樣去做。我怎麼可能去量化這個問題？
在IMVU，他們發現他們：
“至少低估了一個量級的技術債務的長期代價”
它始終都是錯誤的嗎？
這裡有一些很明顯的例子，它們都在產生技術債務；或者至少做得有些不稱職。如果你想在客戶面前展示一個新特性以判斷其是否有價值，那麼它不需要很完美，它只需要迅速地出現在那裡就行。如果新特性對客戶沒用，那麼你將其刪除。你節省了將其做“完美”的成本，並迅速獲得了你所需要的資訊。這顯然是符合成本控制的，是一種管理開發過程的簡易方式。
但是，如果展示的這個特性獲得成功了呢？那麼，你需要制定一個計劃清理它，重構它，確保它產生足夠的文件並被充分的測試。這就是債務。只要你有一個刪除它的計劃，無論這個特性是有用或無用—那麼這是一個完美而有效的方式。但如果不是這樣，那麼這個半成品特性可能需要數年時間去構建程式碼。
不同的是，我們會有一個計劃來消除債務。多久我們就會接受一個模糊的承諾“我們會回過頭來修復它”，或者，“我們會在第二階段完善它”。我的墓誌銘應該是“現在開始第二階段的工作”。
在程式碼中留下債務，且沒有任何消除債務的計劃，就像一個傢伙用一張信用的錢去還另一張信用卡的錢。你讓債務產生，而不去處理它。沒有償還債務的計劃，你最終將走向破產。
技術債務的風險
也許技術債務最大的危害是它代表的風險。技術債務使得我們的程式碼更加脆弱，不太容易修改。當我們最近討論這個問題時，正如@bertvanbrakel所說：
“技術債務會使程式碼變得僵化”
在我們程式碼上堆積的債務越多，程式碼就越難改變。這種僵化會帶來最大的風險：我們無法足夠快速地改變程式碼。如果競爭環境和監管環境突然變化？如果一個新的競爭對手出現，徹底改變了我們的行業，我們需要多久才能趕上？如果我們只有一個僵化的程式碼庫，在我們花2、3或4年時間趕上競爭對手時，我們又能得到什麼呢？
當然這是指的最壞的情況，這種靈活性的缺失（缺乏創新）會一點一點地損害公司。一旦一個革命性的公司變成老古板，無法作出反應，並只釋放衍生產品。當公司發現自己無法創新，跟不上不斷變化的局勢—它們就會變得無關緊要。這也就是技術債務真實的代價。
沒有一個償還技術債務的計劃，沒有可靠的辦法來估計它所帶來的長期成本，我們真的可能做出謹慎而故意的決定嗎？這種輕易就能增加技術債務的決定做得是否太草率了呢？
原文：David Green 編譯：伯樂線上 – 肖翔
譯文連結：http://blog.jobbole.com/17899/
【如需轉載，請標註並保留原文連結、譯文連結和譯者等資訊，謝謝合作！】