Bug

如果问 100 个软件公司的 CEO,问他们是否愿意发布含有 bug 的软件。他们会说什么?50 个根本不愿意回答,会说一些软件 bug 是这个行业中一个需要解决的大问题等不着边的话;40 个会说“当然不会!”,并立即给他们的投资者打电话说这是诬陷,会追究法律责任。9 位会低着头说“无能为力”。而这最后一位会直盯着你的眼睛说“当然会。”

我不知道这最后一位是如何领导一个软件公司的,因为他明显学过经济学。

软件不可能没有 bug,如果你希望发布一个完美的软件,你必须解决藏在代码里的所有 bug。(想把它们挡在门外?不可能,单元测试,敏捷方法,scrum,以及任何当今你能想到的方法论,都不能防止 bug 进入你的代码库。如果我错了,我相信你会在评论里告诉我。)

正如你期望的,你在修补 bug 中投入越多的时间和资金,你就能解决越多的 bug。但是,不幸的是,我们的来自经济学的死对头,受益递减法则,同样适用于这个过程。专业的讲,这个法则指在投入生产要素后,每单位生产要素所能提供的产量增加发生递减的现象。用通俗的话讲,这就是说,你能从这个过程中得到的并不等同于你所有投入的。相反,你的产出会随着投入到增加形成一条迅速下降的曲线,曲线的末端、投入到轴线上,最终成为一条长尾。

举个例子,假如一个程序有 100 个 bug,我们知道这需要投入 100 分的努力来找到并修复这所有 100 个 bug。受益递减法则告诉我们,头 40 分努力将会找到 70 个 bug,而接下来的 30 分努力能找到 20 个 bug,剩下的 30 分努力能找到最后的 10 个 bug。这就是说,头 70 个 bug (很简单的 bug)很便宜,容易找到,算起来每个 bug 只消耗40 / 70 = 0.571分努力。接下来的 20 个 bug (藏的较深的 bug)要昂贵的多,每个消耗30 / 20 = 1.5分努力,而最后的 10 个 bug (真正难发现的 bug)惊人的昂贵,每个消耗30 / 10 = 3分努力。消灭这最后的 10 个 bug 要比消灭起初的 70 个 bug,每个 bug 需要投入的时间或资金要多出 5 倍。从付出的努力看,消灭大多数 bug (70%-90%)和消灭所有 bug,它们的成本有巨大差别,从数字上看相差两倍之多。

而在现实中,实际情况比这更糟糕。因为你不知道何时能干掉这最后一个 bug——没有一个像上面例子那样的倒计数——你不得不不断的去寻找更多的 bug,即使是它们已经全部被干掉了,你也要去证明它们确是全部被干掉了。如果你想消灭所有的 bug,你还要计算你的成本。

所以,消灭一个程序中所有的 bug 是一件代价很大的事。不妨让我们花一分钟这样思考一下:一个软件公司最终决定要这么做。软件公司并没有设定像“发布没有 bug 的软件”的目标——他们设定的目标是“11 月 19 号发布”——于是,这个目标改变了公司的测试计划和开发计划(不论有没有计划),这必然意味着的预算的增加。现在,你想象一下,谁会为这多出的预算买单?公司?(嗨!)如果你没有在软件公司工作过,让我来给你一点提示:非也。软件公司会把成本转嫁到客户身上。因此可以得出,你喜欢的软件都是你支付的起的软件。我得到的消息是:你喜欢有 bug 的软件。(开源软件也是如此。除非你愿意花更多的钱或等更长的时间。很有可能你会接受去忍受次等的软件事实。)

现在澄清一下,我并不是说软件公司应该发布有大量严重 bug 的软件。我是说他们的软件里可以有少量的小 bug。

如何知道一个 bug 是大还是小?你应该思考谁会遇到它,当遇到时会发生什么样的坏情况。如果一个用户,进入第三层菜单,打开一个高级配置窗口,选中三个复选框,在敲击“A”键时得到了一个奇怪的错误信息,这是小 bug。它埋的很深,当碰到它时人们会说“靠”,然后改为点击按钮,然后就会愉快的做其它事情去了。如果在使用你的程序中一个常用的操作时崩溃,那这就是个大 bug。大部分人遇到这样的 bug 时都会愤怒不已。

所以,我要提出一个判断你的软件何时满足发布条件的黄金法则。这个黄金法则内容是,你应该不断的测试并修复软件中的 bug,直到发现这些 bug 是:

  1. 不会让你的公司蒙羞。
  2. 不会激怒你的客户。

相比起让一些用户遇到这些并不在于的 bug 的代价,你的要找出程序中所有 bug 并确保全部纠正的做法代价实在太高。前提条件是,不要让用户做你的测试员——如果你这样做,必定会跟黄金法则冲突——宁愿相信所有的 bug 并非生来平等,有些能影响一个产品的发布,而另一些则不然。不要害怕发布的产品中有 bug。如果你开发的是人们想要的好软件,一些 bug 的存在并不会打搅他们,尤其是当软件升级操作简便时,比如通过 SaaS 或 Web 应用。

如果你的软件测试符合黄金法则,那么,你的客户最迫切得到的是你的软件,而不是希望你去修改那些小 bug。所以,准备发布吧!

哦,别忘了去问那最后一个 CEO 关于炒股的技巧。经济学家的公文包里总有最好的数据。

英文原文:The Economics of Perfect Software