歡迎關注我的博客
翻譯
------"無論你做什麼，請謹慎的做，並且考慮這件事情的連續後果"---Anon
在軟件迭代的開始，無論進度開起來多麼的寬裕，你都無法避免來自時間上的壓力。如果你發現你必須在“正確的寫程序”和“快速的寫程序”之間選擇，那麼你往往會選擇“快速的做”，並給自己一個“以後再Fix它”的藉口。如果你對你自己，你的團隊，你的客戶做出這個承諾，那麼兌現他。但是，經常能看到的事情是在下一個軟件迭代週期中，我們需要解決新的問題，你也專注於解決新的問題。這種拖延工作的行爲我們叫做技術債。而這樣做並不好。更確切的說，Martin Fowler將這種情況叫做故意的技術債，和那些無意中的錯誤導致的技術債區分。
技術債就像是貸款：你會在短期取得很好的效果，但是終究你要連本帶利的還掉你的欠債。在代碼中的“捷徑”讓增加功能和重構代碼都變得更爲困難。這讓Bug蔓生，讓測試用例完成更困難。知道你修正這個技術債，你才能免去這一切煩惱。如果你正在着手修復一個源頭處的錯誤，這也許會引出一系列“不那麼正確”的設計。這會使代碼更難重構和修正。事實上，經常是代碼真的出錯了，你纔去修復它。那時候，這個開始是很小問題的“技術債”，已經變得很難去修復了。你的項目也不能承受修復這個債的時間和風險。
你有時候必須要欠下這種“技術債”，例如deadline將至或者實現一個很小的功能點。首先避免這種情況出現，但是如果出現了，那麼也只能欠下這個“債”了。但是（一個大大的但是），你必須記錄跟蹤這個“技術債”，並儘快的償還他。否則事情將迅速的變得不可控制。也就是，一旦你打算這樣做，那麼必須記錄到一張任務卡或者一個issue中，這樣才能保證你不會忘了這件事情。
如果你在下一個迭代週期中，打算償還這個技術債，那麼損失會最小化。如果你一直不償還這個技術債，那麼你同時需要記錄由於這個“技術債”而產生的“利息”，並量化它。這樣做會強調這個技術債的影響，並且可以量化“還債”的優先級。如何計算和跟蹤“利息”和具體項目有關，但是你必須這麼做。
及時的還清技術債。否則，這技術債便是輕率的行爲。
想法
------
- 慎行是一個很重要的事情。但是讓每個程序員時刻對自己要求嚴格，是一件很刻薄的事情。
- 一個人如果切實瞭解這件事的價值，那麼一定會去做。
- 中國的教育，註定了中國的程序員很難有這方面的素質。其實，培養這種素質很簡單。讓大學的畢業設計，從大一開始做。四年寫一個大型的系統。那麼每個人都應該能感受到不應該欠下“技術債”了
- 文中提到的“技術債"的欠法很牛逼。以前自己沒有想到。