技术债务 (TD) 是一个概念，描述了系统新功能或维护的成本和/或额外工作。把它想象成汽车中的摩擦。您选择忽略它的时间越长，您以后修复它所需的费用就越多。它对开发团队以外的人来说大多是不可见的，但它以两种方式表现出来：
进化系统的难度和额外成本；
维护系统的难度和额外成本。
专家经常将技术债务描述为错误或次优技术决策的结果，这些决策后来导致系统维护和扩展问题。
技术债务是不可避免的。Martin Fowler曾建议使用技术债务象限来解释技术债务的性质。他建议有四种类型的TD
故意和谨慎的技术债务是最无害的。当您必须将 MVP 交付给用户以获得进一步开发的资金并选择稍后处理后果时，就会发生这种情况。在其他情况下，开发人员可能不知道一些最佳实践，也不知道所选择的方法不是最佳决策（无意和谨慎的技术债务）。当您忽略解决方案的设计或规划时，事情会变得相当混乱，这会导致鲁莽但故意的技术债务。最坏的情况是工程师不关心或不称职，因此不遵守开发中的最佳标准（疏忽和鲁莽）。但是是什么导致了这些决定？让我们深入挖掘技术债务的原因。
什么导致技术债务？
现在我们已经看到了技术债务的症状，让我们更深入地研究这种现象的原因。
通常，我们看到的只是冰山一角。为了将后果与原因分开，我们需要解决导致技术债务的原因和情况。通常，技术债务有四个根本原因：
业务。通常，业务需求会阻碍软件开发中的最佳实践。团队被迫更快地或以更少的钱发布产品。有时需求会在中途发生变化。公司需要削减成本。
上下文的变化。通常情况下，对初始系统有意义的需求不再适合。您可能需要更改技术堆栈/工具，或者只是您使用的技术已经过时。
开发过程。当最初的概念没有得到适当的记录时，也会发生技术债务。人们对应该做什么以及为什么这样做感到困惑。如果在此等式中添加不足的资源和缺乏测试自动化，就会出现技术债务。
团队/人。这是技术债务最复杂的原因。这不是责备人或指责，而是了解在人力资源方面可以做得更好。如果缺乏有经验的开发人员，分布式团队之间的沟通效率低下，或者资源从一个项目转移到另一个项目——你肯定会遇到技术债务的麻烦。
那么公司如何减少现有的技术债务呢？不幸的是，没有减少技术债务的通用方法。一切都取决于你的环境，系统有多大，它有多老，你依赖什么商业模式，谁做决定等等。
对拥有 5 名工程师的小型初创公司有效的东西，很可能不适用于支持企业级的遗留系统的 100 多人的团队。但是，有一些一般性建议可以帮助您减少技术债务或减少获取技术债务的频率。
减少技术债务的最佳实践
根据您的情况，您可能需要跳过一个步骤或一个额外的步骤，但所有公司通常都从同一个地方开始。
-
承认技术债务
经常发生的是，公司在没有意识到甚至从中受益的情况下获得了技术债务。然而，当技术债务不再是一个好处而是一个会导致很多麻烦的痛苦问题时，就会出现一个转折点。你越早承认它，你就越容易减少技术债务。
-
了解您的技术采用阶段并确定解决技术债务的最佳方法
根据技术债务的数量，您可能需要进入技术采用阶段。最有可能的是，它将定义偿还技术债务的方法。
Ozkaya 提出了管理技术债务的三种策略：
没做什么。有时，如果技术债务允许您实现业务目标，那么它并不是一件坏事。但是，重要的是要了解不处理此问题的后果。
更换整个系统。有时遗留系统过于复杂，您无法通过添加补丁或仅解决特定问题来修复它们。这是一个漫长而昂贵的过程，但有时它是唯一明智的出路。
增量重构（投资承诺）。这种方法允许您通过关注每个冲刺来减少技术债务。它可能很贵，但从长远来看肯定会得到回报。
-
分类和记录技术债务
第三步是了解您的债务类型并正确记录。您需要说明问题的类型、补救方法、负责人，并说明不偿还这笔债务的后果。
确保衡量您的团队何时以及如何因技术债务而放缓。它将帮助您识别业务影响并将抽象概念转化为可衡量的任务。
-
调整您的积压工作并跟踪技术债务
尝试定期偿还您的技术债务。技术领导者必须不断与利益相关者合作，将技术债务审查纳入待办事项并在必要时安排维护冲刺。Wolpers 说，Scrum 团队应该考虑将 15-20% 的资源分配给每个 sprint 周期的重构代码和修复错误。确保您将相关任务包含在您的待办事项中，并防止它掉入裂缝并被遗忘。
技术债务在持续测量时得到最好的控制。像 SonarQube 这样的工具允许用户使用指标和规则及时观察技术债务。
麦肯锡 2020 年的研究表明，大多数公司将其技术预算的 20% 以下用于支付技术债务。
-
坚持最佳实践
发展通常是在“什么是正确的”和“什么是有效的”之间找到平衡。是的，我们都听说过 GRASP 或 KISS 原则，以及好的代码的特点。但是，对遗留应用程序进行现代化改造意味着您需要与现有方法保持一致。因此，您需要找到平衡点并采用最适合您的案例的最佳实践
您还应该调整“完成”的定义。每个团队成员都需要了解任务何时准备就绪，并且它符合可接受和可管理的技术债务标准。
-
教育非技术利益相关者
管理技术债务的关键方面之一是确保决策人员了解减少技术债务的重要性。你越解释为什么会出现技术债务以及为什么必须偿还它，就越容易让他们站在你这边。 现在我们已经了解了原因，让我们放大特定类型的技术债务。
4种主要类型的技术债务以及如何减少它们
早在 2014 年，一群学者就担心现有的技术债务等级与债务的性质无关。这些专家驳斥了战略债务与非战略债务的传统划分，并提出了不同的方法。他们的努力产生了一个分类，由软件工程研究所发布为Towards an Ontology on Technical Debt。我们根据他们工作的反思建立了我们的清单，主要关注技术和代码相关问题。
架构技术债
这种类型的债务与整个系统的设计有关。它通常会影响关键的架构要求，如性能指标、健壮性等。为什么会发生这种情况？诸如对软件架构理解不足、软件系统的复杂性、架构侵蚀以及对软件开发生命周期 (SDLC) 缺乏了解等因素都会造成架构债务。
如何解决建筑债务？首先，您需要评估现有架构。您甚至可以进行外部审计，以便更好地了解情况。专家将分析系统的当前状态，定义转换范围，概述潜在的瓶颈和风险，并找到解决它们的方法。
如果您正在处理遗留系统并且难以扩展您的产品，您还可以从采用微服务中受益。
代码债务
这种形式的债务是指在源代码中发现的问题。一些最常见的属性是所谓的“代码异味”，即长方法、代码重复和其他类似症状。当缺乏代码审查、标准化指南或 lint 时，它通常会出现。
重构是解决代码债务的主要方法。它可以帮助您在不改变应用程序行为的情况下实现系统现代化。您还可以改进代码审查程序并在代码审查期间和推送之前介绍 lint 的使用。
基础设施债务
基础设施债务主要与运营环境有关。它在基础设施代码中伪装自己，导致许多问题，如缺乏可观察性（也称为监控债务）、部署问题、CI/CD 管道中断等。
DevOps来救援。DevOps 不仅可以帮助您降低运营成本，而且通过确保开发、测试和生产环境的一致性，DevOps 还可以最大限度地降低风险。
测试债务
这种类型的技术债务包括一般测试债务、缺乏测试自动化和缺陷债务。它包括缺乏测试覆盖率、测试和实际代码之间的一致性差、测试用例设计不明确或不成熟等。
为了成功减少测试债务，至关重要的是 a) 增加测试覆盖率，b) 测试正面和负面场景，c) 引入自动化测试，以及 d)尽快开始测试。
概括来讲
无论您拥有遗留系统还是从头开始构建新系统，获得技术债务都是不可避免的。这是每个公司都面临的复杂问题。尽管它的性质，重要的是承认它的存在，记录它并支付它。确保您对开发团队和利益相关者都诚实并直言不讳。
