软件质量之路

上个月有段时间修正 bug 忙得要死,最后缓口气的时候统计了一下,发现这段时间修正了近 20 个 bug。这个数字大大出乎我的意料。

这些修正 bug 的工作并非是目前我开发的产品,而是一个两年前维护过的现在已经交给其它 team 维护的系统。即便两年前,对此系统的诸多细节也不甚了解。如今已两年没有接触它的 code base,只是对其大体构架还有印象。最近维护该产品的人手紧张,调我临时支援一下,主要处理一些罕见的 random crash。这些 random crash 很难在测试环境下复现。产品发布给数千的 pre-release 用户后才会在不断的日常使用中偶尔产生。遭遇 crash 的用户可以通过自动工具把 crash report 提交给服务器,report 中的信息不是很多,最主要的是所有 thread 在 crash 时刻的 call-stack,后端系统会根据导致 crash 的 thread call-stack 自动进行分类。这就是这些 bug 的背景:一个不熟悉的产品,没有复现 bug 的情景,只有少量线索。因为还要保证目前负责的产品的进度,每天只能花一半工作时间研究这些 crash report,如此历经三周。修正近 20 个 bug 的成绩令人颇感意外。

这件事情给我的启示是多方面的。Eric Steven Raymond 在《The Cathedral and The Bazaar》中针对 open source 模式总结出「Linus Law」,后来又在《The Art of UNIX Programming》中详细阐述:

Given enough eyeballs, all bugs are shallow.

有人质疑「Linus Law」(比如这篇),开放 source code 是否等同于有更多的人发现并修正 bug。因为不管一个 open source 软件多么流行,真正积极参与开发,能深入了解 code 的总是少部分人。这段时间修正 bug 的经历却证明修正软件稳定性方面的 bug 无需深入了解特定产品的 source code,特别需要的是与产品无关的通用软件开发知识,比如 C/C++ 的语言和 runtime,操作系统,二进制接口,静态和动态链接,汇编,多线程多核等等。影响和推动某个 open source 软件产品的通常是小团队,但能够参与提高产品稳定性质量的可以是很大的开发者群体。因为所需技能并非与某个甚至某类产品相关,一个高水平的程序员甚至可以在业余时间帮助提高多个 open source 产品的质量,即使有些产品的类型超出他熟悉的范围。

第二方面的启示是关于在软件中寻找问题。这些 crash 的代码乍看起来是非常「无辜」的。甚至于我每次都会惊呼一定是 C runtime 的 malloc() 有 bug 或者宇宙射线导致的内存错误。而且没有任何动态分析(比如使用 debugger,输出 log)的手段。不过只要定下神,告诉自己确信这个地方一定会导致 crash,经过几个小时的静态分析和冥思苦想之后几乎总是能找出一些问题。根据这些模模糊糊的推测完成的修复没法即时验证,只能先 submit 再说,称为 blind-fix。同样出乎意料同时也颇有成就感的是 crash 统计系统中相当多的 crash 数量在相关的 blind-fix 之后陡然下降为零。

在软件系统日益复杂的时候,程序员却失去了一些 postmotern debugging 的信息(例如,large sparse 进程空间让 full core dump 在用户生产系统上无法接受),但是这些真实的 blind-fix 实例说明:第一,call-stack 是最重要的调试信息;第二,修正问题最重要的一步是能 100% 的确信一定存在问题。这两点的重要程度之高远远超乎我之前的预料。关于第一点,我曾经很多次提到过,对待破坏 call-stack 可见性(比如,由于增加动态语言的虚拟机而导致两层 call-stack)和完整性(比如 message-posting,provider-consumer,Reactor 模式)的技术要非常慎重。

第三方面是关于工具。一个简单的自动提交 crash report 的工具和一个 crash 分类数据库,不算什么高深的技术。但是,如果没有这套系统,发现和研究 random crash 与验证 blind-fix 就是不可能的。在软件工业里,再不起眼的小工具都是加速整个行业进程的一部分。一些老程序员有个共同的经历:开始编程是因为能直接操控一台复杂的机器快感;经过一段时间之后,发现这机器比预想的要难驾驭,产生很强的挫败感;经过一段迷茫之后又发现,自己每一点努力的成果,并不是限于直接操控机器,而是增加整个群体的驾驭系统的能力,同时自己的能力也在这个体系上加速提高;如此重新找到编程的热情。

十几年前,「软件危机 (software crisis) 」还算个值得一提的名词,而且《人月神话》里「no silver bullet」的预言至今也没有被打破。不过,虽然没有数量级的生产力提高,软件开发还是在工具与协作模式上持续地稳步提升生产力,甚至还有些许的加速度。我们已经安然度过了「软件危机」。知乎上有一个问题 —— 是否能用十年前的技术造出今天的软件,我说的是,这十年软件业并没有空过,和十年前相比,我们毕竟拥有了很多无法或缺的东西。

发表评论

Fill in your details below or click an icon to log in:

WordPress.com 徽标

You are commenting using your WordPress.com account. Log Out /  更改 )

Google+ photo

You are commenting using your Google+ account. Log Out /  更改 )

Twitter picture

You are commenting using your Twitter account. Log Out /  更改 )

Facebook photo

You are commenting using your Facebook account. Log Out /  更改 )

Connecting to %s


%d 博主赞过: