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

云栖号资讯:【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来!

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

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

作为一名开放人员,经常会遇到这样的情况:管理者似乎对修复已经存在的问题不感兴趣。V m 0 5 . I

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

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

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

这样的形势已经逼得许多o { 7 ! O e D o优秀的开发人员卷铺盖走人了。现在的情况啊,真是铁打的公司,流水的H $ ( c r C E 3 M开发者。

管理者不是工程师

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

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

因此,如果你想为重构说出理由,就应p 2 m ^ !该学会商业语言。

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

可用于管理层的五个论点

  1. “重构将减少功能边际成本y - q e u h Z u的波动性。”

这句话是出自 JP ] D ? - E. B. Rai: k : gnsberger 的名言:“软件设计经济学”(The Economicsk m % n x p of Soft+ ; - V H g Q y Pware Design)。

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

让我们来分解j j ^一下:

  • 到目前为止,“重构将减少”这说得还不错。
  • “波z v / %动性”就是“不确定性”的另x v b一种说法。
  • “边际成本”是指多生产一个单位的成本。
  • “功能”就是商业价值!是啊,我们都对商业价值感d u 6 % L = S G兴趣。

它的要点就] s { Q是这五个论点s b c G ~的核心。当我们与非技术人员交谈时,我们却忽略了这一点:

用他们的语言来说。T % F

不要用极客们惯用的; C y Z y ^ T h &话语。要谈经济、谈商业。这就是我的秘诀!

与你的管理者联系去吧。

所以,来试试这样跟他们谈论这个论点吧。毕竟,你知道这个论点到底是什么意s + q , ! h U D w思。

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

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

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

你当然可以!

下面是一些例子,你可以参考:

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

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

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

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

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

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

仅凭这一点,TypeScript 就值Y X n i ` ^得投资!

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

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

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

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

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

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

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

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

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

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

如今,企业要想留住开发人员p % J +已经很难了。尤其是优秀的s 0 y开发人员。当员工士气低落时,他们就很容易会跳槽。一些能让& 1 E { ( |他们o 7 C[ # i q脱困境的东西。

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

现在,请提出一个问题A P S

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

要吸引新的人B t W 3 J j $ }才,聘? * M 用他们并让他们入职。而这既要花钱,又要花时间,还会拖累团队的效率。

你的管理者肯定不/ | e A 2 8愿意每年都更换开U { M U D M R n发人员。减少员工离职率是一个令人信服的理由。并且,如果能有个解决技术债务的计划,就已经对团队士气d 4 ) q B起到了提振作用。

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

首次回应时间(FirsM v [ . 8t Response Time,FRT),是客户支持的关键指标。O o k ? F ? ( ) p

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

重点是:

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

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

额外建议

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

对吗?

好了,我刚才给你了五个论点& i V L,这些论点可以帮你向管理者们论证解决技术债务X x U $ n X [ m .的重要性。

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

需要重构时就动手吧。

重构不应该是实现功能之外的独立步骤。事实上,你无法预知下一个功能是什么。因此,你必须对代码@ Y ? y x X进行重构,使其Q v n适应新的现实。

这是你工作的一部分。

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

这是行之有效的做法,即使是在遗留代码库上也0 / M o是如此。但也就这样了,不会再好到哪里去了。而且,你也不可能做到随时进行大规模的重构。但至少,情况不会变K T k k ] j ?得更糟B ? 5 e q糕。

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

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

你知道为什么吗?

因为这些利益复合,降低了功能边际成e 9 h ; H W B m A本的波动性!

【云栖号在线课堂】每天都有产品技术专家分享!
课程地址:https://yqh.aliyun.com/live

立即加入社群,与专家面对面,及时了解课程最新动态!
【云栖号在线课堂 社群】https://c.tb.cn/X j B PF3.Z8gvnK

原文发布时间:2020-05-31
本文作者:Nicolas Carlo
本文来自:“. # D D :infoq”,了解相关信息可以关注“infoq”