代码可读性

　　如上所说，敏捷开发中强调高质量的代码胜过冗余的文档，所以Code某种程度上是Document。敏捷开发中，代码的要求不止是能运行功能正确的代码，而是有了更高的要求，即Code for maintenance。

　　可维护的代码，需要清晰，可读性强，这里可读性代码检查不是指代码格式（代码格式可以通过工具检查出），而是指代码语义。在笔者的文章《软件可消费性设计》中有一些这方面的讨论和建议。

　　Code中的“地雷区”Review

　　代码中的逻辑，除了业务逻辑，还应该包括技术逻辑。技术逻辑就是实现逻辑， 比如数据库连接打开是否忘记关闭，是否正确使用线程，Exception 处理，密码是否加密存储等。

　　我把这些最常出现错误的地方，而且是测试不容易发现的地方，称为Code中的“地雷区”。这些“地雷区”在Code Review 中是值得花费一些时间进行维护和检查的。

　　建议，在整个团队中维护并共享“地雷区”注意事项列表，以及统一的处理方式和机制。并在编码和Code Review过程中都按照团队的最佳实践进行。

　　发现代码中的业务逻辑错误

　　业务逻辑指的是代码开发的功能是否符合业务需求，如一个加法函数，检查其是否真的实现了加法的功能。

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

　　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检查：

图1 RAD Software Analyzer中的Performance检查

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