当处理技术债务时，它可以给开发团队带来很多挫败感和疲劳。软件工程师可能意识到技术债务的副作用。但他们经常需要向产品团队解释为什么快速而简单的编码开发解决方案是有风险的。

在关于开发者生产力的研究中[2]，开发者通常被迫引入新的技术债务，因为公司不断地以牺牲质量为代价，追求短期目标，比如新潮的功能。然而，技术债务不仅影响整个组织，还影响到了开发者的幸福感、工作满意度[3]和士气[8]。

技术债务的主要问题在于代码是一个抽象的概念，所以很难向业务和管理层解释其中的影响。因此，公司可能会轻易忽视他们看不见或不理解的问题。这时，我们需要明确表达并可视化我们的技术债务，以便公司和管理层能够理解。通常在软件系统的开发过程中，每个开发周期可用于新功能的容量逐渐减少（交付时间逐渐增加），而复杂性不断增加。因此，我们花费的时间越来越多地用于解决复杂性问题，而非开发新功能。

以下图片展示了技术债务如何减少团队开发新功能的能力。

我们希望构建一个高绩效的组织，为我们带来竞争优势，更具响应性和创新性。我们需要一个高质量的软件开发流程，可以快速实现这一目标。技术债务无论如何都会发生，但我们需要一种策略来减少新债务的产生，并同时减少现有债务。投资于此将为我们的公司积累技术财富。

技术债务类型
通常我们认为糟糕的代码=技术债务，但实际上还有更多。技术债务有不同类型：

1.代码质量 — 我们的代码可能不够清晰易懂。没有编码标准，设计较差，存在很多复杂性。此外，有大量的代码注释来解释某些功能。

2.测试 — 我们需要一个适当的测试方法（参见Test Pyramid），从单元测试到集成测试再到端到端测试。

3.耦合 — 模块之间的耦合增加了彼此阻碍的时间，增加了处理此类代码的时间。

4.过时的库或工具 — 我们使用一些存在问题的传统库或工具，比如安全性问题或无法更新到新技术和平台。作为开发者，我们总是希望使用最新的技术和高效的工具。

5.手动流程 — 我们交付过程中的某些流程需要自动化。没有自动化构建，没有持续集成/持续交付流程。

6.错误或无架构 — 我们没有恰当的架构，或者是一个大泥球。我们的架构无法反映我们想要实现的系统，或者扩展性不好。

7.缺乏文档 — 没有文档，或者文档没有更新以反映系统的当前状态。

8.缺乏知识分享 — 我们缺乏知识分享的文化，新人很难快速适应。我们应该始终在工作过程中记录我们的决策和规范。

还有更多关于低价值工作、监控问题等的类型。然而，在许多组织中，我们经常看到需要更多流程和策略来管理和减少技术债务，这是需要适当的工程文化的标志。


打击技术债务的策略
那么，有哪些策略可以减少技术债务呢？让我们首先通过优先考虑技术债务来开始。首先，我们必须分析我们的开发流程和代码库以找出瓶颈，并创建一个技术债务地图。然后，一旦有了这样的地图（如下图所示），我们需要检查每个部分的原因。

当我们有了这个列表后，我们可以逐个检查，看如果什么都不做会发生什么（是否会变得更糟或不会），以及这部分我们的系统是否在现在和未来用于新开发。因此，当我们标记了这两件事情后，我们就可以优先考虑并保留那些技术债务更严重的部分，我们将在现在和未来构建在这些部分上。

另一个替代方法是按照努力和解决问题的痛苦程度或RICE评分模型建立这个地图。

你也可以组织一个研讨会或技术债务回顾来创建一个地图，并且你应该定期审计所有这些类别下的债务。

处理技术债务的推荐策略
处理技术债务的推荐策略包括以下步骤：

1.我们需要对我们的开发、瓶颈以及为什么我们需要更快的理由透明化。然后，我们需要用一种可以让所有利益相关者（工程和管理）分享相同理解的语言总结。这时，可视化非常有帮助。

2.我们的系统需要明确的所有权，并完全对其负责。但不幸的是，如果系统的某些部分存在问题，没有人来负责解决。

3.我们需要基于影响对事物进行优先级排序，就像上面的技术债务地图所示。

4.我们必须授权团队解决问题，并在产品开发的自然流程中解决技术债务。我们需要在减少技术债务和以实用主义方式增加新功能之间保持健康的平衡。持续投入10-20%的开发时间是有效的。以下是你可以做到这点的方法：

5.对于小债务（数小时内完成），在接触到它们时进行重构。然后，让人们像好童子军一样。

6.对于中等债务（一天到几天的工作），你可以尝试以下方法：技术债务星期五，只专注于这一点，或者将技术债务视为一个功能，对其进行优先级排序，并着手解决它。

7.对于更大的债务（几周到几个月），花固定的时间来处理技术债务。例如，拿出一个故事并投入两天的时间，或者成立一个特别的工作小组（专门团队）一段时间来处理它。

8.使用指标，如代码问题（例如通过使用SonarQube）或交付时间。

这些指标可以帮助我们更好地决定解决技术债务的方式。

跟踪技术债务的工具
有不同类型的工具可以跟踪技术债务。然而，我建议始终使用一些现有的工具，因为引入新工具可能代价高昂。总的来说，可以通过以下方式跟踪技术债务：

1.项目管理工具 — 类似Jira、Asana、GitHub issues、Azure DevOps Board之类的工具，或者一些更专门用于此的工具，比如Stepsize、CodeScene或NDepend**。

2.自动化代码分析工具 — 你可以使用代码分析工具，比如SonarQube，来跟踪和检测代码问题、安全问题或其他问题。

3.手动跟踪方法 — 在这里，你可以使用最适合你的手动方式，比如Excel表格或任何适合你的方式。甚至可以是上述方法的组合，比如在Miro中跟踪战略技术债务，在Jira中跟踪战术债务，并使用SonarQube的指标。只要使其易于访问和更新即可。

保持技术债务低
我们希望以正确的速度、质量和复杂性生成代码，而不是以一种快速而肮脏的方式。随着软件的演进，我们系统的架构变得更加复杂，使得维护变得困难。然而，如果我们从一开始就设计和编码质量不佳，那么以后就会陷入麻烦。我们的目标是生成易于维护的系统，可以避免错误，并且可以以较低的成本添加问题和进一步的改进。为了实现这一目标，软件架构和工艺应该得到适当的设置。我们想要在质量、速度和复杂性之间保持平衡（如下图所示）。

然而，我们开发新功能的速度越快，确保软件质量就越困难，技术债务就越容易积累，导致开发过程变慢并出现更多错误。因此，我们希望从一开始就走得更慢，这将增加我们将来的速度。

问题是如何在第一时间避免创建技术债务。答案是拥有高质量的软件开发流程。以下是我们可以采取的一些方法：

1.为期望的结果设计系统。从一开始就在团队的创建中涉及架构师，通过定义它们的拓扑结构[7]，否则康威定律[5][6]将使我们的架构成为组织通信渠道的映像，而不是期望的架构。

2.为所有架构决策（ADRs）和技术文档编写文档。使其易于查找（将其放在代码库附近）。

3.在测试金字塔的所有级别上编写测试。目标是达到60-80%的代码覆盖率。

4.鼓励代码审查文化。让每个人都参与到代码审查中，并检查代码的可读性、设计、性能、安全性、可测试性和文档。

5.配对编程，其中一个开发者编写代码，而另一个提供反馈和建议。这会提高代码质量，实施此方法后我们就不需要代码审查。

6.允许开发人员进行重构。我们应该建立这样的文化，即无需征求修复技术债务的许可！尤其是如果这是可以在几小时内完成的事情。

7.遵循代码库标准，例如设计、命名和架构。然后通过工具如linter或您的CI/CD流程进行自动化。

8.测试驱动开发（TDD）是一种软件设计过程，每个功能都通过先编写测试，然后进行适当的实现来设计。

9.编写高质量的代码。首先教育开发人员深入了解他们的编程语言，并理解面向对象的概念、设计模式、重构、清晰代码原则、架构模式和风格，以及SOLID、YAGNI、KISS和DRY原则。

10.持续交付。代码以短周期进行调整，因此始终容易由其他团队成员进行验证。通过频繁发布和快速反馈来避免在生产中出现重大问题的方法。

参考文献
[1] “The WyCash Portfolio Management System.” Ward Cunningham, Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.
[2] “ Software Developer Productivity Loss Due to Technical Debt, “Besker, T., Martini, A., Bosch, J. (2019).
[3] “ Happiness and the Productivity of Software Engineers,” Daniel Graziotin, Fabian Fagerholm, 2019.
[4] “ Technical Debt Quadrant,” Martin Fowler, 2009.
[5] “Conway’s Law,” https://en.wikipedia.org/wiki/Conway%27s_law.
[6] “Conway’s Law,” https://martinfowler.com/bliki/ConwaysLaw.html.
[7] “ Team Topologies: Organizing Business and Technology Teams for Fast Flow,” Matthew Skelton, Manuel Pais, 2019.
[8] “ The influence of Technical Debt on software developer morale,” Terese Besker, Hadi Ghanbari, Antonio Martini, Jan Bosch, Journal of Systems and Software, Elsevier, 2020.