本文最初发表在 Understand Legacy Code，经原作者 Nicolas Carlo 授权，InfoQ 中文站翻译并分享。

管理层是不会让我对遗留代码进行重构的！

你认识到自己现在的处境了吗？那是多么令人沮丧的事啊！

作为一名开放人员，经常会遇到这样的情况：管理者似乎对修复已经存在的问题不感兴趣。

新功能！紧急发布！错误修复！推迟重构那个混乱的代码库总有这样的或那样的借口。😭

就算你解释了干净代码的优点和好处，管理者们似乎仍然不理解，也不关心。他们关注的重点总是成本和时间，而不是质量。而现在，面对不断积累的技术债务，就算你想去解决，也会感到有心无力。

IT 部门深陷在为不耐烦的客户提供生产支持的困境。
客户不会为重构买单。
感觉就像是失败的事业！

这样的形势已经逼得许多优秀的开发人员卷铺盖走人了。现在的情况啊，真是铁打的公司，流水的开发者。

管理者不是工程师

你需要帮助管理层了解糟糕的代码质量对商业有什么样的影响。

归根结底，对公司来说，最重要的是创收、盈利能力。为了降低成本、增加收入，管理层需要作出最好的决策。

因此，如果你想为重构说出理由，就应该学会商业语言。

作为一名前顾问和技术主管，这些都是我曾经做过的事情，所以，就让我来帮你一把。

可用于管理层的五个论点

1. “重构将减少功能边际成本的波动性。”

这句话是出自 J. B. Rainsberger 的名言：“软件设计经济学”（The Economics of Software Design）。

别逃避！这只不过是一种听起来似乎很明智的方式，把自己已经知道的事情说出来就好。

让我们来分解一下：

到目前为止，“重构将减少”这说得还不错。
“波动性”就是“不确定性”的另一种说法。
“边际成本”是指多生产一个单位的成本。
“功能”就是商业价值！是啊，我们都对商业价值感兴趣。

它的要点就是这五个论点的核心。当我们与非技术人员交谈时，我们却忽略了这一点：

用他们的语言来说。

不要用极客们惯用的话语。要谈经济、谈商业。这就是我的秘诀！

与你的管理者联系去吧。

所以，来试试这样跟他们谈论这个论点吧。毕竟，你知道这个论点到底是什么意思。

2. “在过去三个月里，我们用了 63% 的开发预算来解决质量问题。”

我会让你根据实际情况对这个数字予以调整。😉

此处的重点，就是要用数据来说话。这个技术宅肯定会影响到你的日常工作。你能证明这一点吗？

你当然可以！

下面是一些例子，你可以参考：

随着时间的推移，你的速度会怎么变化？你每次冲刺能拿到多少分？它会下降吗？
每周报告 Bug 的数量。每周修复的 Bug 数量。Bug 是否在积累？花在 Bug 修复上的时间是不是越来越多？
跟踪每周发生的紧急事件的数量。是否在持续？这个数量会不会上升？

给管理层看看劣质产品的成本。

额外建议：将这些数字与实际金额挂钩。💰

有一天，我参加了一个 Bug 的事后调查分析。这个 Bug 本可以通过静态类型检查来避免。代码是用 JavaScript 编写的。当时公司里正在进行一场迟日旷久的辩论：到底要不要采用 TypeScript。

进行事后调查分析的开发人员做了一些挖掘工作，并能计算出那个 Bug 对业务的影响。

就在这个 Bug 存在的那几个月里，已经让我们损失了 100 万加币。100 万加币啊！

仅凭这一点，TypeScript 就值得投资！

因此，公司决定，新的服务将用 TypeScript 实现，而关键服务将通过类型检查重新审查。

3. “我们拿了技术贷款，为了更快地交付，我们需要偿还一些债务，以保持降低上市时间。”

我再说一遍，用他们的语言来说。

使用比喻可以非常有效地传达信息。它通过与他们所熟知的东西联系起来，可以帮助别人理解他们不熟悉的概念。

“贷款”是管理者们都会熟悉的一个概念。“技术债务”也是一个著名的比喻。

你还可以将公司想象成一个餐厅，把代码库想象成这个餐厅的厨房。当你任由盘子堆积如山时，外面等待的客人越来越多，问题会变得非常棘手，在这种情况下，你的员工需要开始洗碗刷盘。

4. “我们可以通过将 10% 的时间投入到代码质量上来减少员工离职带来的影响。”

我们已经讨论了劣质产品的直接成本。

但有一个恶性的因素可能会被忽视：员工离职。

如今，企业要想留住开发人员已经很难了。尤其是优秀的开发人员。当员工士气低落时，他们就很容易会跳槽。一些能让他们摆脱困境的东西。

嘿！也许你已经在那里了，梦想着有一片更绿的青草！

现在，请提出一个问题：

为了更换一个已离职的开发人员，我们需要花多少钱？

要吸引新的人才，聘用他们并让他们入职。而这既要花钱，又要花时间，还会拖累团队的效率。

你的管理者肯定不愿意每年都更换开发人员。减少员工离职率是一个令人信服的理由。并且，如果能有个解决技术债务的计划，就已经对团队士气起到了提振作用。

5. “将预算的 20% 用于重构，可以减少一半的首次回应时间，并对开发人员的工作效率带来正投资回报率。”

首次回应时间（First Response Time，FRT），是客户支持的关键指标。

让客户满意，对企业来说很重要。

重点是：

获取对客户支持部门重要的指标。
确定一些反复出现或需要开发人员解决的问题。
提出一项计划，通过解决问题的根源，来减少支持问题的数量。

通过解决这些问题，开发人员在协助客户支持方面将花更少的时间。这将弥补所投入的时间：正投资回报率。

额外建议

但最终他们还是做出了决定

对吗？

好了，我刚才给你了五个论点，这些论点可以帮你向管理者们论证解决技术债务的重要性。

但是，我觉得在你去找管理者谈谈之前，我还应该给你最后一个额外的建议。

需要重构时就动手吧。

重构不应该是实现功能之外的独立步骤。事实上，你无法预知下一个功能是什么。因此，你必须对代码进行重构，使其适应新的现实。

这是你工作的一部分。

作为一名专业开发人员，你知道怎样才能不断带来商业价值。

这是行之有效的做法，即使是在遗留代码库上也是如此。但也就这样了，不会再好到哪里去了。而且，你也不可能做到随时进行大规模的重构。但至少，情况不会变得更糟糕。

使用遗留代码并不是一件什么好事，而是为了更好。

每修复一个 Bug，就要多花一个小时编写一个自动化测试。对于每个功能，都要多花一天的时间来清理代码。让改变变得更容易。每天都要如此。这样，几个月后，这个习惯将会对你的工作效率产生巨大的影响。

你知道为什么吗？

因为这些利益复合，降低了功能边际成本的波动性！

作者介绍：

Nicolas Carlo，在加拿大蒙特利尔生活和工作。他创建了软件工匠蒙特利尔社区（Software Crafters Montreal community），该社区关注构建可维护的软件。

原文链接：

https://understandlegacycode.com/blog/5-arguments-to-make-managers-care-about-technical-debt/

创作场景

怎么说服你的老板重视技术债？