技术债务（Technical Debt）

什么是技术债？

技术债务（也称为技术债务或代码债务）描述了当开发团队采取行动加快交付某个功能或稍后需要重构的项目时的结果。换句话说，这是将快速交付优先于完美代码的结果。

如果您在软件行业工作过一段时间，那么您很可能听说过“技术债务”这个词。也称为设计债务或代码债务，这个短语（或更准确地说，比喻）广泛用于技术领域。它被称为包罗万象的包罗万象，从错误到遗留代码，再到缺少的文档。但究竟什么是技术债务？为什么我们这样称呼它？

技术债务最初是由软件开发人员 Ward Cunningham 创造的，他不仅是敏捷宣言的 17 位作者之一，还被认为是 wiki 的发明者。他首先用这个比喻向 WyCash 的非技术利益相关者解释了为什么需要为重构预算资源。

他当时并没有意识到，但他在软件界创造了一个新的流行词。后来，它成为无数学术研究、辩论和小组讨论的主题。

多年后，Cunningham 描述了他最初是如何提出技术债务隐喻的：

“有了借来的钱，您可以比其他方式更快地做某事，但在您还清这笔钱之前，您将支付利息。我认为借钱是个好主意，我认为将软件赶出门来获得一些经验是个好主意，但是当然，您最终会回去，并且当您了解有关该软件的知识时，您会偿还通过重构程序来反映你获得它时的经验。”

想要 了解更多可观看下面原文、视频：

是否有技术债务的简化定义？

由于隐喻本质上是抽象的，因此技术债务的真正定义取决于解释。多年来，不同的人已经为它制定了自己的个人定义。随着时间的推移，一些高度细微的解释已经发展，但处于高水平。我们可以看到几个可以帮助我们为技术债务建立具体定义的主题。

它是一个工具

就像有人可能会在房产被定价之前通过贷款进入蓬勃发展的房地产市场一样，技术债务通常被用作“获得成功”的工具。gitconnected 的创始人 Trey Huffine 从创业公司的角度解释了技术债务的作用。他的定义很简单，“技术债务是现在添加的任何代码，以后需要更多的工作来修复——通常是为了实现快速收益。”

它有后果

Shaun McCormick 对技术债务的定义更侧重于长期后果，“我将技术债务视为随着项目成熟而降低敏捷性的任何代码。请注意我没有说糟糕的代码（因为这通常是主观的）或损坏的代码。” 他认为，真正的技术债务总是有意的，而不是偶然的。

Gaminer 对他们所谓的技术债务谬误的解释主要集中在稍后支付利息的概念上。“当您在编写代码时走捷径以便更快地实现目标，但以更丑陋、更难维护的代码为代价时，就会发生技术债务。它被称为技术债务，因为它就像贷款一样。你今天可以完成比平时更多的事情，但你最终会付出更高的成本，”他们在 Hackernoon 的一篇文章中写。

这不是一团糟

有时，当试图定义一个有点抽象的概念时，了解它不是什么可能很有用。

在一篇热情洋溢的帖子中，长期担任软件开发顾问的 Bob 大叔写道：“一团糟不是技术债。一团糟只是一团糟。技术债务决策是根据实际项目限制做出的。它们是有风险的，但它们可能是有益的。制造混乱的决定从来都不是理性的。它总是基于懒惰和不专业，未来没有回报的机会。混乱总是一种损失。”

根据他的定义，承担技术债务始终是有意和战略性的。他的解释支持 McCormick 的说法，即糟糕的代码不符合技术债务的条件。稍后，当我们讨论对技术债务进行分类的各种方法时，您会发现并非所有技术债务实例都属于这一类。

技术债务的学术定义

随着技术债务的广泛自以为是的定义，一些学术著作试图为这个抽象概念提出一个公正的、具体的定义。例如，Information and Software Technology Journal 中的一篇文章以非常具体的术语定义了技术债务：

“技术债务描述了有意或无意优先考虑客户价值和/或项目限制（如交付期限）的软件开发行为的后果，而不是更多的技术实施和设计考虑……”

同一篇文章扩展了技术债务的隐喻，“从概念上讲，技术债务类似于金融债务，具有相关的概念，例如债务水平、随着时间的推移应计的债务及其可能的后果，以及偿还债务的压力。某个时间点。”

有不同类型的技术债务吗？

对于技术债务的许多定义，技术债务的类型也一样多。多年来，软件开发从业者一直在寻找新的方法来分类和传达技术债务。

2007 年，Steve McConnell 提出有两种类型的技术债务：有意的和无意的。据他介绍，故意技术债务是人们有意识地作为一种战略工具承担的技术债务。与无意的债务相反，他称之为“做得不好的非战略性结果”。

几年后，马丁·福勒将麦康奈尔的概念更进一步，并发表了他所谓的“技术债务象限”。该象限试图根据意图和背景将技术债务分为 4 类。Fowler 说，技术债务可以首先根据意图进行分类：是故意的还是无意的？然后更进一步区分它是谨慎的还是鲁莽的债务。

2014 年，一群学者指出，现有的技术债务分类框架并没有直接解决债务的具体性质。他们驳回了 McConnell 和 Fowler 提出的类别，并提议根据技术债务的性质而不是其是否具有战略性来对技术债务进行分类。

根据软件工程研究所发表的论文“走向技术债务术语本体论”，有 13 种不同类型的技术债务和一组关键指标。

• 建筑债务
• 建立债务
• 代码债务
• 缺陷债
• 设计债务
• 文件债务
• 基础设施债务
• 人债
• 处理债务
• 需求债务
• 服务债务
• 测试自动化债务
• 测试债务

技术债务不好吗？

如果您想要一个简单的答案：技术债务既不好也不坏，它就是债务。就像金融债务一样，关于技术债务是好事还是坏事，有几种思想流派。因此，我们将在这里讨论一些不同的观点，而不是寻找一个客观的答案。

当今大多数软件公司都面临着来自市场和竞争力的压力，需要快速开发和发布。初创公司尤其感受到这种“船或沉”的压力。这种对速度的需求导致许多产品和软件开发团队在承担技术债务或稍后发布之间做出权衡。

这就是为什么大多数敏捷团队的普遍共识是技术债务本质上并不是坏事。事实上，大多数（如果不是全部）软件产品都有一定程度的技术债务。当您考虑团队每天发布多少代码时（尤其是在敏捷环境中，工作软件是进度的主要衡量标准），这并不奇怪。

另一方面，许多严格按照 Waterfall 软件开发方法和其他文档驱动框架工作的软件开发团队并不认同这种观点。

正如史蒂夫·麦康奈尔（Steve McConnell）所指出的，对技术债务的态度不仅因公司理念而异，而且因部门和角色而异。

“我发现，与技术人员相比，业务人员对技术债务的容忍度通常更高。业务主管倾向于了解所涉及的权衡，而一些技术人员似乎认为唯一正确的技术债务数量是零。” 麦康奈尔写道，他解释说，他将这种厌恶归因于技术债务，因为这将不可避免地产生沟通挑战。

他说，技术人员通常的任务是向业务人员解释技术债务，他们可能不会立即看到其中的含义。“主要问题似乎是，与金融债务不同，技术债务不太明显，因此人们更容易忽视它，”他建议道。

所以这里的要点是，在确定技术债务是好是坏时，背景很重要。一般来说，您可以像处理金融债务一样考虑技术债务：直到出现问题才成问题。

原文连接：https://www.productplan.com/glossary/technical-debt/