代码走读与审查

　　目的

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

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

　　代码审查的阶段

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

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

　　代码审查和走读的方式

　　常用的方式主要有：

　　1、召开审查走读会议。

　　2、专人书面评审。

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

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

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

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

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

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

　　代码走读和审查角色分布

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

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

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

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

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