当我们谈论“技术债务”时，很容易将其与不同类型的金融债务相提并论——无论是健康债务（如抵押贷款）还是问题债务（如信用卡债务）。无论是哪种债务，都需要持续偿还，否则您将面临破产的风险，不得不重新开始。

然而，理解技术债务并不总是那么简单。金融类比只能让我们在一定程度上理解技术债务是什么、它为什么重要以及我们如何优先解决它。要理解和解决我们的技术债务，我们需要改变我们的想法。

在本指南中，我们将分析什么是技术债务、技术债务的原因以及如何有效地管理技术债务。

目录： 

• 什么是技术债务？
• 我们能避免技术债务吗？
• 技术债务的类型及其影响
• 技术债务在实践中如何体现
• 解决技术债务
• 管理技术债务的 3 个技巧 

技术债务，也称为技术债务或代码债务，是指开发人员匆忙完成项目，优先考虑短期开发时间或捷径，而不是长期一致性或质量，从而增加后续新工作的成本和挑战。简而言之，技术债务优先考虑速度而不是准确性，并将这种选择的成本推到未来的开发周期。

您的团队可能需要快速发布最小可行产品 (MVP) 以获得超越竞争对手的优势。该产品可能不需要完美无缺，但需要快速上市，因此您的团队可能会故意积累技术债务，以便更快地将产品交到客户手中。

这是一个合理的决定：收集早期用户反馈对于找到产品/市场契合度和满足客户需求非常有价值。在这种情况下，技术债务不一定是坏事，负债也不一定是一个坏决定。就像金融债务一样，它只是意味着你为了尽快得到对你来说很重要的东西而承担了一些债务。 

你永远不想承担无法偿还的债务，但走捷径和加快开发进程往往是一个明智的战略决策。但这应该是一个决定！

技术债务的产生原因多种多样，有些是故意决策的结果，有些则仅仅是随着时间推移而产生的变化。有时，技术债务源于代码编写不当、缺乏培训或项目指导方针不明确，但也可能源于编写得非常好但无法像以前那样发挥其功能的代码。

我们很少能够完全避免技术债务，但通过了解技术债务是什么以及它是如何产生的，我们可以更经常地做出何时承担它的慎重决定。

对技术债务的普遍看法是，它源于工程师为了更快取得成果而草率或粗心大意。虽然技术债务可能是由于鲁莽（无意或无意）造成的，但也可能被故意利用。

这就是信用卡和抵押贷款的类比——工程团队现在借用效率来换取以后必须做更多的修复代码的工作。

开发专家马丁·福勒 (Martin Fowler) 认为，从高层次来看，技术债务的原因可以分为四类，他称之为技术债务象限：就像人们可以负责任地或粗心地借入资金一样，团队可以策略性地或鲁莽地制造技术债务。

• 故意鲁莽：故意走捷径以加快交付时间，但没有充分了解未来的影响

• 深思熟虑和谨慎：当你清楚了解未来的影响并愿意承担风险时 

• 疏忽和鲁莽：由于缺乏理解或知识，或匆忙完成项目而无意中发生，通常会造成极端的未来后果 

• 疏忽和谨慎：当出现无法避免和意外的问题时发生，通常来自经验丰富的开发团队 

这种观点使我们更接近于对技术债务的健康、同理心的理解——它不一定（甚至经常）是性格缺陷或个人不足的结果。

未解决的技术债务可能会让团队维持一段时间，但最终，这些问题将开始影响生产过程和代码库的更大领域。

除了组织因素外，还有人为因素。敏捷教练 Declan Whelan分享了技术债务在个人、团队和组织层面影响工程公司的一些方式：

当然，管理者不想等到出现最严重的症状时才去解决技术债务。但不管怎样，工程团队已经背负了技术债务。几位技术领导者都曾说过，团队发布代码的那一刻，就变成了技术债务。尽管有时技术债务是故意造成的，团队决定加快项目进度，因为他们知道以后可能不得不承担后果。 

作为领导者，关键在于学会识别和分类技术债务，这样您才能有效地决定如何偿还债务。

除了 Fowler 关于风险和意向性的论点之外，2014 年，一组研究人员创建了一个技术债务类型的分类法，这些术语不仅用于描述债务本身，还用于描述这些成本在开发过程中如何在利息开始累积时体现出来：

代码债务是指开发人员为了在短期内加快代码生产速度而走捷径，导致代码难以理解或难以更改。这种债务最明显地体现在产品最重要的功能或核心差异化因素上。

代码债务的影响各不相同，但它对产品速度的拖累是，因为即使是很小的变化也会造成认知负担，从而导致产品速度下降，使满足客户需求或适应新的市场机遇变得越来越困难。

文档债务是指开发过程仓促进行且未仔细记录，或为了迭代产品而降低文档优先级的情况。文档债务的影响直到您的产品到达客户手中时才会显现，他们开始提问，却发现答案已经过时或错误，或两者兼而有之，导致用户认为产品质量不合格。

如果在开发过程中测试被推迟或延期，您很容易对产品质量产生错误的信心。更糟糕的是，从长远来看，您可能很难或不可能知道您为创建新功能所做的努力是否破坏了旧功能，或者您是否意外地将早已解决的错误重新发送给了客户。

流程债务是指无效和过时的流程随着时间的推移而积累，成为一套未经优化的例行公事，而不是解决实际问题的解决方案。当这种情况发生时，组织会发现自己很难交付代码，即使代码写得很好，也很容易理解。流程债务通常是由于之前的失败而积累的，而那些足够规避风险的组织也很难在合理的时间内交付高质量的软件。

当设计变更提议在方向改变之前只得到部分实施时，就会发生这种情况，当解决产品不一致问题的后续努力遭遇同样的命运时，这种情况很容易加剧。结果就是用户体验中出现令人困惑的不一致、错误和半成品或缺失的功能，就像文档债务一样，无论底层软件执行得多么好，用户都会觉得产品是半成品。

让我们回到上面的定义：技术债务是任何在开发过程中产生摩擦的事物。最广泛和最容易理解的技术债务形式是那些在代码库本身中表现出来的债务。但技术债务也可以采取不一定与一行代码相关的形式。

为了让您更好地理解现实世界中的技术债务，这里举几个例子：

缺乏自动化和认知负荷的存在都是阻碍开发团队进步的摩擦点。这是因为他们必须手动完成每个流程才能有效地完成工作，这最终会减慢他们的进度。

当然，所有工程师都会在脑子里保留一些概念，每个人都必须手动完成某些事情。但就像笔记本电脑的设计初衷是轻松处理一定的处理负载一样，如果运行太多程序，它就会开始陷入困境。 

由于缺乏自动化或认知负荷过大而产生的技术债务最终也会在代码中显现出来。 

复杂的法规和不明确的指导方针只是两个例子： 

• 复杂的代码库：如果代码库变得过于复杂和交织，工程师就很难理解他们所做的更改所产生的所有连锁反应。这不是他们在完成新代码时能够合理认知地承受的信息。
• 需求模糊：由于需求和最终目标不明确，开发人员可能必须考虑太多意外情况和可能性才能清晰地向前推进。

同样，缺乏背景也是一种技术债务。我们将这种债务分为两种类型：面包屑和日常实践。

• 面包屑：如果开发人员需要深入研究代码库的某个部分，代码本身或开发人员可以参考清晰的文档会很有帮助。代码本身可能有用，但如果缺少提交注释或原始开发人员思维过程的其他线索，那么后来的开发人员就无法轻松、迅速地理解代码的用途。
• 日常实践：对于日常实践，工程师可以通过问自己这样的问题来改进他们留下的线索：“我是否使用了清晰的变量名和函数名？我是否使用了可靠的编码原则？我知道这些原则是什么吗？”个人实践可以为其他工程师建立重要的背景理解。

然后，还有一些完全非技术性的人为因素会造成技术债务。许多开发人员在相对较小的、通常是跨职能的团队中工作，当这些团队无法独立工作并实现目标时，技术债务就会累积。 

人为因素常常会阻碍团队全面改变、操作、维护和拥有其领域的能力。 

以任何一种形式列出技术债务的每一次迭代都是不可能的。每个代码库和每个团队都会经历其独特的版本，但如果要概括的话，那就是技术债务实例通常是不可见的。

软件是由组织开发的，而组织的领导力——他们如何设定目标、价值观和指标，如何建立流程和认可成功——至关重要。这不仅在新产品和新创意的创造中如此，在对市场上已有产品的维护和支持中也是如此。

讨论技术债务时，人们往往会指责对方，这对工作环境来说可能是极其有害的。管理者不应将技术债务视为一种过错，而应将其视为一种成功，以及成功的代价：团队积累的技术债务也帮助他们达到了应有的水平。即使这些债务现在一团糟，团队仍然可以庆祝迄今为止取得的进展。

Andrea Goulet将偿还技术债务比作改造房屋。无论你建造的房子有多好，你最终都需要更换屋顶。其他功能或设备可能老化得不太好，需要更换，但这并不意味着原来的屋顶或设备有故障。你只是在做你的房子需要继续使用的工作。

代码库和团队流程也是如此，尤其是随着团队随着时间的推移而变得更好。曾经行之有效的策略和方法可能已经过时或效率低下。较新的方法可以取代过时的方法，并且快速、廉价的解决方案可以在资源允许的情况下换成更高质量的替代方案。

很少有工程师会否认技术债务的存在和偿还的必要性，但需要具体切实的调整来体现为流程和工作流程的实际变化。

这些是行业领导者提出的一些方法，有助于改变工程团队对技术债务的态度和方法。 

在向其他部门和利益相关者提出想法之前，工程团队需要就解决技术债务的重要性达成共识。

工程师需要参与其中，才能使任何债务计划变得有意义。确保他们了解此类项目的必要性，确保他们得到支持并因其成果而得到认可（即使不是每个人都喜欢其中的重构工作），一旦团队获得其他人的认可，这将是无价的。

此外，你的工程团队中可能已经有修补者——那些在解决技术债务挑战中茁壮成长的开发人员。

Yvette Pasqua提出了她所在组织以前使用过的一种策略，即从词汇表中移除“技术债务”一词，并用“持续的产品健康”取而代之。

“当我们谈论技术债务时，好像每个人的肩膀都耷拉下来了，”Pasqua 说。 

“因此，我们尝试将其称为持续产品健康，它对我们帮助很大，让人们将其视为和谈论它一样，成为我们每天所做健康、快乐的一部分。”

团队可以将这一长期策略视为自我保健，因为它类似于长期关注健康，例如去健身房或健康饮食。你不会只在一年中的两周内保持“健康”；这是一种日常习惯。产品健康也是如此。

进一步贯彻上述概念，将技术债务维护作为常规做法，使这种方法成为现状的一部分。 

这意味着，花时间清理代码或确保现有产品正常运行应该成为你正在进行的任务的一部分。毕竟，团队在日常和常规职能方面的文化会对技术债务产生重大影响。认识到每天维护产品健康的需要将使技术债务在未来更易于管理。

技术债务积累的首要原因之一是，很少有组织有专门负责减少债务的团队或个人。每个人都有围绕开发产品、提升客户体验和增加销售额的使命，但很少有人完全承担技术债务。

因此，一旦工程领导者获得上层利益相关者的支持来解决技术债务问题，下一步就是争取这些利益相关者为工程计划提供全组织支持。高层支持可以为工程团队提供更大的杠杆，让他们投入时间和资源来有效减少债务。

获得上层利益相关者认可的一种方法是同时规划更大的技术债务计划，并以公司规划其产品战略和路线图的方式进行。无论是每月、每季度还是每半年，携手合作都可以简化组织的流程并提高工作的可见性。