转：敏捷开发中的Code Review
转自程序员杂志
一些敏捷团队在实施敏捷开发中忙于编码、忙于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巨大的威力。
附件Pdf为完整的文章。
一些敏捷团队在实施敏捷开发中忙于编码、忙于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巨大的威力。
附件Pdf为完整的文章。