它是什么？

技术债务是将工作推迟到以后再做。与日常生活打个比方，我们可以举个晚餐的例子。你准备了食物并吃了，但没有洗碗。虽然一切都很好，你很满足，很饱，但总有一天你必须洗碗。

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

它是什么样子的？

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

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

它从哪里来？

技术债务通常可以看作是技术团队为了产品团队而做出的一系列妥协。它也被称为质量和速度的妥协。虽然这被称为技术债务，但它的责任在项目中的所有人身上是平等的。这种幕后的妥协可能是由以下因素造成的：

不合理的要求，
沟通不畅或沟通错误，
不切实际的期限，
团队成员资质较低。

这已经导致我们的代码质量低，开发时间长，应用程序不稳定，可维护性水平低。

怎么打？

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

不要忘记，游说偿还债务的想法完全是这些团队的意愿。产品团队和整个企业并不擅长处理这些事情，他们会自行评估并确定优先事项。

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

结论

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

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