正确管理技术债务可以决定软件项目的成功和失败。另一方面，忽视或未能识别技术债务可能导致更高的开发成本和更低的商业回报。有这么多的利害关系，理解和处理技术债务应该是软件开发人员和高级决策者的优先事项。

本文是技术债务的初学者指南。我们解释了该术语的含义，它如何影响软件开发项目，以及如何最好地衡量组织中不同类型的技术债务。我们还提供了一系列有效的实践来帮助控制技术债务。

技术债务（也称为技术债务、代码债务或简称TD）是在软件开发过程中为了获得短期成果而走捷径的结果。开发人员推迟了某些工作以达到可交付成果或截止日期，但“陷入债务”，他们必须通过未来的返工来偿还。

当开发人员依赖易于实施、次优的编码或设计解决方案来加速生产时，通常会出现技术债务。然后，团队必须（在某个时候）返回该产品以添加更多功能或修改代码。以下是公司在质量和速度之间进行权衡的一些常见原因：

技术债务的功能与任何其他类型的债务一样：您在短期内获得便利，但以后必须支付利息和利息。快速修复和低于标准的解决方案加速了软件开发，但在未来解决这些问题是昂贵的、受限的和耗时的。未解决的技术债务的一些常见症状是：

敏捷宣言的作者WardCunningham是第一个使用术语技术债务来描述累积技术问题的影响的人。他还使用术语“?cruft”来描述敏捷团队需要修复或“回馈”以消除技术债务的隐秘代码问题。

虽然技术债务总是具有影响力，但不同类型的债务比其他债务风险更大。您产生的债务可能是故意的，也可能是无意的：

MartinFowler的技术债务象限通过定义两种类型的故意债务和无意债务进一步细分了技术债务的类型：

当团队知道缺点但没有立即计划如何或何时解决问题时

当开发人员知道他们正在积累兴趣但决定现在发布并稍后修复错误时

当开发人员盲目地实施解决方案而没有意识到他们正在负债时

当团队在发布后了解到实施错误时

我们还可以根据团队“欠”什么来区分不同类型的技术债务，例如：

技术债务本质上并不坏。大多数开发团队无法避免偶尔在速度、成本和质量之间进行权衡。只有在以下情况下，技术债务才会成为一个问题：

就像稳健的金融债务一样，智能技术债务在某些情况下可以带来巨大的好处。战略性债务可以帮助：

技术债务对项目的影响取决于团队如何处理他们所欠的。如果公司：技术债务可能是一种有价值的工具：

技术债务也是不可避免的。软件开发不断发展的本质意味着每个产品都需要随着时间的推移进行维护和重建。

以下是故意和意外技术债务的三个真实示例。

示例1：审慎而深思熟虑的技术债务

在此示例中，团队使用具有已知问题的框架来实现早期发布。一旦公司达到目标，开发人员就会回去重构组件并消除代码问题。

示例2：鲁莽和无意的技术债务

在这种情况下，陷入技术债务不是计划中的决定，而是技能低劣的结果。该团队发布的产品存在错误，这些错误会增加云成本并增加客户流失率。偿还债务的唯一方法是聘请更有经验的开发人员重新编写代码。

示例3：鲁莽和蓄意的技术债务

在此示例中，团队使用WordPress构建电子商务网站。CMS无法处理高流量，导致客户放弃购物车并转向竞争对手。唯一的解决方案是将网站迁移到更合适的平台。

以下是一些技术债务原因的真实例子：

以下是有助于评估组织中技术债务水平的指标：

没有一种万能的方法来减少技术债务。一些适用于小型初创公司的策略并不总是适用于解决企业级系统问题的100多人团队。每家公司都应该采取两个总体方向来控制技术债务：

让我们看看您可以使用哪些不同的最佳实践和策略来控制当前的技术债务并限制出现的新错误的数量。

跟踪和消除垃圾至关重要，因为技术债务可以在多个开发周期中幸存下来。处理工艺是一个五步过程：

这个过程应该是连续的，并且是每个发布周期的一部分。理想情况下，杂乱无章的跟踪和删除应该是您的开发或DevOps团队的KPI之一。

即使在积极解决现有错误时，低质量、廉价的开发人员也会产生更多的技术债务。当您考虑交付性能较低的产品所造成的收入损失时，低质量的开发人员花费的成本比您为经验丰富的团队支付的费用要高。

在招聘开发人员时，您应该接受以下两种心态：

较小、较好的团队比较大、技能较低的部门运作得更好。雇佣两名顶级开发人员通常比雇佣十名表现不佳的程序员更好。一旦你有两个可靠的工程师来指示方向并监督发布，你就可以开始引入初级员工进行内部培训。

这种做法与上述做法有关；通过衡量以下指标来确保团队编写高质量的代码：

密切关注这些指标有助于推出低负债软件产品。请记住根据高水平的工作而不是编写代码的数量来奖励员工。还可以考虑创建编码风格指南。通过记录理想的编码实践，团队会发现更容易编写更简洁的语法并花更多时间审查代码。

手动测试不是控制技术债务的长期选择，这就是为什么您的团队应该转而寻求建立和依赖自动化测试的原因。虽然建立和维护自动化测试需要时间和精力，但缺少手动测试将确保您更准确、更一致地发现问题。

开发团队应持续记录存储库中的所有更改。如果出现问题，开发人员可以轻松追踪其来源并记录债务。此记录还有助于分布式团队和需要仔细更改的高度复杂的项目（例如迁移到云或对遗留软件进行现代化改造）。

并非每个开发人员或利益相关者都应就技术债务做出决定。决策应该来自了解项目并具有产品权衡经验的合格团队成员。

考虑在您的公司内建立一个专门的团队来制定与技术债务相关的决策。这个团队应该：

并非每个机会都值得为之举债，因此专门的团队还应评估技术债务墙上的选择权。

留出时间和资源来解决债务问题

优先考虑良好的文档和质量代码至关重要，但您还需要确保您的团队有足够的时间和资源来处理技术债务。调试产品和解决问题既耗费资源又耗费时间，因此如果开发人员面临不断交付新功能的压力，他们将无法解决与债务相关的问题。专家建议，平均Scrum团队应该将15%到20%的sprint周期用于重构代码和修复与债务相关的错误。

你的团队应该定期进行代码重构，以确保持续偿还技术债务。重构是重组杂乱的代码段以使其更多的过程：

重写软件产品中的组件可以消除冗余并提高性能，这两者对于偿还技术债务至关重要。您还应该考虑改进团队的代码审查程序并引入代码检查（自动检查源代码中的程序和样式错误）。

调整贵公司对“完成”的定义

开发一个可重复的公式，指导开发人员如何进行实验或向产品添加新功能。该程序应包括可管理技术债务的标准，因此在软件满足设定要求之前，团队不应将任何产品视为“完成”。

在速度和质量之间取得适当的平衡

只要您的团队明白他们必须“偿还”他们的技术债务，采取战略捷径并偶尔以质量换取速度，就可以为您带来相当大的竞争优势。快速上市和快速概念验证是当今市场的一切，因此明智地使用技术债务并确保团队主动管理平衡以避免未来的障碍。