在代码已经编写的情况下，这项工作可能意味着一些改进或优化。但需要注意的是，这些改进对最终产品没有影响或影响很小。所有这些都是针对开发人员作为最终用户的。如果不是这样，那么这将是一项标准任务。

它是什么样子的？

事实上，他有很多伪装，这些伪装既取决于项目的具体情况，也取决于项目所处的条件。以下只是其中的几种：

• 架构不符合应用程序的要求或完全不存在。你能想到的最糟糕的例子是整个应用程序写在一个文件中，而且长达数百行。
• 应用程序内的代码内聚力强。在项目、组件、类、模块等级别。一个部分的变化会导致看似不相关的事物产生意想不到的后果。
• 没有什么比临时的、一次性的解决方案更持久的了。“在这里和这里，我将专门为这种情况添加一个新条件，稍后我将删除它。

它从哪里来？

怎么打？

首先也是最困难的，不要寻找罪魁祸首，你需要偿还债务。接下来，你需要评估悲剧的规模。在有些高级情况下，将系统命名为遗产并将其视为遗产更容易。但通常，它仍然可以修复，然后我们使用分而治之的原则。所有债务都必须登记并按优先顺序排列，并随时准备进入处理队列。

最重要的是预防。必须控制和管理债务。不断留出时间来处理债务，这应该是系统的。

结论

对于许多产品，尤其是初创公司来说，时机往往是一个因素。如何快速进入市场，占领新的利基市场或创造这个利基市场，设法吸引尽可能多的客户，如果在你的产品的另一边有一个不妥协的技术领导，不让你在一个新的杀手级功能大放异彩之前将其投入生产，那么这对整个产品来说往往是致命的。相反的说法绝对同样有效。当产品团队未能偿还此类债务时，存在失去质量和可靠性水平以及支持该系统的能力的风险，这是不为零的。

原文链接：https://hackernoon.com/the-work-you-defer-only-accumulates-tech-debt