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

一些敏捷团队在实施敏捷开发中忙于编码、忙于UnitTest、忙于沟通、忙于Build等，虽然也有编码审核阶段，但大都浮于表面，流于形式，效果不佳。本文结合实践，介绍笔者对敏捷开发中CodeReview的理解和相关经验。

文/陈序明黄彦军

敏捷开发中CodeReview的目的及内容

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

设计合理性Review

在笔者的另一篇文章中《敏捷开发中的架构设计》谈到，敏捷开发中崇尚Codeisdesign，对开发人员提出了比以往更高的要求，即需要开发人员不断地重构出合理的设计。所以敏捷开发中的CodeReview也需要承担一部分“结对设计”和“设计把关”的职责。

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

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

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

互为Backup

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

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

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

分享知识、设计、技术

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

笔者参加的项目中就碰到了类似情况，当时我们整个团队分成三个ScrumTeam，其中一个ScrumTeam负责一个Eclipse工具的开发，其中用到的一些功能和知识在其他ScrumTeam上以前都有涉及过。当时负责开发的同事非常优秀而且能力突出，但由于不知道其他ScrumTeam同事有这方面的经验，没有很好地分享以往好的经验和知识，以至于最后导致浪费了一些学习的成本。

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

代码可读性

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

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

Code中的“地雷区”Review

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

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

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

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

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

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

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

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

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

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

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

发现性能问题

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

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

如图1是RADV7.0(IBMRationalApplicationDeveloper)中的SoftwareAnalyzer工具带有的Performance检查：

图1 RAD Software Analyzer中的Performance检查

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

发现开源的授权法律问题

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

其他问题，如国际化，J2EEBestPractice等

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

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

图2 RAD Software Analyzer中检查规则列表

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

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

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

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

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

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

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

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

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

敏捷开发中如何开展CodeReview

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

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

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

CodeReview协作过程：

a）先由代码的开发人员向检查人员进行大体的介绍，包括设计思想、数据结构、程序代码结构介绍等。

b）双方进行讨论、交流。

c）检查人员单独进一步进行CodeReview，并记录Review结果和建议。

d）由检查人员和开发人员一起，检查人员反馈CodeReview结果，并和开发人员一起讨论改进方法，重构。

e）最后把可重用的CodeReview的经验总结编码规范，或者记录到“地雷区”中。便于整个团队复用经验。

图3 Code Review是沟通、协作、互助和学习的过程

开展以上过程可以以开发人员为主，辅助以工具。但无须规定系列的文档、流程、CheckList等，这反而会影响开发人员的积极性。

CodeReview是发现问题的过程，同时也是学习和交流过程。需要是灵活、自由、主动的态度，而不是行政上的控制和规章流程。笔者建议：和敏捷开发的核心思想一致，让团队明确CodeReview的思想、作用和目的内容后，充分发挥个体的积极性和学习分享的动力。随时随地地进行CodeReview，讨论，重构，改进。

增量式Review

大家都知道，软件开发中存在长鞭效应，即一个问题越在后期发现造成的影响会越大，CodeReview也是

如此，如图4所示：

图 4 Code Review中的长鞭效应

软件的开发过程中，应该阶段性地进行CodeReview，而不是等到所有代码都开发完毕后再做一次性的CodeReview。那时如果发现问题，造成的改动成本比增量式的检查来的大得多。

笔者了解的一些开发团队，他们在软件开发完毕，并测试后，才临时确定CodeReview的人员，然后再安排半天左右的时间进行CodeReview。结果尽管发现一些结构或设计方面问题，但由于修改成本大，也无法进行改进。

正确的方式是，在早期就参与设计开发过程，抱着互助、沟通、协作、学习的思想，阶段性的参与讨论、学习并贡献自己的意见。具体Review的频率、次数则可以由开发人员抱着主动、积极的态度，按照敏捷的思想自己去把握决定。

利用工具进行CodeInspection

有很多的工具可以辅助CodeReview：

1．如代码格式检查Checkstyle工具，检查如过大的类、太长的方法和未使用的变量等这样违反编程规范的问题。

2．RAD中的SoftwareAnalyzer工具，可以基于规则进行国际化、J2EE最佳实践、性能、安全等检查。3．CSAR，用于扫描代码检查开源软件等。

4．JDepend，可以检查包依赖关系。

5．CPD工具，Eclipse的PMD插件提供了一项叫做CPD（或复制粘贴探测器）的功能，用于寻找重复的代码。

6．Eclipse的Metrics插件，提供了很多有效地查出代码复杂度的功能。

辅助以工具和自动化流程，能花很少时间轻松完成很多基本的CodeInspection工作。让团队有更多的时间和精力去做更重要的CodeReview。

持续自动化CodeInspection

工具检查可以由开发人员自行检查并修正，但一种更可持续的做法是自动化的集成工具进行CodeInspection，可以通过自动化脚本在每日进行Build前进行扫描，并呈现报告给相应人员。

CodeReview协作工具

为了快速有效地进行人工CodeReview协作，可以使用诸如Jupiter这样的工具辅助进行。可以帮助开发人员有效管理CodeReview任务、问题、建议等。

总结

CodeReview的核心是：互助，沟通，协作，学习的过程，这是一个美妙而享受的过程，是跨越需求分析、架构设计、编码等各阶段的过程。敏捷团队应该统一达成CodeReview对产品、对团队、对个人的巨大好处的共识，发挥出个体的积极性，相信会改变“流于形式”的现状，发挥CodeReview巨大的威力。

总结

以上是生活随笔为你收集整理的敏捷开 发中Code Review的目的及内容的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。