同事跟我说,在某个类里面,有个 populate 方法可能有 bug。我随机打开那个类文件,查找一个叫 populate 的方法,那个具体步骤是这样(不具体的话看不出来到底会浪费多少时间),IDE 里用 pop 开头来过滤方法列表,但很遗憾,没看到叫 populate 的方法,却有以 populate 为前缀的几个方法。于是向同事确认,他也没看就说,就叫 populate。我还是相信他的,于是猜想可能是代码没更新,接着做更新,还是没有,可能不在 trunk 上而在分支里,几番周转无果,回到最初的类文件,绝望之中,竟然在方法列表里发现了一个叫 pupulate 的方法。

一股冏上心头泪千行的感觉。作为一个相对底层的类,使用率还不低的情况下,居然有个方法名字错了整整一年甚至更长。

同样是错误,那个 github 史上评论最多的一次 commit(原地址已经 404,可以看其它人的文字记录 或者 google “github giant bug”来重温)。那个要命的空格,让我笑到肚子疼。

rm -rf /usr /lib/nvidia-current/xorg/xorg

好歹人家也可怜地表示 sorry 了。

是不是一个错误只要不影响软件的正常使用,就无须为一些错误感到内疚,甚至会继续延续下去?

在日常开发当中,错误被忽略被延续的情况时有发生。程序员的基本技能技能 ctrl+c, ctrl+v ( or ⌘C, ⌘V ) 以及 IDE 的自动补全就是延续错误的帮凶(当然 IDE 是无罪的,如果没有第一次错误,IDE 是不会乱搞恶作剧的)。延续错误似乎是零成本的,但是修正却是有成本的,会带来不稳定的感觉。

只是延续错误是不是真的是零成本,怎么看待就取决于你的想象力有多丰富了,或者说经验有多丰富了。我们知道 墨菲法则 那句著名的,“凡是可能会出错的事必定出错”,而且我们还知道屋漏偏逢连夜雨,那种疼不是蛋都碎了可以形容的。我就不再举个实例证明了,相信那种疼还是很容易理解的。对错误及其影响的低估,会使人产生侥幸的心理。


(苏州国际科技园一期就在雨期来临的时候,天花板缺了那么一大块,天天滴水,一个月过去了,不知道会不会跟臭氧层空洞一样慢慢变大。)

即使延续错误是零成本的,但是每一次错误的延续都会增加问题修复的成本。出来混代码,迟早是要还的。我想的是公平一点的情况,自己还自己的,应该是比较容易理解和接受的。比如项目只有你一个人的情况(虽然也有点特殊)。难以接受的是人家把错误复制 N 遍了,却轮到你了!你或者会想,后面还会有人。嗯,的确,很有可能,而那个人精通问候的技能甚至会点咒语什么的也是很有可能的。能够制止别人作恶的人正是你了。“Save the Cheerleader, Save the World”

突然又想起 去年 10 月轰动一时的 小悦悦事件。那场悲剧,她的生命,并不仅仅是因为遇上了车祸,碾了两回,还遇上了十八个“冷漠”的“不作为”的路人。不知道是讽刺还是欣慰,这件事情的广泛传播,让人们再次思考生命的意义,社区生活的责任和道德。

估计是不会有人希望生活在没有安全感的社区里的。类似地,是没有人希望在一个糟糕的团队里工作的。正因为错误是必定会出现的,但是它能不能在代码里持久化则完全是人的质量问题了。如果你拿到一份比较严谨的代码(注意这和 bug 少,质量高不是一个概念),除了意味着开发者和你所认为的理所当然是一致的,还意味着开发者会注意约束自己,并为此付出了许多,是专业的,是值得鼓励和赞许的。

最后补充说明一下,通常“错误”是会包含但不限于 bug 的会产生非预期影响效果的情况,这里的错误是特指并不是 bug 的那部分。因为 bug 许多时候有任务指派,是必须消除的,但哪些错误则很少有相应的配套设施。