也许你是一位项目经理，也许你是一位项目骨干成员，或者开发小组长。在我发表“如何提高代码质量”的这一系统文章后，有许多网友都向我抱怨，说他无法把握整个项目组成员的代码质量。我想，这也是所有项目组普遍存在的问题吧，它通常表现为以下几个问题：

　　软件项目普遍存在的问题

　　1）新手。任何项目组成员都不可避免地出现新手，他们往往是刚刚从大学毕业的学生。这些新手由于软件开发时间太短，往往技术不成熟，没有形成良好的开发习惯，所以编写代码质量较差，问题很多。他们常常成为项目组的“鸡肋”，用多了项目质量无法得到保证，不用则又人手不够。

　　2）人员变动。一个维护时间稍长一点儿的软件项目，人员变动是在所难免的。老员工被调动到其它项目去了，由新员工来接替他们的工作。在我的项目组中，人员调动达到了90%，唯一没有调走的就是我自己。新员工在接替老员工进行代码维护，甚至继续进行新的开发的时，由于对原有代码以及设计思路理解的偏差，也会出现大量的低劣代码。

　　3）不规范的代码编写。即使除去以上两个问题的影响，项目组成员编写的代码同样会出现问题。在项目开发之初，我们往往会制定一个代码编写的规范，但在项目开发过程中，许多成员往往会忽视这些代码规范而进行随意的编写。随意地代码编写会降低代码的可读性、可维护性和易变更性。那么，我们应当采用什么样的管理措施，保证代码的规范，提高代码的质量呢？

　　以上问题，也是我在项目开发中不断摸索和思考的问题，而一些有经验的项目经理给出了他们的解决之道，那就是“代码复查”。

　　什么是代码复查

　　代码复查（Code Review），又叫“代码审查”，其基本思想就是，在开发人员编写完自己的代码后，由其他人来复查他写的代码，从而有效地发现代码中存在的缺陷。代码复查的一个基本理论就是，当我们越早发现代码存在的缺陷，我们解决缺陷的代价就越低。代码复查往往分成以下一个方面进行审查：

　　1）代码风格。在项目开发之初，我们往往会制定一个代码编写的规范，实际上，这个代码规范就包含了整个项目组的代码风格。由于软件开发人员的设计习惯不同，如果不统一代码风格，一个项目中的代码将五花八门，如变量和常量的命名、接口与实现类的注释、何时回车、怎样缩进等等。一个五花八门的设计风格，必将为日后的维护与改进带来困难。我们通过代码复查，一方面督促开发人员按照规范编写代码，另一方面也使开发人员自身形成良好的编程习惯。代码风格的审查，由于内容比较单一，我们常常可以通过一些代码复查的工具来自动完成，提高复查的效率。

　　2）重大缺陷。在一些关于代码复查的文章中，列出了一个常常的单子，描述了代码复查应当着重注意的重大缺陷，它们包括：存在SQL注入、易受跨站点脚本攻击、缓存区溢出、托管代码等等。项目组可以不断积累重大缺陷的审查项目，并在每次审查中逐一检查。重大缺陷审查是一个繁琐而细致的工作，如果能编写或使用一些审查软件，可以大大提高我们的审查效率。

　　3）设计逻辑与思路的审查。我认为，这部分的审查是代码复查中最核心、最有价值的部分。代码风格与重大缺陷的审查，虽然重要但简单而机械，可以通过软件自动检查；而设计逻辑与思路的审查，却是复杂而有深度的审查，需要有一定理论深度和编码经验的人才能完成，而且对新手尤其重要。前面提到，新手是任何项目组不可避免的问题。但遗憾的是，许多项目经理的办法是，只将一些简单而少量的工作交给新手完成，而将大量复杂的工作交给人数不多的那些老手来完成。这样的结果是，新手始终是新手，他们没有经过足够的锻炼；老手累死累活，无法指望新手予以分担工作。对于这个问题，我的办法是，通过代码复查，让老手去指导新手，让团队整体素质达到提高。具体办法就是，在新手完成编码以后，让老手去进行代码复查，指出新手的问题，指导新手设计。这样的过程最初可能需要重构，甚至重新编码。但经过这样的过程，新手将逐渐熟练，迅速成为老手，使整体团队素质提高。

　　代码复查的形式及优缺点

　　经过以上的描述，我们可以发现代码复查的优点显而易见。首先，通过对代码风格与规范的审查，可以大大提高代码的可读性与可维护性。现在的软件，往往需要持续的维护与升级，人员变动也在所难免，因此代码的可读性与可维护性尤为重要。代码复查是一种鞭策，因为它的存在，督促着开发人员自觉地规范编码，养成好的编码习惯，提高代码质量。一个值得注意的问题是，如果你不去读别人的代码，永远不能深刻理解什么是可读的代码，而自己的代码不让别人去读并且反馈，也永远不知道自己的代码是否可读，即使你是一个编码多年的老手。代码复查恰恰解决了这个问题，值得你去尝试。