项目管理和质量控制之代码走读与审查

项目管理和质量控制

代码走读与审查

目的

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

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

代码审查的阶段

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

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

代码审查和走读的方式

常用的方式主要有：

1． 召开审查走读会议。

2． 专人书面评审。

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

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

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

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

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

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

代码走读和审查角色分布

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

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

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

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

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

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

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

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

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

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

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

实施过程

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

参考流程如下：

专家评审：







编码规范、代码统计、注释率、类化程度、复用度等一般性审查：





BUG修改代码需要在软件的最终版本提交前得到走读和审查通过。修改人员修改完后需要立即通知审查人员进行审查。

参考流程：