债务，Tech Debt 以及其他

当人们争论 "tech debt" 的有效性时，其他人则在问：“在软件开发和交付中，我们还有哪些其他类型的‘债务’？”

2025年3月9日 tl;dr 我的同事 Scott Porad (CTO, VP Engineering) 在 LinkedIn 上发帖提问：“除了 tech debt，还有哪些其他类型的债务？” 他列出了一些，然后请其他人参与讨论，结果清单变得......有点长。而且很有趣。这让我更深入地思考了这个比喻。

他的清单 包括财务债务（最初的 debt）、产品债务（产品中的缺陷，影响收入或导致支持成本）、运维债务 (Ops Debt)（运维团队执行的手动流程，因为软件不支持这些流程）、流程债务（跳过软件开发过程中的重要步骤，导致质量或速度问题）和组织债务 (Org Debt)（关键岗位人员未配备，导致质量或速度问题）。

然后他请其他人分享他们最喜欢的 debt 类型，答案如潮水般涌来。许多答案（我不会全部列出，部分原因是我想让你阅读原始帖子！）都很有趣，我认为它们可以分为以下几个不同的类别：

• 技术方面. 无论是数据、UX/Design、后端，甚至是过度依赖开源而没有“回馈”的选择。文档也属于这一类。
• 程序方面. 哪些流程是由人工完成的，从而耗费了团队的时间、金钱或精力？ 有哪些事情因为公司害怕建立流程而被贴上“不敏捷”的标签，而被“轻量级流程”所掩盖（类似于 "agile"）？
• 思维方面. 哪些假设被证明是错误的？ 哪些假设“当时”是对的，但现在已经不再成立？ 组织是否在追逐正确的问题？ 哪些知识是需要知道的人所缺少的？
• 文化方面. 任何人类群体都会形成一种文化，但这种文化是在为业务服务，还是在阻碍业务发展？
• 人才方面. 一些回复提到了“年轻”或“经验”债务，例如缺乏对初级人才的投资，或者拒绝承认团队中有经验的资深人才的价值。 同样，在原始意义上“不够”，例如，团队人员不足。
• 支持方面. 这是一个比较模糊的包罗万象的类别，但包括诸如“营销”（长期忽视营销实践，导致品牌和客户关系受损）或“法律”（未能认识到法律和/或监管方面的必要性，使公司陷入法律风险）等方面。

再次，我鼓励读者去查看 Scott 的原始帖子。 评论中涌现出如此多的内容，以及回复的广泛性，着实令人着迷。

这让我开始思考：这些真的是“债务”吗？ 或者，更确切地说，它们是不好的吗？

债务：一个比喻

如果我们回到 "tech debt" 的最初定义，如果我没记错的话，我第一次听到它是在 2000 年代后期 NFJS 巡回演讲中 Mike Clark 提到的，但 Wikipedia 告诉我 Ward Cunningham 在 1992 年首次创造了这个术语，作为一个比喻来向他的老板解释，做出短期决策可能会适得其反，并在以后造成问题，因此需要投资来重构代码。 特别是，这个类比的重点是“虽然 tech debt 可以在短期内加速开发，但如果放任不管，可能会增加未来的成本和复杂性。” 顺便说一句，Wikipedia 对 "Technical debt" 的官方定义是：“因选择权宜之计而非更稳健的解决方案而在未来产生额外工作量的隐含成本。”

Ward 是这样说的：

“第一次交付代码就像负债。 只要及时通过重写来偿还，少量的债务就可以加速开发…… 当债务没有偿还时，危险就会发生。 每分钟花在不够正确的代码上都算是该债务的利息。 整个工程组织可能会因未合并的实现（面向对象或其他方式）的债务负担而陷入停滞。”

Martin Fowler 后来也 涉足了这个领域，他指出，债务有时是出于好的目的而故意承担的（汽车贷款、抵押贷款），有时是由于计划或执行不力而意外累积的（信用卡债务）。 他将其比作一个沿两个轴象限：鲁莽 vs 谨慎，故意 vs 无意：

在几乎所有债务的“痛苦”案例中，无论哪种类型，最糟糕的象限都是无意/鲁莽：我们在没有意识到的情况下做出了错误的决定，并在以后为此付出了代价，非常痛苦。 稍微好一点的是故意/鲁莽，我们明知故犯地做出了鲁莽的决定（这本身就提出了问题），并且仍然在以后为此付出了代价，非常痛苦。“痛苦”的部分是大多数人对债务以及债务比喻反应如此强烈的原因，也是为什么当这个话题出现时，它经常会引发下意识的反应。

当我们看到那些“债务”清单时，几乎所有债务都可以很好地符合这个定义：对于主题 S，我们承担了在未来做额外努力的隐含成本，以便现在采取权宜之计，而不是更稳健的解决方案：

• 技术方面：数据。 我们承担了额外的成本，包括重构我们的数据和打破孤岛，以便现在采取权宜之计，如非规范化的数据库或维护独立的数据库。
• 技术方面：架构。 我们承担了额外的成本，包括重构我们的架构，使其更具可扩展性、更安全或更适合移动设备，以便现在采取权宜之计，如交付一个基本的三层 CRUD 应用程序。
• 技术方面：UI/UX。 我们承担了额外的成本，包括构建一个更具凝聚力和连贯性的用户体验，以便现在采取权宜之计，如交付一个笨拙的、功能性的 UI。
• 人才方面：年轻债务。 我们承担了额外的成本，包括在以后指导更多的初级开发人员，以便现在采取权宜之计，如让所有高级工程师现在都在该项目上工作。
• 人才方面：经验债务。 我们承担了额外的成本，包括在以后构建我们在领域或系统方面的经验，以便现在采取权宜之计，如解雇该项目上的所有高级工程师。

......等等。 对于 Scott 的帖子中提出的每一个主题，都有一个非常清晰的感觉，即“我们正在采取短视的观点，这在长期内会伤害我们”。 是的，我们在 IT 行业的许多人都经历过这样的故事（即使不是多次），并且对此感到后悔。

但我认为这只是故事的一半。

债务与进化/迭代

我越是深入研究这些，就越意识到这里隐藏着另一个想法，那就是有时我们承担债务是因为我们不知道未来。 这样想：如果我们发现在几次迭代后，采取这种方法是一个错误，那么在一个特定领域（应用程序、数据库、愿景、流程、人才……）进行大量投资是否有意义？ 想想你最喜欢的独角兽创业故事，以及那些独角兽需要“转型”的频率——也就是说，放弃他们正在做的事情，尝试完全不同的事情——以便维持生计或尝试其他事情？ 如果公司_没有_采取短期方法，而是投入大量的时间/精力/金钱去做一些现在基本上毫无价值的事情，那么所有的投资现在都将是一种浪费，因此是一种损失。

或者更糟糕的是，成为沉没成本谬误的牺牲品，并坚信“他们现在不能放弃！”，并且完全无法转型。

事实是，在大多数实际的“获得债务”的案例中，参与做出决策的人面临着一个基本难题：“我们是否应该尽快交付，知道我们交付的东西会有一些固有的问题，需要在以后解决？” 尽管如此，这个问题中隐含的是另一面，通常有助于呈现为整个决策过程的一部分：“我们是否应该晚些交付，知道如果我们等待太久，机会之窗将会部分或完全关闭，并使整个企业变得毫无意义？” 很少有人大声说出这个“晚些”部分，并且在对“我们 n 个月或几年前选择了权宜之计，现在我们已经到了这一点”的 事后 分析中，从来 没有人提到这一点。 请记住，如果他们选择了长期解决方案并失败了，我们就不会在这里讨论它了！ 虽然在 事后 判断这个决定很容易，但就像当时做出的所有决定一样，“正确”的选择并没有那么清晰。 更糟糕的是，我们对这里选择的有效性并没有很好的清晰度，因为我们只记得结果象限的四分之一：

“债务结果” | 选择：债务/权宜之计 | 选择：无债务/“正确”
---|---|---
失败结果 | 无数据/讨论 | 无数据/讨论
成功结果 | “啊，痛苦！” | 无痛苦可讨论
换句话说，上图中有 25% 的方格获得了 100% 的讨论和焦虑。 根据对这些数据的任何合理解释，这表明我们花这么多时间责骂人们做出 Debt 选择的主要原因是这是我们唯一谈论的选择。

债务作为比喻

我认为，总的来说，债务这个比喻是有效的，而且效果很好。 显然，它不仅适用于“技术”债务，正如 Scott 的帖子所表明的那样，作为一个组织，我们可以承担许多不同类型的债务。 Fowler 的鲁莽-谨慎-无意-故意的象限有助于对围绕债务的有意识决策进行分类，但显然依赖于相关人员来描述“鲁莽”和“谨慎”之间的区别。 在当下，专注于此时此地的解决方案可能感觉是谨慎的——公平地说，通常是这样，正如整个 YAGNI (You Ain't Gonna Need It) 敏捷思维所体现的那样——只有后来才感觉是鲁莽的。 但这种 事后 分析本身就是一种特权，因为这意味着我们已经取得了迄今为止的成功，能够回顾这些决策并尝试恢复/重构它们。

或者这样看：如果我们没有承担抵押贷款来购买我们的第一套房子，我们有多少人会成为永久的租房者？ 有多少人能够真正达到在银行里存了 50 万美元、100 万美元甚至更多的钱，等待直接购买房屋的地步？ 债务本身并不坏； 只有当它是无意/鲁莽的债务时，我们才会感到焦虑。

Tags: management engineering design