昂贵的质量 —— 为什么bug总在发生?

 “To err is human”

在过去相当长一段时间内,我都在一个负责项目维护的团队内工作。团队的特殊之处在于,我们从来不开发新功能,而是负责解决每天上报的线上问题。这些 bug 无奇不有,从无法打开页面到数据奇怪丢失,麻木早已经替代焦虑成为了我们面对 bug 时的主要情绪。 

但我时不时的抱怨依然是:为什么 bug总是在发生。

缺陷早已在丰田生产系统(Toyota Production System)中被标注为浪费之一。没有人希望看到 bug,我们不想,客户更加不想。但我们似乎都不愿承认的一个事实是:

bug是代码的副产品而已。

如果我们选择接受编码不过是人思维活动的一种形式,与思考无异,那我们也就必须接纳,人性的缺陷在代码中自然也不会缺席,恰如硬币的正反两面。

反过来说,如果你对 bug采取的是零容忍的态度,甚至不惜把此写入 KPI 中,它也未必会带来正面效应,因为自此开始,没有人会愿意重构,没有人会愿意引入新的技术方案,道理非常简单:改动越多风险越大——这是某年发生在我所属团队的一次亲身经历。 

所以我们面临的并非 bug 去或者留的选项,而是多与少的问题。

摆正质量

在 MoSCoW 方法论的框架下,我们通常可以将功能的优先级划分为四类: Must Have, Should Have, Could Have 以及 Won’tHave,如果把质量也作为功能的一个维度落入这四个区间之一的话,它一定不会在 Must Have 这个范围内。因为人们既不会因为没有 bug而选择长时间地使用一款应用,也不会因为存在 bug而成为转投它竞争对手的唯一理由。我们必须承认这样一个事实:质量永远也不是商业的核心竞争力,这也暗示着:

  • 有些功能缺陷是可以被容忍的
  • 质量被分配得到的资源永远是有限的。

前者并非我们的一厢情愿,在互联网产品的高性价比和快速迭代的商业逻辑下,用户对产品质量的预期已经被规训到一个非常「理想」的状态。 

而后者更为关键:我们应该如何最大化利用有限的资源去提升质量?如果你所在的部门也有机会组建一支类似于本文开头的团队,那不妨考虑一下这个建议:用资源换取更多的人员加入这支团队怎么样?

原谅我用一个粗俗的比喻来解释为什么这么做行不通:

我们换来的只是打扫的速度,对制造垃圾的人产生不了任何影响,效果甚至会适得其反:考虑到总有人为他们收拾残局,我们的善后工作做得越好,他们越是会肆无忌惮。

但这是当下大部分公司的现状:如果线上问题激增,是不是QA 工作不到位?我们似乎倾向把编码和测试的界限划分得一清二楚,从人员到职责到工序都是如此。而质量问题从编码中来,却想从测试中寻找解决之道,这与刻舟求剑无异。 

铺垫了如此之多,我想表达的观点依然是老生常谈:质量内建,以及最近几年我们常常提倡的测试左移。至于什么是质量内建和测试左移,并不在这篇文章的范围内,你在网上可以找到大量的专业文章来介绍他们。

质量的成本

现在我们必须回答一个核心问题:谁该对质量负责?最官方的答案是每个角色,我们可以列举出产品经理没有全面地对功能做验收,QA没有把控好质量关等等。但假定此刻我们必须指定一人将他五花大绑起来祭天,为的是有人需要为上一个让人焦头烂额的bug 负责,程序员绝对是不二之选。 

但程序员死也不会瞑目的。 

如果你是团队经理,你发现上个月线上问题数量增加了一倍,于是你冲到你的工程师团队工位前,怒不可遏地冲他们吼道:我希望这个月的线上问题不超过个位数!你觉得他们能做到吗?

我想说的是:

质量不是「希望」的结果,它是付出的收获。关键在于你愿意用什么去交换。

提升质量的诀窍一点也不神秘。口口相传的各类业内实践便是最好的灵丹妙药,比如重构、代码评审、结对编程、流水线集成等等。我们不妨就以单元测试为例,看看我们需要付出多大的成本 

首先,时间便是一笔可观的支出。以我所在的项目为例,我们为前端React 组件编写单元测试的时间,几乎与开发功能的时间相同。注意这还是在没有追求覆盖所有的边界用例,以及没有追求 100%的测试覆盖率的情况下。另外,当我们编写的代码导致之前编写的关联测试无法通过流水线时,去查找失败的原因以及修正这些错误也是隐形时间。

其次,在我看来最难以逾越的障碍在于对工程文化的重塑。对下要强调保证程序员去写、关注、修复的纪律;对上要争取理解和空间来辅助这些实践,单拎出来任何一件事推动起来都不简单。工程实践天然具有一种反商业活动的特性,它很难被量化、难以一针见效。没有人敢拍着胸脯说在xx 天之内或者当测试覆盖率至少达到 xx 水平之后, bug 数量会降至 xx。我们都不否认它会变得更好。讽刺的是实践带来的「负面」效应是立竿见影的:工程团队的交付速度变慢了。

测试的部分好处还来自未来,比如它能增强我们重构代码和变更架构时的信心,防止旧功能无意被新功能破坏。但我依然无法保证你的收益会何时何地有几倍于付出的到来。 

于是现状变成了一方面可见的迭代速度变慢,另一方面成本的付出看不到收益,质量就自然值得被牺牲。

在提升质量的过程中,我们解决的不是个体问题而是工业问题。细想这是很难的:一个团队中成员的能力不同背景不同,但我们却要设法让它们的产出质量处于某个水平之上。

还债

听上去我们只能义无反顾去相信(take a leap of faith)某些实践能够帮助我们提升质量,且付出的收益是不确定的。但换一个角度想,我们只是在做一些本该做好的事情而已,用户的宽容让质量变得可有可无。 

我不否认有时候快比好更重要,只不过当有一天质量变成我们无法再忽视的问题时,别不知所措地想不起来质量是在哪里搞丢的。 

  • 5
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

诗者才子酒中仙

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值