技术债务不是债务；这甚至不是技术性的

花一点时间写下这个问题的答案，“什么是技术债务？”然后阅读这篇文章并重读你的答案——看看它是否仍然有意义。技术债务是我们工作过的每家公司技术部门的常用术语。没有人解释技术债务；我们认为这是作品的基本属性。在我们发现 Edith Tom 等人的一篇论文之前，我们从未质疑我们对它的理解。题为“技术债务的探索”。事实证明，我们根本没有理解它。现在，学术界关注的一个主要问题是严谨性。学者们喜欢深入研究一个主题，检查细微差别，并带来清晰。在彻底审查了 100 多篇关于技术债务的开创性论文后，我们将其视为一个无定形的幽灵，在使用上存在巨大差异和不一致。接下来，我们开始在实践中研究它，询问了同事、前同事和在职技术人员，但在那里也找不到令人满意的解释。最终，我们回到了原始来源以了解历史——并了解它的演变。一致同意的一件事是：技术债务一词来自沃德·坎宁安 (Ward Cunningham)。坎宁安是维基的发明者和科技传奇。 1990 年代初期，他的团队正在构建一款财务软件，他用金融界的一个比喻向他的经理解释了团队是如何运作的。正如他后来在 1992 年 OOPSLA 会议上的一篇论文中所解释的那样：只要通过重写及时偿还，一点点债务就能加速开发。对象使此事务的成本可以承受。当债务没有偿还时，危险就会发生。花在不太正确的代码上的每一分钟都算作该债务的利息。整个工程组织可能会在未整合的实施（面向对象或其他方式）的债务负担下陷入停滞。这个比喻很快成为标准技术论述的一部分。因为会议关注面向对象的开发，所以它在那个社区举行。 Martin Fowler 和 Steve McConnell 等热门技术作者很快就接受了它，帮助它成为软件开发中更广泛语言的一部分。今天，“技术债务”的使用已经司空见惯，从 1992 年的一篇论文中提到到 2021 年 7 月 Google 搜索的超过 3.2 亿个结果。更快地实现目标，同时打算在未来做得更好。 2009 年，他对隐喻的变异方式感到不满，在 YouTube 视频中澄清了技术债务的使用。坎宁安不喜欢技术债务意味着“现在做得不好，以后做得更好”的观点。这从来都不是他的本意。他说：

我从不赞成编写糟糕的代码，但我赞成编写代码来反映您当前对问题的理解，即使这种理解是片面的。但为时已晚。到那时，这个比喻已经超出了他最初的意图。它在野外，为全球范围内的可怕决定提供了借口。技术债务现在既代表有意承担的债务，也代表更阴险的形式，隐藏或无意的债务——在团队不知情的情况下承担的债务。它还超越了代码并传播到技术架构、基础设施、文档、测试、版本控制、构建和可用性等各个领域。技术债务允许从业者通过债务的视角来看待技术交付。这是合适的镜头吗？债务偿还有一个重要特征：易于理解。债务偿还具有三个容易理解的特性——本金、利率和期限（即偿还时间的长短）。但是在比较技术债务时，没有约定本金，也没有约定欠款。技术债务没有利率的概念，因为技术人员将每个项目单独评估为独特的工件。最后，期限长度在技术债务中并不是一个固定的概念——事实上，克劳斯施密德甚至认为未来的发展应该是技术债务评估的一部分。已经付出了巨大的努力和精力来试图计算许多技术和学术部门的技术债务的准确数字。不幸的是，试图将直接的数学表示粘合到隐喻上似乎失败了。从这个角度来看，技术债务作为一种债务的想法并不站得住脚。那么它是技术性的吗？这取决于我们是只考虑最初的行为，还是考虑随之而来的后果。如果攻击者打旁观者的脸，我们不仅要考虑攻击者的动作（始发动作），还要考虑对旁观者的伤害（始发动作的影响）。从这个角度来看，技术债务只能是技术性的，前提是我们考虑它的起源，而不是它产生的影响。技术人员采取原始行动；企业会受到这些决定的影响。技术债务的影响：一旦我们意识到技术债务是一个公司范围内的问题，我们就不能再将其视为技术债务，这个标签太狭隘，没有传达其重要性。事实上，我们目前正在进行的研究表明，技术债务甚至可能对公司产生影响，我们需要从更广泛的角度看待（例如它对社会的影响）。最重要的一点：我们必须扩大对技术债务的认识。就像公司高管检查财务现金流和销售渠道一样，我们必须向这些受众传达承担技术债务的后果。我们最重要的挑战是找到一种共享语言来帮助业务利益相关者了解技术部门做出的未知决策的重要性。

最后，回顾一下您在本文开头是如何定义技术债务的。您是否传达了行动或影响？适合商务人士吗？什么是？如果您喜欢这篇文章，请与三个会欣赏它的人分享。非常感谢你，马克。此条目发表在文章分类目录并标记为架构、技术债务、决策、软件设计。为永久链接添加书签。