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巨大的威力。