笔者了解的一些敏捷团队中，把发现代码的业务逻辑错误当做目标和内容，但往往效果都不是很好，基本都是从形式上泛泛检查一番。原因有两个：

　　1．业务逻辑的检查是从需求到代码的全方位检查，需要花费大量时间，投入产出比失衡。

　　2．业务逻辑的检查和业务需求紧密关联，已经超出了检查人员的能力范围（一般Code Review是开发人员，不是业务人员）。

　　笔者认为，发现逻辑错误，不应该是Code Review 的目的和内容。应该是Unit Test，功能测试，集成测试的目的。从投入产出比考虑，不应该花费太多时间在Code Review 阶段去进行逻辑错误检查。

　　敏捷开发中不推荐的Code   Review的目的及内容

　　下面还有一些常见的Code Review目的和内容被很多团队广泛使用，但作者认为这些并不是敏捷开发中的主要目的和内容，团队应该把时间花费在重要的目的和内容上，而不应该投入精力在下面的这些Code Review目的和内容上。

　　发现性能问题

　　有些团队把性能问题，也作为Code   Review的目的和内容之一，然后提出一些如String应该使用StringBuilder，而不能使用+，类似这样的看似有用其实无用建议。

　　笔者认为，性能问题是需要量化的衡量和精确定位， 很难通过Code   Review检查出来。而一些粗浅的性能问题可以通过一些工具方便地扫描出来，而无须花费时间去进行Code Review。

　　如图1是RAD V7.0 (IBM Rati onal   Application Developer) 中的Software   Analyzer工具带有的Performance检查：

　　所以笔者认为，开发人员提交的代码，需要是经过工具检查后的代码。而代码审核人员则无须花费时间在性能相关的Code Review 上。具体的性能问题交给性能测试。

　　发现开源的授权法律问题

　　开源软件也可以借助一些检查工具， 统一通过工具扫描， 无需在Code Review 阶段花费时间。

　　其他问题，如国际化，J2EE Best   Practice等

　　这些问题开发人员可以在提交代码之前通过工具发现和解决， 不是Code Review 阶段的职责和目的，也无须花费时间去处理。

　　像FindBugs 和RAD 这样的工具具备类似的代码检查功能，如RADV7.0 中的Software Analyzer 工具带有如下的检查功能：

　　1．设计原则（5）：用于面向对象编程的设计原则的规则。

　　2．全球化（47）：基于全球化编码佳实践的规则，有助于确保代码在局部环境中正确地运行。

　　3．J2EE 佳实践（32）：基于佳的 Java™ 2 Platform Enterprise   Edition（ J2EE）开发实践的规则，以及支持瞄准 IBM WebSphere服务的Web 项目的规则；

　　4．J2EE 安全性（17）：验证代码符合 J2EE 技术安全性需要的规则；

　　5．J2SE 佳实践（71）：基于佳的 Java™2 Platform Standard Edition   （J2SE）开发实践的规则；

　　6．J2SE 安全性（9）：验证代码符合 J2SE 技术安全性需要的规则；

　　7．命名（2）：关于 Java 代码中命名约定的规则；

　　8．性能（26）：加强在 Java 应用程序中提高性能和减少存储器足迹的建议的规则；

　　9．私有 API （3）：定位那些不属于 Java 代码的 API 的规则。

　　敏捷开发中如何开展Code   Review

　　在清晰明确了敏捷团队进行Code   Review 的目的和内容后，下面介绍如何有效地开展Code Review。

　　沟通、协作、互助、学习的团队氛围

　　Code Review 中，Review 人员和开发人员不是对立的关系，而是互助、沟通、协作和学习的过程。团队形成互助、互学的气氛，既能互相增长团队的知识和经验，还能把产品做得更好。