敏捷开发中的Code Review
转载于 http://blog.csdn.net/programmer_editor/article/details/4957257
?
?
?
一些敏捷团队在实施敏捷开发中忙于编码、忙于Unit?Test、忙于沟通、忙于Build等，虽然也有编码审核阶段，但大都浮于表面，流于形式，效果不佳。本文结合实践，介绍笔者对敏捷开发中CodeReview的理解和相关经验。
?
文/?陈序明
?
敏捷开发中Code?Review的目的及内容
做任何事情，首先要清晰为什么要做，才能有目标和动力把事情做得更好，Code?Review?也是如此。只有清晰明确了敏捷团队进行CodeReview?的动机，才能以此为方向开展后续工作。下面我们推荐的敏捷开发中常见的Code?Review的目的：
?
设计合理性Review
在笔者的另一篇文章中《敏捷开发中的架构设计》谈到，敏捷开发中崇尚Code?is?design，对开发人员提出了比以往更高的要求，即需要开发人员不断地重构出合理的设计。所以敏捷开发中的Code?Review也需要承担一部分“结对设计”和“设计把关”的职责。
这部分的Code?Review?包括：设计的合理性（如实现方法，数据结构，设计模式，扩展性考虑等），是否存在大量重复代码和其他组件是否有重复的代码，包结构设计是否合理等。
笔者了解的一些项目中，?进行敏捷开发后，?提高了开发效率，?但是设计的质量却下降了。如Repeat?Yourself?的现象（特别是跨组件之间的Repeat?Yourself?现象）；更有甚者，在笔者看到一个某银行的应用中（不是国内的），数据库连接和操作是直接在JSP中写SQL语句。
像这些Bad?Design?的例子还是很多的。这些在重构的时候应该由开发人员解决。但考虑到不同开发人员之间技术功底不一，很有必要在Code?Review阶段进行Review和讨论。
?
互为Backup
这是很容易被忽略，但是又很重要的一个Code?Review的目的。
我们知道，敏捷开发中强调高质量的代码胜过详细的文档，所以某种程度上来说Code?is?Document。敏捷开发中的代码承担了一部分Document的职责，即传递技术的作用。
Code?Review?中，Review?的开发人员了解代码的设计和实现，传递了技术，开发人员互为Backup，方便后期的维护，也减少了项目风险。
?
分享知识、设计、技术
这也是很容易被忽略的一个很重要的目的。敏捷开发是一个中央集中控制到个体发挥积极性的过程，中央集中控制的优点就是有统一的视图和控制，经常开大会，开长会，这样知识和经验也较容易集中。敏捷开发中，分散在两个Scrum?Team的开发人员之间，如果没有好的机制，相互沟通也会相对较少，造成知识和好的经验无法在整个团队传播。
笔者参加的项目中就碰到了类似情况，?当时我们整个团队分成三个Scrum?Team，其中一个Scrum?Team负责一个Eclipse?工具的开发，?其中用到的一些功能和知识在其他ScrumTeam上以前都有涉及过。当时负责开发的同事非常优秀而且能力突出，但由于不知道其他Scrum?Team同事有这方面的经验，没有很好地分享以往好的经验和知识，以至于最后导致浪费了一些学习的成本。
Code?Review是一个学习和享受的过程，一个开发人员的能力有限，而Code?Review正是这样的一种机制，让好的知识、设计在团队中分享，实现整体团队的成长和整体的效益最大化。
?
代码可读性
如上所说，敏捷开发中强调高质量的代码胜过冗余的文档，所以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检查：
所以笔者认为，开发人员提交的代码，需要是经过工具检查后的代码。而代码审核人员则无须花费时间在性能相关的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?人员和开发人员不是对立的关系，而是互助、沟通、协作和学习的过程。团队形成互助、互学的气氛，既能互相增长团队的知识和经验，还能把产品做得更好。
Code?Review协作过程：
a）先由代码的开发人员向检查人员进行大体的介绍，包括设计思想、数据结构、程序代码结构介绍等。
b）双方进行讨论、交流。
c）检查人员单独进一步进行Code?Review，并记录Review结果和建议。
d）由检查人员和开发人员一起，检查人员反馈Code?Review结果，并和开发人员一起讨论改进方法，重构。
e）最后把可重用的Code?Review的经验总结编码规范，或者记录到“地雷区”中。便于整个团队复用经验。
开展以上过程可以以开发人员为主，辅助以工具。但无须规定系列的文档、流程、Check?List?等，这反而会影响开发人员的积极性。
Code?Review是发现问题的过程，同时也是学习和交流过程。需要是灵活、自由、主动的态度，而不是行政上的控制和规章流程。笔者建议：和敏捷开发的核心思想一致，让团队明确Code?Review?的思想、作用和目的内容后，充分发挥个体的积极性和学习分享的动力。随时随地地进行Code?Review，讨论，重构，改进。
?
增量式Review
大家都知道，软件开发中存在长鞭效应，即一个问题越在后期发现造成的影响会越大，Code?Review?也是
如此，如图4所示：
软件的开发过程中，?应该阶段性地进行Code?Review，而不是等到所有代码都开发完毕后再做一次性的Code?Review。那时如果发现问题，造成的改动成本比增量式的检查来的大得多。
笔者了解的一些开发团队，他们在软件开发完毕，并测试后，才临时确定Code?Review的人员，然后再安排半天左右的时间进行Code?Review。结果尽管发现一些结构或设计方面问题，但由于修改成本大，也无法进行改进。
正确的方式是，在早期就参与设计开发过程，抱着互助、沟通、协作、学习的思想，阶段性的参与讨论、学习并贡献自己的意见。具体Review的频率、次数则可以由开发人员抱着主动、积极的态度，按照敏捷的思想自己去把握决定。
?
利用工具进行Code?Inspection
有很多的工具可以辅助Code?Review?：
1．如代码格式检查Checkstyle?工具，检查如过大的类、太长的方法和未使用的变量等这样违反编程规范的问题。
2．RAD中的Software?Analyzer工具，可以基于规则进行国际化、J2EE最佳实践、性能、安全等检查。3．CSAR，用于扫描代码检查开源软件等。
4．JDepend，可以检查包依赖关系。
5．CPD工具，Eclipse?的?PMD?插件提供了一项叫做?CPD（或复制粘贴探测器）的功能，用于寻找重复的代码。
6．Eclipse?的Metrics?插件，提供了很多有效地查出代码复杂度的功能。
辅助以工具和自动化流程，能花很少时间轻松完成很多基本的Code?Inspection?工作。让团队有更多的时间和精力去做更重要的Code?Review。
?
持续自动化Code?Inspection
工具检查可以由开发人员自行检查并修正，?但一种更可持续的做法是自动化的集成工具进行Code?Inspection，可以通过自动化脚本在每日进行Build?前进行扫描，并呈现报告给相应人员。
?
Code?Review协作工具
为了快速有效地进行人工Code?Review协作，可以使用诸如Jupiter这样的工具辅助进行。可以帮助开发人员有效管理Code?Review任务、问题、建议等。
?
总结
Code?Review?的核心是：互助，沟通，协作，学习的过程，这是一个美妙而享受的过程，是跨越需求分析、架构设计、编码等各阶段的过程。敏捷团队应该统一达成Code?Review?对产品、对团队、对个人的巨大好处的共识，发挥出个体的积极性，相信会改变“流于形式”的现状，发挥Code?Review巨大的威力。
