该帖子同步发自：(飞眉的博客  访问该博客)

　　代码走读与审查

　　目的

　　主要检查软件代码编写质量，是否与设计相符，与开发目的(需求)是否一致;是否符合编码规范;有没有存在明显的缺陷;

　　与测试的不同是测试通过一系列的测试活动(运行程序为主)来发现BUG，而代码审查走读则一方面通过浏览代码，检查语法结构，调用关系，以规范度，注释率，类化程度，耦合度，复用度等等指标来衡量代码的质量，达到防范问题发生;另一方面检查代码与设计的偏差，问题是否得到正确解决。

　　代码审查的阶段

　　一般的代码审查活动通常发生在软件完成时提交测试前，主要的目的是检查软件代码结构，评估软件质量，防止软件出现重大缺陷，把质量问题解决在测试之前。

　　近年来随着软件行业的发展，软件开发设计和控制能力不断提高，但软件依然存在BUG，不停地发放补丁，问题依然存在。对软件测试后的修改，也越来越谨慎，考虑得也越来越周全，因此，修改bug的代码改动也越来越重要，软件行业开始对代码修动进行了走读和审查，目的是防止问题的再次发生并且防止修改引发新的问题。

　　代码审查和走读的方式

　　常用的方式主要有：

　　1、召开审查走读会议。

　　2、专人书面评审。

　　3、使用统计和分析工具。

　　不同的场合可以采用不同的方式，以我个人的经验总结以下：

　　● 进行程序代码结构审查走读，可以采用召开多人会议。

　　● BUG修改代码的评审可以采用指定专人评审，如果召开多人会议，则需要修改人对修改的代码进行解释。

　　● 对于注释率，复用度等等可以采用工具软件进行。

　　多人会议一般是以专家会议的形式召开，没有外部专家的参与，会议往往很难达到预期的效果，这点在一般的软件工程书籍都可以见到，项目组内的成员，容易“只缘身在此山中，不识庐山真面目”，或者因为组内复杂的利益关系不能尽言，有专家提问的情况下效果会好很多，专家必须是内行专家，否则造成反效果。

　　代码走读和审查角色分布

　　代码走读和审查需要整个项目组的成员参加，但由于组内角色不同，侧重点也大不相同。或者公司的发展历史影响，部门责任不同，一个项目组可以包含好几个部门，走读和审查各有职责。

　　评审会议需要所有开发人员加上测试人员参加。

　　测试人员需要参加所有的评审，除了指定专人评审外。

　　代码统计、注释率、类化程度、复用度通常情况下可以由测试人员进行评审和跟踪，也可以由项目组开发人员担任。

　　专家需要参加软件完成时提交测试前的走读和审查会议，不需要参加专人评审和工具评审。

　　代码走读和审查的结果处理

　　注释率、类化程度、复用度通常情况下有量化指标，并不是百分百就最好并且与公司的开发历史相关，随着开发水平的提高，量有可能得到提升或下降。

　　对于bug修改代码通常只有通过或不通过(需要返修)两种状态。

　　有些问题需要记录在案，在下一次开发再进行提升或纠正。

　　有些问题修改在软件发布前得到妥善处理。

　　项目组成员同意表决处理情况，公平妥当。

　　实施过程

　　走读审查会议需要提前半天(至少1小时)通知，并把走读和审查的内容以及代码发给会议成员，以方便专家和成员提前做好准备。

　　参考流程如下：

　　专家评审：