最近很忙，一直在研究开发模式的改善，关注点有3个：Peer Review、代码评审和测试驱动。

关于Peer Review，中文不知道应该怎样翻译才贴切，一些人翻译作“同行评审”，一些翻译作“对等评审”，我现在姑且意译作“成员间相互检查代码”。Peer Review实际上在外国已经流行n久了，外国把它作为过程改进的一个关键步骤。

目的：

相关的文档请参看：

关于代码评审，中国很多公司早就有这个做法了。我今天跟金蝶的温少讨教过这个问题，他提出了不少好建议，先摘录如下：

你可以把项目组中的每个人的代码都抽取部分给其他人审查。最好有办法避免开发者把最好的代码提交评审。

每几个人负责评审一块的代码，最好能够熟悉对方的业务或者程序

最初时，通常只能检查到一些代码中的容易发现的错误，例如编码不规范和一些很显而易见的错误，不过单这一些就很重要了

你最好让大家花时间自己整理一下代码，然后提交评审。评审的时候，最好有投影仪，大家坐在一个电脑前面，轮流讲自己评审别人的代码中发现的问题和优点

当然，发现了问题，如果确定了要修改的，会录入研发管理平台中作为待处理任务的

不单要发现问题去解决，也要发现优点推广之

你先做一次，你就会发现，这个过程会很愉快，因为发现了很多可笑的代码，同时你要注意协调，让这个过程愉快一些

最初只能做编码规范和一些简单错误的检查。你去审查一遍大家的代码，你可能也能总结一些和自己所采用技术相关的规则，你目前的一些评审项目可能还可以细化和补充

建议补充一条，是否检查了在函数入口处检查了参数的合法性，如果检查了，做优点处理。

调用别人的函数，返回值，是否进行了合法性检查或者空值处理。例如if (rtnVal != null) 。通常如果做了，当优点处理

这两条，能够提高代码的质量，因为程序中，通常会很容易产生因为参数或者返回值不恰当导致的错误，这类错误的错误信息通常比较乱，很难查。

这个要求有些高的，所以如果做了，当优点处理。

当然，数据库可以检查命名规范，是否使用不恰当的数据类型

代码评审的目的：

设计和开发评审的目的是由一组有资格的人员对软件设计和开发的输出进行评价，以判断确定设计和开发的输出能否实现软件产品预先定义的规格，同时通过评审标识出与规格和标准的偏差。它向管理部门提供充足的证据以证明
　　1）设计和开发的输出符合了其规格要求；
　　2）设计和开发的输出是否满足相关法律、法规以及企业标准的要求；
　　3）软件产品的更改得到了恰当地实施；
　　4）软件产品的更改只对那些规格发生了更改的系统区域有影响，没有引入新的问题。

相关的文档请参看：http://www.chinauml.net/software_engineering/rjzl/20040429/151346.html

代码评审时应该有一依据，并根据这一依据进行评审，把评审结果详细记录下来，这就是代码评审报告。我在网络上搜索很久都没有这样的文档，于是就自己写了一个，并实际运用起来。

开发评审模版：http://www.cnblogs.com/Files/unruledboy/DevAssessReport.rar