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

本文最初发表在 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/