技术债务简介

技术债务 是一个术语，描述了未来成本，这些成本将来自今天选择一个简单的解决方案，而不是使用需要更长时间才能完成的更好做法。

选择了“技术债务”一词，因为它类似于财务债务。 金融债务中的人们通常做出看似正确或当时唯一选择的决定，但这样一来，利息增加。

积累的利息越多，他们将来面对的困难就越大，选择也越少。 有了财务债务，利息很快就会增加，从而产生滚雪球效应。 同样，技术债可能会累积到一种程度，使开发人员几乎所有的时间都花在修复问题和重新处理任务上，这些任务可能是计划好的或是临时的，而不是在增加价值。

那么，它是如何发生的？

最常见的借口是紧张的最后期限。 当开发人员被迫快速创建代码时，它们通常会采用快捷方式。 例如，他们可能会复制该方法以创建新版本，而不是对某个方法进行重构以加入新功能。 然后，它们仅测试新代码，并且如果更改原始方法，则可以避免所需的测试级别，因为代码的其他部分使用它。

现在，它们具有需要将来修改的同一代码的两个副本，而不是一个副本，并且会面临逻辑变得不同的风险。 有许多原因。 例如，开发人员可能缺乏技术技能和成熟度，或者没有明确的产品所有权或方向。

组织可能根本没有编码标准，因此开发人员甚至不知道他们应该生产什么。 开发人员可能没有明确的目标要求，或者他们可能会受到最后一刻的要求更改。

必要的重构工作可能会延迟。 可能没有任何代码质量测试、手动或自动化。 最后，它只会使在合理的时间范围内以合理的成本向客户提供价值变得更加困难和困难。

技术债务是项目未能达到截止日期的主要原因之一。

随着时间的推移，它增长的方式与货币债务的方式大致相同。 技术债务的常见来源包括：

• 缺乏编码风格和标准
• 单元测试用例缺乏或设计不佳
• 忽略或不理解面向对象的设计原则
• 单体类和代码库
• 对技术、架构和方法的使用计划不周（忘记需要考虑所有影响维护、用户体验、可伸缩性等因素的系统属性）
• 过度工程代码（添加或创建不需要的代码、在现有库足够时添加自定义代码或创建不需要的层或组件）
• 注释和文档不足
• 不编写自文档代码（包括描述性或指示意向的类、方法和变量名称）
• 使用捷径以满足截止日期
• 将死代码留在原处

我们看到，技术债务在开发过程中增加了问题，并使得增加额外的客户价值要困难得多。

在项目中拥有技术债务可降低工作效率，挫败开发团队，使代码难以理解和脆弱，增加进行更改和验证这些更改的时间。 计划外的工作经常妨碍计划内的工作。

从长远来看，这也削弱了该组织的力量。 技术债务往往在不知不觉中积累到企业的头上。 它开始很小，随着时间的推移而增长。 每次因为需要赶紧实施更改而使用快速解决方案或跳过测试，问题会进一步恶化。 支持成本越来越高，最终会出现严重的问题。

最终，组织无法及时且经济高效地响应其客户需求。

用于监视的自动度量值

尽量减少持续积累技术债务的一个关键方法是使用自动测试和评估。

在下面的演示中，我们将了解用于评估债务的常用工具之一：SonarCloud。 （原始本地版本为 SonarQube）。

还有其他可用工具，我们将讨论其中一些工具。

稍后，在下一个动手实验室中，你将了解如何将 Azure Pipelines 配置为使用 SonarCloud、了解分析结果，以及如何配置质量配置文件来控制 SonarCloud 在分析项目时使用的规则集。

有关详细信息，请参阅 SonarCloud。

回顾：

Azure DevOps 可与各种现有工具集成，用于在生成期间检查代码质量。

你当前使用哪些代码质量工具（如果有） ？

你喜欢还是不喜欢这些工具？