技术债务简介
“技术债务”这一术语描述了未来的成本，产生此费用的原因是目前选择了一个简单的解决方案而非使用需要花更长时间才能完成的更好的做法。
选择“技术债务”这一术语是为了与财务债务做对比。 财务债务用户通常会做出当时看似合适或唯一的选择，但这样做会增加利息。
积累的利息越多，他们将来就越难，他们以后可用的次要选择也就越多。 有了财务债务，利息很快就会增加，从而产生滚雪球效应。 同样，技术债务累积到一定程度后，开发人员将花费几乎所有的时间来解决问题并有计划或无计划地进行返工，而不是增加价值。
那么，技术债务是如何发生的呢？
最常见的原因是截止时间紧迫。 当被迫快速创建代码时，开发人员通常会走捷径。 例如，我们不会重构某种方法来包含新功能，而是复制该方法以创建新版本。 然后，我只测试新代码，如果因为代码的其他部分使用原始方法而对其进行更改，则可以避免所需的测试级别。
现在我有两份相同的代码，我需要在未来同时修改这两份代码，而不是一份，这存在逻辑分歧的风险。 其原因有很多。 例如，开发人员可能缺乏技术技能和成熟度，或者没有明确的产品所有权或方向。
组织可能根本没有编码标准。 因此，开发人员甚至不知道他们应该生成什么。 开发人员可能没有确切的目标要求。 他们可能会受最后一分钟要求更改的影响。
必要的重构工作可能会延迟。 可能没有任何手动或自动的代码质量测试。 最终，它只会让在合理的时间范围内以合理的成本向客户交付价值变得越来越难。
技术债务是项目未能按期完成的主要原因之一。
随着时间的推移，它的增长方式与财务债务的增长方式大致相同。 技术债务的常见来源包括：
- 缺少编码风格和标准。
- 缺少单元测试案例或其设计不佳。
- 忽略或不了解面向对象的设计原则。
- 单体类和代码库。
- 对技术、体系结构和方法的使用设想不佳。 （忘记了需要考虑所有系统属性，以及对维护、用户体验、可扩展性等的影响）。
- 过度设计代码（添加或创建不需要的代码，在现有库足够时添加自定义代码，或创建不需要的层或组件）。
- 注释和文档不足。
- 不编写自文档化代码（包括描述性或指示意图的类、方法和变量名称）。
- 走捷径以按时完成任务。
- 将死代码留在原处。
注意
随着时间的推移，必须偿还技术债务。 否则，团队需要更长的时间来修复问题和实施新功能和增强功能，最终导致成本过高。
我们已经看到，技术债务在开发过程中增加了一系列问题，并使增加额外的客户价值变得更加困难。
项目中的技术债务会降低工作效率，使开发团队感到沮丧，使代码既难以理解又脆弱，增加了进行更改以及验证这些更改的时间。 计划外工作经常会妨碍计划内工作。
从长远来看，它还会削弱组织的实力。 技术债务往往会在组织中蔓延。 它一开始很小，随着时间的推移而增长。 每次由于需要匆忙进行更改而进行快速破解或规避测试时，问题都会变得越来越严重。 支持成本越来越高，并且总是会出现一个严重问题。
最终，组织无法及时且经济高效地响应客户的需求。
用于监视的自动度量值
最大限度地减少技术债务累积的一种关键方法是使用自动化测试和评估。
在接下来的演示中，我们将了解用于评估债务的一种常用工具：SonarCloud。 （最初的本地版本是 SonarQube）。
还有其他工具可用，我们将讨论其中一些。
稍后，在下一个动手实验室中，你将了解如何配置 Azure Pipelines 以使用 SonarCloud，了解分析结果，以及如何配置质量配置文件以控制 SonarCloud 在分析项目时使用的规则集。
有关详细信息，请参阅 SonarCloud。
回顾：
Azure DevOps 可以与多种现有工具集成，用于在生成期间检查代码质量。
你当前使用哪些代码质量工具（如果有）？
你喜欢或不喜欢这些工具的哪些部分？