程序员需要知道的97件事情之 ------- 谋定而后动

   本人英语抄过4级，奇烂无比，翻译这个实属蛋疼，错误是肯定有的，而且是翻不出出来就是随便猜，欢迎指出，谢谢啦。但愿我能够翻完我看的懂的....
    原链接：oreilly的程序员需要知道的97件事http://programmer.97things.oreilly.com/wiki/index.php/Act_with_Prudence
    不管你着手去做什么事情，都应该在行动前规划，并考虑与之相对的结果(anon).
在迭代的初期，无论计划看起来是多么的合适，你都不能忽略随后可能到来的压力。当你面临着“正确去做”和“快速去做”的抉择的时候，在怀着我可以回过头去修复这些不足的侥幸心理的条件下，常常会要求选择“快速完成”。

   当你对你自己，你的团队，你的客户作出承诺的时候，你已经做出了这样的选择。但是频繁的迭代带来的新的问题，使你不得不面对他们。这些使项目延期的种类被认作“技术债务”。更加明确的定义，Martin Fowler在他的技术类过错分类这篇文章中，把这类问题归结为“有预谋的技术债务”，用于区分于“无意识的技术债务”。

   技术债务很像贷款：你能从短期类受益，但是你必须一直关注它直到它被完全付清。
走捷径的代码很难添加新的特性和重构。它们将带来面积性的过失和脆弱的单元测试。你忽视它的时间越长，它带来的后果更严重。当你抽出时间去解决原先的预留问题，它可能已经导致一序列追求捷径而没有选择正确途径的选择横档在原先问题之前，使得代码更加困难去重构致正确化。事实上，大家总是等到事情变的很糟糕的时候才去修复这些问题，通常到那个阶段下，他常常变得十分难以修复以致你无法避免花费时间和风险
   
     通常招致“技术债务”意味着即将项目的最终期限或者是新增一个很小的特性。在这个阶段下，试着尽量不要犯这样的错误。但是，如果当时的情形完全要求那样，那就勉强的做吧。但是（这是个强烈的转折）你必须跟踪这些“技术债务”，并且快速的返回来修复它。一旦你决定去妥协，记录这些任务或者日志在跟踪系统里面，以确保不会遗忘他们。
如果你在下个迭代确认时间去修改这些问题，代价将非常小。忽视这些过失将增加影响而这些问题将被跟踪让代价可见。这将强调“代码过错”在商业上的效果并且适当的“”。如果去计算和跟踪这些利害问题，将依赖于特定的项目，但是你必须跟踪它。

    尽快的还清技术债务，否则那将会是个轻率的决定。