编程的97件事——1、谨慎行事

 

谨慎行事

        “无论你做什么，请谨慎行事并考虑后果”   －Anon

        无论新项目的工作计划看起来如何轻松自在，有时还是难以避免陷入交付压力之中。当不得不面临“做得好”和“做得快”的抉择时，我们往往倾向于选择“做得快”，相信自己日后会回来做好。当我们对自己、对团队、对客户做出这样的承诺时，我们是真心实意的。但经常会出现这样的情况：下一个迭代带来了新的待解决问题，我们只能先聚焦于新的问题。这种不完善的工作就是我们熟知的技术债务，它可不是你的朋友。特别的，在Martin Fowler的“技术债务分类”中，将这一类技术债务称为“有意的技术债务”，以区别于“无意的技术债务”。

        技术债务就像贷款，你可以短期获利，但必须一直偿还利息，直到还清为止。在代码中走捷径会使添加新特性更加困难、代码更加难以重构。它为程序缺陷提供了温床，使测试用例变得脆弱。你欠债越久情况就越糟糕。当你最终着手解决一开始的技术债务时，很可能已经有了一大堆基于此技术债务的不良设计，使得代码非常难以重构和修正。事实上，经常是事情已经糟糕到你不得不去修正它，你才真的会去修正它。到了那时，代码已经非常难以修改，以至于你无法担负修正它的时间或风险。

        有时因为交付截止日期或便于加入一个小的特性，我们不得不引入技术债务。尽量避免陷入这样的境地，但实在别无选择时，先解决眼前的问题吧。但是（敲黑板！）你必须追踪技术债务并尽可能快地偿还它，否则情况就会急转直下。每当你引入技术债务时，写一张任务卡片或将此事写入你的事务追踪日志，以确保你不会忘了它。

        如果你能在下一次迭代时就偿还技术债务，就能付出最小的代价。如果推迟偿还将产生利息，应该同时记录利息，使得你能够看到将要付出的代价。这样才能强调项目的技术债务对商业价值产生的影响并为偿还技术债务安排适当的优先级。具体如何计算和追踪技术债务因项目而异，但首先你要追踪它。

        尽可能快地还清技术债务，不这么做是不明智的。

 

---

原文：

 

Act with Prudence

 

"Whatever you undertake, act with prudence and consider the consequences" Anon

No matter how comfortable a schedule looks at the beginning of an iteration, you can't avoid being under pressure some of the time. If you find yourself having to choose between "doing it right" and "doing it quick" it is often appealing to "do it quick" on the understanding that you'll come back and fix it later. When you make this promise to yourself, your team, and your customer, you mean it. But all too often the next iteration brings new problems and you become focused on them. This sort of deferred work is known as technical debt and it is not your friend. Specifically, Martin Fowler calls this deliberate technical debt in his taxonomy of technical debt, which should not be confused with inadvertent technical debt.

Technical debt is like a loan: You benefit from it in the short-term, but you have to pay interest on it until it is fully paid off. Shortcuts in the code make it harder to add features or refactor your code. They are breeding grounds for defects and brittle test cases. The longer you leave it, the worse it gets. By the time you get around to undertaking the original fix there may be a whole stack of not-quite-right design choices layered on top of the original problem making the code much harder to refactor and correct. In fact, it is often only when things have got so bad that you must fix it, that you actually do go back to fix it. And by then it is often so hard to fix that you really can't afford the time or the risk.

There are times when you must incur technical debt to meet a deadline or implement a thin slice of a feature. Try not to be in this position, but if the situation absolutely demands it, then go ahead. But (and this is a big BUT) you must track technical debt and pay it back quickly or things go rapidly downhill. As soon as you make the decision to compromise, write a task card or log it in your issue tracking system to ensure that it does not get forgotten.

If you schedule repayment of the debt in the next iteration, the cost will be minimal. Leaving the debt unpaid will accrue interest and that interest should be tracked to make the cost visible. This will emphasize the effect on business value of the project's technical debt and enables appropriate prioritization of the repayment. The choice of how to calculate and track the interest will depend on the particular project, but track it you must.

Pay off technical debt as soon as possible. It would be imprudent to do otherwise.