在这篇文章中，我们将讨论以下内容：
- 什么是技术债务？
- 技术债务的类型
- 应对技术债务的策略
- 处理技术债务的推荐策略
- 追踪技术债务的工具
- 保持技术债务的低水平
什么是技术债
技术债务会给开发团队带来很多挫折和疲劳。软件工程师可以意识到技术债务的副作用。然而，他们往往需要向产品团队解释为什么快速、简单的编码开发解决方案具有风险。
因此，业务继续添加更多的功能，技术债务增长。我们通常说这是因为技术债务不是一个技术问题。因此，每个软件开发团队都必须尽力防止技术债务累积，这样才不会导致最糟糕的情况，即项目停顿。
这个术语由Ward Cunningham在1992年的OOPSLA会议上创造。作为发展软件资产的隐喻。他得出结论，开发过程导致了新的学习，因为它依赖于他称为技术债务的工件。
对于技术债务，我们可以说它是阻止我们快速开发软件的一切。马丁·福勒在他的技术债务四象限中解释了导致技术债务产生的四种不同路径[4]，但还有更多。特别是对于想要快速发展但不考虑质量的初创公司，我们可以看到这一点。
在关于开发人员生产力的研究[2]中，由于公司为了短期目标（如新的闪亮功能）而牺牲了质量，开发人员通常被迫引入新的技术债务。然而，技术债务不仅影响整个组织，还会影响开发人员的幸福感、工作满意度和士气。
技术债务的主要问题是代码是一个抽象的概念，所以很难向业务和管理层解释发生了什么。因此，公司可以轻易忽视他们看不到或理解不了的东西。因此，在这里，我们需要以明确和可视化的方式清楚地向公司和管理层呈现我们的技术债务。
通常，在我们的软件系统开发过程中，每个开发周期可以用于新功能的容量都在减少（花费时间在增加），而复杂性不断增加。因此，我们花费的时间越来越多地与复杂性作斗争，而不是开发新功能。
下图显示了技术债务如何降低团队开发新功能的能力。
我们希望拥有一个高绩效的组织，为我们提供竞争优势，以提高响应能力和创新能力。为此，我们需要一个高质量的软件开发流程来快速实现这一目标。
无论如何，技术债务都会发生，然而我们需要一种策略来减少新债务的产生，同时允许我们减少现有债务。在这方面投资将为我们的公司创造技术财富。
技术债类型
我们通常认为糟糕的代码=技术债务，但事实上还有更多。技术债务有不同的类型：
- 代码质量我们的代码可能不够清晰易懂。没有编码标准，设计不良，有很多复杂性。此外，还有很多代码注释解释某些事情的作用。
- 测试我们需要一个适当的测试方法（请参见测试金字塔），从单元测试到集成测试再到端到端测试。
- 耦合模块间的耦合增加了处理此类代码的时间。
- 过时的库或工具我们正在使用一些存在问题的旧版库或工具，例如安全性或无法更新到新的技术和平台。作为开发人员，我们总是希望使用最新的技术和高效的工具。
- 手动流程我们交付中的某些流程需要自动化。没有自动化构建、没有CI/CD流程。
- 错误或没有架构我们没有适当的架构，或者只是一个泥团架构。我们的架构不反映我们想要通过系统实现的目标，或者无法良好扩展。
- 缺乏文档没有文档，或者文档没有更新以反映系统的当前状态。
- 缺乏知识分享我们没有知识分享的文化，所以新加入者很难迅速上手。我们应该在工作过程中始终记录我们的决策和规范。
还有更多的类型，例如对低价值工作、监控问题等的处理。
然而，我们经常看到许多组织需要更多的流程和策略来管理和减少技术债务，这是一个需要合适的工程文化的标志。
解决技术债的策略
那么，如何减少技术债务的策略是什么？我们都应该从优先考虑技术债务开始。首先，我们需要分析我们的开发过程和代码库以找出瓶颈，并创建一个技术债务地图。然后，一旦我们有了这样一张地图（如下图所示），我们需要逐个检查每个部分以确定原因。
现在，当我们有了这个列表，我们可以看看如果不采取任何措施会发生什么（会更糟糕还是不会变糟）以及我们的系统现在和未来是否将用于新开发。因此，当我们标记了这两件事之后，我们可以优先考虑并保留那些技术债务更糟糕的东西，我们将在现在和未来建立在这些基础上。
另一种替代方式是按照修复问题的工作量和痛苦程度或RICE评分模型构建这个地图。
您还可以组织一个研讨会或技术债务回顾会来制定一张地图，您应该定期审核所有这些类别的债务。
处理技术债推荐策略
处理技术债务的推荐策略包括以下步骤：
- 我们需要对我们的开发过程、瓶颈以及为什么需要更快有一个透明的了解。然后，我们需要以一种共同理解的语言将其概括起来，以便所有利益相关者（工程和管理层）可以共享相同的理解。在这里，可视化非常有帮助。
- 我们的系统需要具有明确的所有权，并对其负责。但是，不幸的是，如果我们的系统的某些部分有问题，没有人会照顾它们。
- 我们需要根据影响进行优先级排序，就像我们在上面的技术债务地图中展示的那样。
- 我们必须赋予团队解决问题并解决技术债务的权力，在产品开发的自然流程中解决。我们需要在降低技术债务和以实用的方式添加新功能之间保持健康的平衡。一个好的方法是将10-20％的开发时间持续投入其中。您可以通过以下方式实现：
- 对于较小的债务（几个小时之内），在触及它时进行重构。然后，让人们保持好男孩童子军原则。
- 对于中等的债务（从一天到几天的工作时间），可以尝试以下方法：
- 只在技术债务星期五解决此类问题。
- 将技术债务视为一个功能，将其放在优先级列表中，并予以处理。
- 对于较大的债务（从几周到几个月）：
- 花固定的时间来处理技术债务。例如，花两天时间处理一个故事。
- 成立一个特别的工作小组（专门的团队）来处理一段时间的债务。
- 使用度量指标，例如代码问题（例如使用SonarQube）或交付时间。这些指标可以帮助我们在修复技术债务时做出更好的决策。
跟踪技术债的工具
有不同类型的工具可以追踪技术债务。然而，我建议始终使用现有的工具，因为引入新工具可能会很昂贵。通常，可以通过以下方式追踪技术债务：
- 项目管理工具例如Jira、Asana、GitHub问题、Azure DevOps Board或一些更专注于此的工具，如**Stepsize、CodeScene或NDepend*（.NET）。
- 自动化代码分析工具您可以使用代码分析工具，例如**SonarQube*，来跟踪和检测代码问题、安全问题或其他问题。
- 手动跟踪方法在这里，您可以使用最适合您的手动方式，例如Excel表格或对您有效的方式。甚至可以是以上方法的结合，例如在Miro中跟踪战略性技术债务，在Jira中跟踪战术性债务，并从SonarQube使用指标。只需使其易于访问和更新即可。
保持技术债处于低水平
我们希望以正确的速度、质量和复杂性生成代码，而不是采用快速而肮脏的方式。随着软件的发展，我们的系统架构变得越来越复杂，这使得维护变得困难。然而，如果我们从一开始就进行了糟糕的设计和代码质量，以后就会陷入困境。
我们的目标是开发易于维护的系统，可以避免错误，并且问题和进一步的改进可以以较低的成本添加。为了实现这一目标，软件架构和工艺应适当设置。我们希望在质量、速度和复杂性之间取得平衡（如下图所示）。
然而，我们开发新功能的速度越快，确保软件质量就越困难，技术债务往往会积累，导致开发过程变慢且出现更多错误。因此，我们希望从一开始就慢下来，但这将在将来获得更高的速度。
问题是如何在一开始就避免创建技术债务。答案是拥有一个高质量的软件开发流程。以下是我们可以做的一些事情：
- 根据期望结果为系统进行架构设计。从一开始就将架构师纳入团队创建的过程中，通过定义他们的拓扑结构，因为否则，康威定律将使我们的架构成为组织的通信渠道的映像，而不是期望的架构。
- 为所有的架构决策（ADRs）和技术文档编写文档。使其易于查找（将其放在靠近代码的存储库中）。
- 在测试金字塔的所有层次上编写测试。目标是达到60-80％的代码覆盖率。
- 鼓励代码审查文化。让每个人参与到代码审查中，检查代码可读性、设计、性能、安全性、可测试性和文档相关的问题。这是分享知识的最佳方式之一。
- 在代码编写时，进行结对编程。一个开发人员编写代码，另一个提供反馈和建议。这样可以提高代码质量；如果实施了这一点，我们就不需要代码审查了。
- 允许开发人员重构。我们应该建立这样的文化，即无需请求权限来解决技术债务！特别是如果这是可以在几个小时内完成的任务。
- 遵循代码规范，如设计、命名和架构。然后，通过代码检查工具或CI/CD流程来自动完成这些。
- 使用测试驱动开发（TDD）的软件设计过程，即首先编写测试，然后进行适当的实现。
- 编写高质量的代码。首先培养开发人员对编程语言的深入了解，并理解面向对象的概念、设计模式、重构、良好代码原则、架构模式和风格以及SOLID、YAGNI、KISS和DRY原则。
- 持续交付。以短周期调整代码，因此其他团队成员始终可以轻松验证。通过频繁发布和快速反馈避免在生产中出现重大问题。
内容由GeekAI网页翻译服务自动翻译完成。 原文地址：https://newsletter.techworld-with-milan.com/p/how-to-deal-with-technical-debt
