1.     WHY

         代码review 是提高开发团队代码质量的一个非常好的技术手段，同时也是了解和培养新手程序员的一个非常好的方法，我个人的建议是所有的开发团队都应该努力推广代码review这一技术实践。

 

2.     WHO

原则上，如果有条件，应该是团队中所有人相互进行代码review，或者说，确保每行代码都被除作者以外的人review过。也就是说，不仅仅团队LEADER要review 新人的代码，LEADER的代码也应该被新人或其他工程师review。

 

3.     WHEN & WHERE

如果按照功能看，建议是每完成一个功能就进行review，从时间的角度看，原则上一到两天review一次，是一个合适的频率。如果未review的代码积累得很多的话，则review起来很花时间和精力，并且如果代码实现有一些瑕疵的话，需要改动的地方也会很多。而程序员的习惯是写代码比较有劲，写完以后再改，并且是因为所谓代码质量去改，则动力相对会不足。

这里有一个要注意的地方，那就是review和代码提交备份的先后顺序。原则上，我们要求所有提交到SVN的代码都是被review过的，也就是说，工程师完成某一功能的开发后，他的主管通过结对编程的方式在他的座位上进行code review，如果review中发现问题，简单易改的问题就当场修改掉，如果改动较大，则由开发工程师在review完成后自己进行修改，待修改完成后，再次review，直到没有问题方可提交代码服务器。

 

4．WHAT

         代码review自然是review代码，不过，说实话，看代码是一件十分辛苦的事情，尤其还是看别人的代码。为了让看代码不至于太耗精力，我建议是看代码之前先想一下如果类似的功能自己来做，会怎么设计和实现，想明白之后，再重点看代码的头文件，是否和自己设计的思路比较一致，这时候如果发现与自己思路不一致的地方，就可以直接问一下代码的作者，了解一下他这样做的目的，总之，代码的头文件是review的重点，抓住这个重点，代码review的工作就可以做得既不过于占用精力，而最终的效果又比较好。

 

5．HOW

         实际在代码review的过程中，建议以一个规范、两个规则作为review的指导思想。所以一个规范，指的就是团队的所谓编程规范，很多TEAM都有自己的编程规范，那么review就是检查是否有不遵守编程规范的地方，一般而言，这一条绝大多数人都可以做到。

         所谓的两个规则，就是命名规则和对称规则，命名规则在我的<关于编程中的命名问题>一文中有比较详细的描述，这里重点说一下对称规则。

 

对称规则规定 1

类的方法除了run等方法外，其余方法都应当是对称出现的，我们把这样的对称出现的方法称为对称方法组，比如open和close、create和 destroy 等。这个规定要求，如果一个类里面有 SAVE方法，则必须要有对应的LOAD方法，也就是说，在review类的头文件时，只看到OPEN方法，而没看到CLOSE 方法，则头文件的设计一定要出问题，也就是说，程序一定存在与此相关的bug。

 

对称规则规定2

         对称方法组中的实现，也应当是对称的。比如在OPEN 方法中，有某些内部数据的内存分配，某些文件的read 等等操作，则CLOSE 方法中，也必须有这些数据相对应的对称方法，即一定要write某些文件，然后再释放某些内部数据的内存。

         一般而言，工程师看到规定1，都觉得不会有太大问题，接受起来也比较顺利，而对规定2，初看觉得也不会有太大问题，但深入的按照这个规定去检查自己的代码，就会产生这样一个问题：真的所有对称方法组都做到完全对称的实现吗？那我这个RELEASE函数怎么做不到和它的INITIALIZE 对称？

 

对称规则推论

         对称方法组中的实现，如果无法做到对称，则程序设计很大可能出了问题，同时程序很可能隐含了重大bug，因此，程序员应该把这种情况视作程序需要重构的信号，认真和仔细的思考类的设计是否合理。

         这个推论是我对规定2中提问的工程师的回答，如果RELEASE函数无法做到与INITIALIZE对称，那么这个类的设计肯定有问题，如果类的设计也没问题，则整个程序一定有某一个地方设计有问题，才导致了我们无法做到完美的对称实现。

         这个推论我觉得是蛮有趣的，我刚开始介绍的时候，很多工程师听到以后都颇不“服气”，这里我举一个我遇到的很典型的例子。

         某个类里面有一段数据需要在程序释放后保存，这个需求要满足，类的OPEN函数是这样做的：先判断是否存在该文件，如果该文件存在，这读取该文件中的数据，如果不存在，则创建该文件。对于这个类的CLOSE，如果要对称实现的话，就十分纠结了，问题的关键在于在CLOSE的时候，要不要删这个文件，如果不删，则程序应该在什么地方删除这个数据文件？如果删除，那么程序重新起来的时候，用户会发现上一次操作时的数据丢失了，要重新设置，这也就失去了保存文件的意义了。当时这个问题折腾了有一个小时，觉得怎么做都无法满足对称规则，最后，在坚信对称规则正确的情况下，找到了最佳解决方案，那就是把这个文件，放到配置类中去，这下对称规则也满足了，代码行数也下降了，而且程序架构更合理了。