[size=medium] 本人英語抄過4級，奇爛無比，翻譯這個實屬蛋疼，錯誤是肯定有的，而且是翻不出出來就是隨便猜，歡迎指出，謝謝啦。但願我能夠翻完我看的懂的....
原連結：oreilly的程式設計師需要知道的97件事http://programmer.97things.oreilly.com/wiki/index.php/Act_with_Prudence
不管你著手去做什麼事情，都應該在行動前規劃，並考慮與之相對的結果(anon).
在迭代的初期，無論計劃看起來是多麼的合適，你都不能忽略隨後可能到來的壓力。當你面臨著“正確去做”和“快速去做”的抉擇的時候，在懷著我可以回過頭去修復這些不足的僥倖心理的條件下，常常會要求選擇“快速完成”。

當你對你自己，你的團隊，你的客戶作出承諾的時候，你已經做出了這樣的選擇。但是頻繁的迭代帶來的新的問題，使你不得不面對他們。這些使專案延期的種類被認作“技術債務”。更加明確的定義，Martin Fowler在他的技術類過錯分類這篇文章中，把這類問題歸結為“有預謀的技術債務”，用於區分於“無意識的技術債務”。

技術債務很像貸款：你能從短期類受益，但是你必須一直關注它直到它被完全付清。
走捷徑的程式碼很難新增新的特性和重構。它們將帶來面積性的過失和脆弱的單元測試。你忽視它的時間越長，它帶來的後果更嚴重。當你抽出時間去解決原先的預留問題，它可能已經導致一序列追求捷徑而沒有選擇正確途徑的選擇橫檔在原先問題之前，使得程式碼更加困難去重構致正確化。事實上，大家總是等到事情變的很糟糕的時候才去修復這些問題，通常到那個階段下，他常常變得十分難以修復以致你無法避免花費時間和風險

通常招致“技術債務”意味著即將專案的最終期限或者是新增一個很小的特性。在這個階段下，試著儘量不要犯這樣的錯誤。但是，如果當時的情形完全要求那樣，那就勉強的做吧。但是（這是個強烈的轉折）你必須跟蹤這些“技術債務”，並且快速的返回來修復它。一旦你決定去妥協，記錄這些任務或者日誌在跟蹤系統裡面，以確保不會遺忘他們。
如果你在下個迭代確認時間去修改這些問題，代價將非常小。忽視這些過失將增加影響而這些問題將被跟蹤讓代價可見。這將強調“程式碼過錯”在商業上的效果並且適當的“”。如果去計算和跟蹤這些利害問題，將依賴於特定的專案，但是你必須跟蹤它。

儘快的還清技術債務，否則那將會是個輕率的決定。
[/size]