说起代码走查，相信每个人都不陌生，但为什么要执行代码走查，什么时候来执行代码走查，如何有效执行代码走查，很多人的看法和见解都不一样。

　　一般的看法，认为代码走查是一种非正式的代码评审技术，它通常在编码完成之后由代码的作者向一组同事来讲解他自己编写的代码，由同事来给出意见。

　　这种做法在很多做软件开发组织中经常采用。但从实际执行效果来看，成效并不都那么明显，反而很多组织的这种做法有浪费时间之嫌。主要是因为代码走查活动时间有限，而参加代码走查的人之前没有较多的时间来提前了解被走查的代码，故而在实际执行时能被走查的代码所占的比例并不高，同时也发现不了多少本质问题。

　　随着软件外包业的发展，它有别于软件产品开发，客户对于产品的要求不再局限于系统是否能够正确运行。而是在设计、代码的品质上也有了更多的要求。有的客户甚至会在我们每次交付后先来检查我们的代码品质，只要是代码不符合要求就会被拒绝。

　　但在项目的实际执行中，面对客户的这些要求，我们又常常遇到诸如编写的代码不符合规范；编码效率低；代码的可重用性低；代码错误多等现象，从而影响到项目的时程和交付的品质，影响到客户对我们的满意度和对我们专业程度的质疑。

　　那么在项目的执行过程中，如何来解决面临的这些问题呢？结合在过程改进中的实践和软件外包项目的实际来看，我认为要解决这些问题的一个有效方法还是在于如何有效地执行代码走查活动。

　　首先我们要明确为什么要进行代码走查活动，我以为其目的主要有：

　　1）、通过代码走查活动，及时了解程序员编写的代码是否符合设计要求以及编码规范；

　　2）、通过代码走查活动，及时了解程序员在编码过程中遇到的问题，并给以协助，从而达到有效、透明地掌控项目进度的目的；

　　3）、通过代码走查活动，及时了解代码中可以重用的代码，并将其提取为公共方法或模块，提高代码的可重用性以弥补当前人员设计能力不足的现状。

　　要满足上面的三个目的，显然仅仅依靠工具是不能够满足要求的。那么如何执行代码走查活动才会有效呢？

　　首先，在系统设计阶段，我们需要明确系统架构、编码规范等技术要求，来制定出代码走查活动需要的Checklist（对于编码规范，当可以利用工具来进行检查时，准备的Checklist中就不需要将工具可以检查的要点再逐一列出来。）下图就是一个Checklist的示例。

　　第二步是确定代码走查时发现问题的记录方式。可以使用文档的方式来记录（这在很多项目中使用），也可以使用缺陷跟踪系统来记录。

　　当准备工作完成，且项目进入Coding阶段后，我们就可以正式开始执行代码走查活动了。为了改变以前那种事后检查的弊端，我们将代码走查活动前移到与程序员的Coding同步进行。这样做就是为了及时发现问题及时解决问题。实施的步骤如下：

　　1）、负责代码走查的人员从建构库中获取需要走查的代码；

　　2）、阅读代码，并根据前面准备好的Checklist对代码进行检查，看代码是否符合相关的技术要求，以及是否满足业务需求，发现的问题及时记录下来；

　　TIPS: 通常可以在阅读代码之前或者阅读完代码之后，利用工具来进行必要的Check。可以利用的工具有：Checkstyle, CodePro, FindBugs, Metrics, JDepend等等。