Act with Prudence【行事谨慎】
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” with 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, and it should not be confused with inadvertent technical debt.
不管迭代开始时的计划看起来有多舒适,您都无法避免在某些时候处于压力之下。如果你发现自己不得不在“正确地做这件事”和“快速地做这件事”之间做出选择,那么“快速地做这件事”通常是很有吸引力的,因为你知道你稍后会回来做这件事。当你对自己、团队和客户做出这样的承诺时,你是认真的。但是通常情况下,下一个迭代会带来新的问题,而您会关注这些问题。这种延期的工作被称为技术债务,它不是你的朋友。具体来说,Martin Fowler在他的技术债务分类中称这种人为的技术债务为*,并且它不应该与无意的技术债务相混淆。
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 the original problem, 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.
尽快还清技术债务。不这样做是不谨慎的。
本文探讨了软件开发过程中常见的技术债务概念,解释了为何在短期利益和长期维护间找到平衡至关重要。技术债务如同贷款,短期内提供便利,但长期未偿还则会产生高昂的利息,增加重构和修复的成本。文章建议开发者应谨慎行事,记录并优先偿还技术债务,以避免项目价值受损。
&spm=1001.2101.3001.5002&articleId=102983090&d=1&t=3&u=64b3108800dc4d7fbb70a0ea4bb9bf7f)
416

被折叠的 条评论
为什么被折叠?



