Code Review(转)

Code Review是一种通过复查代码提高代码质量的过程，在XP方法中占有极为重要的地位，也已经成为软件工程中一个不可缺少的环节。本文通过对Code Review的一些概念和经验的探讨，就如何进行Code Review和Code Review中应该注意什么提出一些建议。 本文中涉及的问题大部分针对JAVA类代码。同时本文不涉及Code Review过程和组织。

关键词： Code Review，JAVA， XP ，代码质量 ，软件工程

一、Code Review简介
1 Code Review的目的
凡事知其然还要知其所以然，我们首先需要知道什么是Code Review和我们使用它的目的是什么。Code Review是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们可以对代码，测试过程和注释进行检查。Code Review主要用来在软件工程过程中改进代码质量，通过Code Review可以达到如下目的：

在项目早期就能够发现代码中的BUG

帮助初级开发人员学习高级开发人员的经验，达到知识共享

避免开发人员犯一些很常见，很普通的错误

保证项目组人员的良好沟通

项目或产品的代码更容易维护

2 Code Review的前提
知道了Code Review的目的，我们就可以看看如何做Code Review了，但在做Code Review前我们还有事要做，所谓预则立，不预则废，就是说如果在进入Code Review之前我们不做些准备工作，Code Review很容易就变得没有意义或是流于形式，这在我们周围是有很多例子的啊。进入Code Review需要检查的条件如下：

a)       Code Review人员是否理解了Code Review的概念和Code Review将做什么

如果做Code Review的人员不能理解Code Review对项目成败和代码质量的重要程度，他们的做法可能就会是应付了事。

b)      代码是否已经正确的build，build的目的使得代码已经不存在基本语法错误

我们总不希望高级开发人员或是主管将时间浪费在检查连编译都通不过的代码上吧。

c)      代码执行时功能是否正确

Code Review人员也不负责检查代码的功能是否正确，也就是说，需要复查的代码必须由开发人员或质量人员负责该代码的功能的正确性。

d)      Review人员是否理解了代码

做复查的人员需要对该代码有一个基本的了解，其功能是什么，是拿一方面的代码，涉及到数据库或是通讯，这样才能采取针对性的检查

e)       开发人员是否对代码做了单元测试

这一点也是为了保证Code Review前一些语法和功能问题已经得到解决，Code Review人员可以将精力集中在代码的质量上。

3 Code Review需要做什么
好了，进入条件准备好了，有人在这些条件中看到Code Review这也不负责，那也不检查，不禁会问，Code Review到底做什么？其实Code Review主要检查代码中是否存在以下方面问题：代码的一致性、编码风格、代码的安全问题、代码冗余、是否正确设计以满足需求（性能、功能等等），下边我们一一道来。以下内容参考了《Software Quality Assurance: Documentation and Reviews》一文中的代码检查部分。

3．1完整性检查（Completeness）
代码是否完全实现了设计文档中提出的功能需求

代码是否已按照设计文档进行了集成和Debug

代码是否已创建了需要的数据库,包括正确的初始化数据

代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型

3．2一致性检查（Consistency）
代码的逻辑是否符合设计文档

代码中使用的格式、符号、结构等风格是否保持一致

3．3正确性检查（Correctness）
       代码是否符合制定的标准

所有的变量都被正确定义和使用

所有的注释都是准确的

所有的程序调用都使用了正确的参数个数

3．4可修改性检查（Modifiability）
       代码涉及到的常量是否易于修改(如使用配置、定义为类常量、使用专门的常量类等)

代码中是否包含了交叉说明或数据字典，以描述程序是如何对变量和常量进行访问的

代码是否只有一个出口和一个入口（严重的异常处理除外）

3．5可预测性检查（Predictability）
       代码所用的开发语言是否具有定义良好的语法和语义

是否代码避免了依赖于开发语言缺省提供的功能

代码是否无意中陷入了死循环

代码是否是否避免了无穷递归

3．6健壮性检查（Robustness）
       代码是否采取措施避免运行时错误（如数组边界溢出、被零除、值越界、堆栈溢出等）

3．7结构性检查（Structuredness）
       程序的每个功能是否都作为一个可辩识的代码块存在

循环是否只有一个入口

3．8可追溯性检查（Traceability）
       代码是否对每个程序进行了唯一标识

是否有一个交叉引用的框架可以用来在代码和开发文档之间相互对应

代码是否包括一个修订历史记录，记录中对代码的修改和原因都有记录

是否所有的安全功能都有标识

3．9可理解性检查（Understandability）
       注释是否足够清晰的描述每个子程序

是否使用到不明确或不必要的复杂代码，它们是否被清楚的注释

使用一些统一的格式化技巧（如缩进、空白等）用来增强代码的清晰度

是否在定义命名规则时采用了便于记忆，反映类型等方法

每个变量都定义了合法的取值范围

代码中的算法是否符合开发文档中描述的数学模型

3．10可验证性检查(Verifiability)
       代码中的实现技术是否便于测试

二、Code Review经验检查项
以下是在实践中建立的检查列表（checklist），通过分类和有针对性的检查项，保证了Code Review可以有的放矢。

1 JAVA编码规范方面检查项
检查项参照JAVA编码规范执行，见《JAVA编码规范(Java Code Conventions)》

2 面向对象设计方面检查项
这几点的范围都很大，不可能在本文展开讨论，有专门的书籍介绍这方面问题，当然在Code Review中主要靠经验来判断。

A)       类设计和抽象是否合适

B)        是否符合面向接口编程的思想

C)       是否采用合适的设计范式

3 性能方面检查项
性能检查在大多数代码中都是需要严重关注的方面，也是最容易出现问题的方面，常常有程序员写出了功能和语法没有丝毫问题的代码后，正式运行时却在性能上表现不佳，从而不得不做大量的返工，甚至是推倒重来。

A)       在海量数据出现时,队列,表,文件,在传输,upload等方面是否会出现问题,有无控制,如分配的内存块大小,队列长度等控制参数

B)       对hashtable,vector等集合类数据结构的选择和设置是否合适，如正确设置capacity,load factor等参数，数据结构的是否是同步的

C)       有无滥用String对象的现象

D)       是否采用通用的线程池、对象池模块等cache技术以提高性能

E)       类的接口是否定义良好，如参数类型等，避免内部转换

F)       是否采用内存或硬盘缓冲机制以提高效率

G)       并发访问时的应对策略

H)       I/O方面是否使用了合适的类或采用良好的方法以提高性能（如减少序列化，使用buffer类封装流等）

I)         同步方法的使用是否得当,是否过度使用

J)         递归方法中的叠代次数是否合适，应该保证在合理的栈空间范围内

K)       如果调用了阻塞方法，是否考虑了保证性能的措施

L)        避免过度优化，对性能要求高的代码是否使用profile工具，如Jprobe等

4 资源泄漏处理方面检查项
  对于JAVA来说由于存在垃圾收集机制，所以内存泄漏不是太明显，但使用不当，仍然存在内存泄漏的问题。而对于其它的语言，如C++等在这方面就要严重关注了。当然数据库连接资源不释放的问题也是广大程序员最常见的，相信有很多的PM被这个问题折磨的死去活来。

A)       分配的内存是否释放，尤其在错误处理路径上（对非JAVA类）

B)        错误发生时是否所有的对象被释放，如数据库连接、Socket、文件等

C)       是否同一个对象被释放多次（对非JAVA类）

D)       代码是否保存准确的对象reference计数（对非JAVA类）

5 线程安全方面检查项
线程安全问题实际涉及两个方面，一个是性能，另一个是资源的一致性，我们需要在这两方面做个权衡，现在就是到了权衡利弊的时候了。

A)       代码中所有的全局变量是否是线程安全的

B)        需要被多个线程访问的对象是否线程安全，检查有无通过同步方法保护

C)       同步对象上的锁是否按相同的顺序获得和释放以避免死锁，注意错误处理代码

D)       是否存在可能的死锁或是竞争，当用到多个锁时，避免出现类似情况：线程A获得锁1，然后锁2，线程B获得锁2，然后锁1

E)        在保证线程安全的同时，要注意避免过度使用同步，导致性能降低

6 程序流程方面检查项
A)       循环结束条件是否准确

B)        是否避免了死循环的产生

C)       对循环的处理是否合适，如循环变量，局部对象，循环次数等能够考虑到性能方面的影响

7 数据库处理方面
很多Code Review人员在面对代码中涉及到的数据库可移植性和提高数据库性能方面的冲突时表现的无所适从，凡事很难两全其美的啊。

A)       数据库设计或SQL语句是否便于移植（注意和性能方面会存在冲突）

B)       数据库资源是否正常关闭和释放

C)       数据库访问模块是否正确封装，便于管理和提高性能

D)       是否采用合适的事务隔离级别

E)       是否采用存储过程以提高性能

F)        是否采用PreparedStatement以提高性能

8 通讯方面检查项
A)       socket通讯是否存在长期阻塞问题

B)       发送接收的数据流是否采用缓冲机制

C)       socket超时处理，异常处理

D)       数据传输的流量控制问题

9 JAVA对象处理方面检查项
这个检查项的基础是对JAVA对象有较深的理解，但现实是很多看过《Thinking in Java》的程序员，仍然在程序中无法区分传值和传引用，以及对象和reference的区别。这或许就是理论和实践难以结合的问题啊。正所谓知而不行，非真知也。

A)       对象生命周期的处理,是否对象的reference已经失效,能够设置为null,并被回收

B)       在对象的传值和传参方面有无问题,对象的clone方法使用是否过度

C)       是否大量经常的创建临时对象

D)       是否尽量使用局部对象(堆栈对象)

E)        在只需要对象reference的地方是否创建了新的对象实例

10 异常处理方面检查项
JAVA中提供了方便的异常处理机制，但普遍存在的是异常被捕获，但并没有得到处理。我们可以打开一段代码，最常见的现象是进入某个方法后，一个大的try/catch将所有代码行括住，然后在catch中将异常打印到控制台，而且该异常是Exception对象。

A)       每次当方法返回时是否正确处理了异常，如最简单的处理，记录日志到日志文件中

B)        是否对数据的值和范围是否合法进行校验，包括采用断言（assertion）

C)       在出错路径上是否所有的资源和内存都已经释放

D)       所有抛出的异常都得到正确的处理，特别是对子方法抛出的异常，在整个调用栈中必须能够被捕捉并处理

E)        当调用导致错误发生时，方法的调用者应该得到一个通知

F)        不要忘了对错误处理部分的代码进行测试，很多代码在正常情况下执行良好，而一旦出错，整个系统就崩溃了

11 方法（函数）方面检查项
A)       方法的参数是否都做了校验

B)        数组类结构是否做了边界校验

C)       变量在使用前是否做了初始化

D)       返回堆对象的reference，不要返回栈对象的reference

E)        方法API是否被良好定义，即是否尽量面向接口编程，便于维护和重构

12 安全方面检查项
A)       对命令行执行的代码，需要详细检查命令行参数

B)        WEB类程序检查是否对访问参数进行合法性验证

C)       重要信息的保存是否选用合适的加密算法

D)       通讯时考虑是否选用安全的通讯方式

13 其他
A)      日志是否正常输出和控制

B)        配置信息如何获得,是否有硬编码

三、总结
通过在项目中实施Code Review将为我们带来多方面的好处，表现在提高代码质量，保证项目或产品的稳定性，开发经验的积累等，具体的实施当然也要看项目的实际情况，因为Code Review也是需要成本的，这方面属于Code Review过程的问题，将在其他文章中进行探讨。

四、参考资料
Java语言编码规范(Java Code Conventions)  SUN

Software Quality Assurance: Documentation and Reviews  Dolores R. Wallace,Wendy W. Peng, Laura M. Ippolito