敏捷开发中的代码检视

敏捷开发中的代码检视

整理人：李名俊

创建日期：2011-03-05

iSoftStone IT Co., Ltd.

软通动力信息技术有限公司

All rights reserved

版权所有侵权必究

1 敏捷开发中Code Review的目的及内容

做任何事情，首先要清晰为什么要做，才能有目标和动力把事情做得更好，Code Review 也是如此。只有清晰明确了敏捷团队进行CodeReview 的动机，才能以此为方向开展后续工作。下面我们推荐的敏捷开发中常见的Code Review的目的：

1.1 设计合理性Review

敏捷开发中崇尚Code is design，对开发人员提出了比以往更高的要求，即需要开发人员不断地重构出合理的设计。所以敏捷开发中的Code Review也需要承担一部分“结对设计”和“设计把关”的职责。

这部分的Code Review 包括：设计的合理性（如实现方法，数据结构，设计模式，扩展性考虑等），是否存在大量重复代码和其他组件是否有重复的代码，包结构设计是否合理等。

笔者了解的一些项目中，进行敏捷开发后，提高了开发效率，但是设计的质量却下降了。如Repeat Yourself 的现象（特别是跨组件之间的Repeat Yourself 现象）；更有甚者，在笔者看到一个某银行的应用中（不是国内的），数据库连接和操作是直接在JSP

中写SQL语句。

像这些Bad Design 的例子还是很多的。这些在重构的时候应该由开发人员解决。但考虑到不同开发人员之间技术功底不一，很有必要在Code Review阶段进行Review和讨论。

1.2 互为Backup

这是很容易被忽略，但是又很重要的一个Code Review的目的。

我们知道，敏捷开发中强调高质量的代码胜过详细的文档，所以某种程度上来说Code is Document。敏捷开发中的代码承担了一部分Document的职责，即传递技术的作用。

Code Review 中，Review 的开发人员了解代码的设计和实现，传递了技术，开发人员互为Backup，方便后期的维护，也减少了项目风险。

1.3 分享知识、设计、技术

这也是很容易被忽略的一个很重要的目的。敏捷开发是一个中央集中控制到个体发挥积极性的过程，中央集中控制的优点就是有统一的视图和控制，经常开大会，开长会，这样知识和经验也较容易集中。敏捷开发中，分散在两个Scrum Team的开发人员之间，如果没有好的机制，相互沟通也会相对较少，造成知识和好的经验无法在整个团队传播。

笔者参加的项目中就碰到了类似情况，当时我们整个团队分成三个Scrum Team，其中一个Scrum Team负责一个Eclipse 工具的开发，其中用到的一些功能和知识在其他ScrumTeam上以前都有涉及过。当时负责开发的同事非常优秀而且能力突出，但由于不知道

其他Scrum Team同事有这方面的经验，没有很好地分享以往好的经验和知识，以至于最后导致浪费了一些学习的成本。

Code Review是一个学习和享受的过程，一个开发人员的能力有限，而Code Review正是这样的一种机制，让好的知识、设计在团队中分享，实现整体团队的成长和整体的效益最大化。

1.4 代码可读性

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

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

1.5 Code中的“地雷区”Review

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

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

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

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

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

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

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

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

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

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

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

2.1 发现性能问题

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

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

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

2.2 发现开源的授权法律问题

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

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

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

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

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

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

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