不论你想干嘛，三思而后行——Anon
不管开局多么美好，你都无法避免某些时刻的压力。当“保质保量”和“赶工期”摆在你的眼前，选择“赶工期”意味着你很快会返工。尤其是你给自己、团队、客户作出某些承诺后，就意味着你选择了后者，通常在下次迭代那些赶工导致的问题就会浮现出来，反而导致工期延长。Martin Fowler 在他的技术债分类中把这种现象称为deliberate technical debt(故意的技术债)，注意不要和无意的技术债混淆（前者是你和你的团队明知这样做会出问题，还选择这么做）。
“技术债”就像一次借贷：短期内你能从中获益，但必须为此支付利息直到还清为止。代码中的投机(Shortcuts in the code)会导致你的代码很难再增加新功能或重构，也是缺陷和脆弱的测试用例的温床，时间越长越糟糕。当你着手准备修复时最初的问题时，在此之上可能还会面对一堆堆被不太正确的选择（越来越歪）。而事实上，你总是等到bug一发不可收拾的地步才会回来修复它。燃鹅，这早已发展到你承担不起的时间和风险。
有时你必须引入技术债去应付截止日期或一些功能雏形，尽量别尝试这么做，除非情况已经是非做不可了。但是（一个大大的但是）你必须跟踪这个技术债而且要尽快偿还或者把事情迅速平息下来。当你决定妥协时，为了确保这笔债不会被遗忘，一定要在你的系统问题跟踪里加入此项任务清单或日志。
如果你打算在下次迭代的时候就偿还此债务，它的成本是最低的。未偿还的部分应该作为累计利息被跟踪，以使成本可见。同时这也将作为影响项目的业务价值权重，确保偿还的优先级。至于如何计算和跟踪这些利息并加以权衡，取决于项目的细节，但跟踪是必须的。
尽可能还清技术债，否则就太轻率了不是吗。
