我所经历的review
从n年前大学的毕业设计开始到现在,大大小小的软件项目做了很多。切身体会是如果一个项目不想最后演变成垃圾,最重要的就是交流。
我的大学毕业设计是给一个国外大公司的做的,当时自觉已是C语言高手,2周做个dos下的editor都是小case,何况有一个学期的时间去"发明"(笑)一个排序程序呢。除了验收前一天,硬盘损坏,通宵重写了部分代码以外,程序做的还算顺利。考验来自后来的code review,先是部长写了review计划书,指定参加review的人员,review的方式和目标。参加人员是同一个部门的先辈和我的同级生,5个人左右。review方式采用面对面方式(另外一种方式是回览,既将代码打印交给review人员,不讲解,由他们在自己方便的时间进行检查)。review的目标指出1000行代码应该发现的bug数目,当时的计划好像是每千行发现25个bug。
首先由我介绍这个程序用途,我的实现方案,然后一个函数一行一行的进行了讲解。其他人可以随时打断我。
"这个变量有什么用途?怎么会叫这个名字?"
"这段代码是不是应该这么写......."
"这里应该有一些注释"
"哦,我发现了一个bug!"
我们随时对出现的问题做讨论,有一个人负责记录我们讨论的结果,将不妥当程序的行号,原因,处理办法都记录在review报告书上。
经过两个小时的review,头冒汗声发抖,实实在在地发现很多以前想都没有想到的问题。
改正这些bug以后,感觉心里塌实了很多,对自己的程序质量有了很大的信心。

后来我也参加了其他人的document review, code review,一直到我带领项目,组织review。切实感觉review是非常好的质量保证手段同时它促进了集体技术水平的提高。
我带过一些刚毕业半年的newbie做过两个项目,没有review的话那结果将无法想像。
其中一个项目工期极其紧张,在设计好框架以后的两周里,5个pair居然没有一个能拿出可以运转的模块,计划可是2个人一组1周做出两个模块啊,当时真是急得火上房。主要是大家的思想还没有统一,对如何写出程序来还不清楚。关键时刻review发挥了重要作用。我参加了一组的coding工作,实际指导和暗示了程序的写法,随后立即进行review。通过作者们的讲解,以及大家的提问和讨论,大家清楚了程序越来是怎么编出来。以后的开发效率明显提高,10个人两个月50个模块(ASP+COM+Oracle StoreProcedure)艰苦地完成了,要知道10个人里面大部分是刚毕业半年的新手。

review不是万能的,也会导致一些问题
1,得罪人。在我指出一个同级生的bug时,他恨得要命,后来同我说,当时差点就想跑过来掐死我了(:>)
2,惨不人睹。有的code实在太难看,作者有时自己都看不懂了,review根本就无法进行,代码必须重写。
3,导致时间紧张。有时工期非常紧张,如果每个人的代码全都进行面对面review的话,会延误工期,这时候就需要manager做出判断,进行回览形式的review。
4,bug还是有的。不能完全依赖review来找出所有的bug,review以后的测试才是主要的除错手段。

重粒子@到了写回忆录的年纪了