项目管理和质量控制
代码走读与审查
目的
主要检查软件代码编写质量，是否与设计相符，与开发目的（需求）是否一致；是否符合编码规范；有没有存在明显的缺陷；
与测试的不同是测试通过一系列的测试活动(运行程序为主)来发现BUG，而代码审查走读则一方面通过浏览代码，检查语法结构，调用关系，以规范度，注释率，类化程度，耦合度，复用度等等指标来衡量代码的质量，达到防范问题发生；另一方面检查代码与设计的偏差，问题是否得到正确解决。
代码审查的阶段
一般的代码审查活动通常发生在软件完成时提交测试前，主要的目的是检查软件代码结构，评估软件质量，防止软件出现重大缺陷，把质量问题解决在测试之前。
近年来随着软件行业的发展，软件开发设计和控制能力不断提高，但软件依然存在BUG，不停地发放补丁，问题依然存在。对软件测试后的修改，也越来越谨慎，考虑得也越来越周全，因此，修改bug的代码改动也越来越重要，软件行业开始对代码修动进行了走读和审查，目的是防止问题的再次发生并且防止修改引发新的问题。
代码审查和走读的方式
常用的方式主要有：
1． 召开审查走读会议。
2． 专人书面评审。
3． 使用统计和分析工具。
不同的场合可以采用不同的方式，以我个人的经验总结以下：
l 进行程序代码结构审查走读，可以采用召开多人会议。
l BUG修改代码的评审可以采用指定专人评审，如果召开多人会议，则需要修改人对修改的代码进行解释。
l 对于注释率，复用度等等可以采用工具软件进行。
多人会议一般是以专家会议的形式召开，没有外部专家的参与，会议往往很难达到预期的效果，这点在一般的软件工程书籍都可以见到，项目组内的成员，容易“只缘身在此山中，不识庐山真面目”，或者因为组内复杂的利益关系不能尽言，有专家提问的情况下效果会好很多，专家必须是内行专家，否则造成反效果。
代码走读和审查角色分布
代码走读和审查需要整个项目组的成员参加，但由于组内角色不同，侧重点也大不相同。或者公司的发展历史影响，部门责任不同，一个项目组可以包含好几个部门，走读和审查各有职责。
评审会议需要所有开发人员加上测试人员参加。
测试人员需要参加所有的评审，除了指定专人评审外。
代码统计、注释率、类化程度、复用度通常情况下可以由测试人员进行评审和跟踪，也可以由项目组开发人员担任。
专家需要参加软件完成时提交测试前的走读和审查会议，不需要参加专人评审和工具评审。
代码走读和审查的结果处理
注释率、类化程度、复用度通常情况下有量化指标，并不是百分百就最好并且与公司的开发历史相关，随着开发水平的提高，量有可能得到提升或下降。
对于bug修改代码通常只有通过或不通过（需要返修）两种状态。
有些问题需要记录在案，在下一次开发再进行提升或纠正。
有些问题修改在软件发布前得到妥善处理。
项目组成员同意表决处理情况，公平妥当。
实施过程
走读审查会议需要提前半天（至少1小时）通知，并把走读和审查的内容以及代码发给会议成员，以方便专家和成员提前做好准备。
参考流程如下：
专家评审：
编码规范、代码统计、注释率、类化程度、复用度等一般性审查：
BUG修改代码需要在软件的最终版本提交前得到走读和审查通过。修改人员修改完后需要立即通知审查人员进行审查。
参考流程：
