敏捷开发中的Code Review

《敏捷开发中的Code Review》由会员分享，可在线阅读，更多相关《敏捷开发中的Code Review（7页珍藏版）》请在装配图网上搜索。

1、一些敏捷团队在实施敏捷开发中忙于编码、忙于Unit Test、忙于沟通、忙于Build等，虽然 也有编码审核阶段，但大都浮于表面，流于形式，效果不佳。本文结合实践，介绍笔者对敏 捷开发中 CodeReview 的理解和相关经验。文/ 陈序明敏捷开发中 Code Review 的目的及内容做任何事情，首先要清晰为什么要做，才能有目标和动力把事情做得更好， Code Review 也 是如此。只有清晰明确了敏捷团队进行 CodeReview 的动机，才能以此为方向开展后续工作 下面我们推荐的敏捷开发中常见的Code Review的目的：设计合理性 Review在笔者的另一篇文章中敏捷开发中的架构设

2、计谈到，敏捷开发中崇尚Code is design， 对开发人员提出了比以往更高的要求，即需要开发人员不断地重构出合理的设计。所以敏捷 开发中的Code Review也需要承担一部分“结对设计”和“设计把关”的职责。这部分的 Code Review 包括：设计的合理性（如实现方法，数据结构，设计模式，扩展性 考虑等），是否存在大量重复代码和其他组件是否有重复的代码，包结构设计是否合理等。笔者了解的一些项目中， 进行敏捷开发后， 提高了开发效率， 但是设计的质量却下降了。 如 Repeat Yourself 的现象（特别是跨组件之间的 Repeat Yourself 现象）；更有甚者，在 笔者看

3、到一个某银行的应用中（不是国内的），数据库连接和操作是直接在JSP中写SQL语 句。像这些 Bad Design 的例子还是很多的。这些在重构的时候应该由开发人员解决。但考虑到 不同开发人员之间技术功底不一，很有必要在 Code Review 阶段进行 Review 和讨论。互为 Backup这是很容易被忽略，但是又很重要的一个Code Review的目的。我们知道，敏捷开发中强调高质量的代码胜过详细的文档，所以某种程度上来说 Code isDocument。敏捷开发中的代码承担了一部分Document的职责，即传递技术的作用。Code Review中，Review的开发人员了解代码的设计和实

4、现，传递了技术，开发人员互为 Backup，方便后期的维护，也减少了项目风险。分享知识、设计、技术这也是很容易被忽略的一个很重要的目的。敏捷开发是一个中央集中控制到个体发挥积极性 的过程，中央集中控制的优点就是有统一的视图和控制，经常开大会，开长会，这样知识和 经验也较容易集中。敏捷开发中，分散在两个Scrum Team的开发人员之间，如果没有好的 机制，相互沟通也会相对较少，造成知识和好的经验无法在整个团队传播。笔者参加的项目中就碰到了类似情况，当时我们整个团队分成三个Scrum Team,其中一个 Scrum Team负责一个Eclipse工具的开发，其中用到的一些功能和知识在其他Scru

5、mTeam 上以前都有涉及过。当时负责开发的同事非常优秀而且能力突出，但由于不知道其他Scrum Team同事有这方面的经验，没有很好地分享以往好的经验和知识，以至于最后导致浪费了 一些学习的成本。Code Review是一个学习和享受的过程，一个开发人员的能力有限，而Code Review正是这 样的一种机制，让好的知识、设计在团队中分享，实现整体团队的成长和整体的效益最大化。代码可读性如上所说，敏捷开发中强调高质量的代码胜过冗余的文档，所以 Code 某种程度上是 Document。敏捷开发中，代码的要求不止是能运行功能正确的代码，而是有了更高的要求, 即 Code for mainten

6、ance。可维护的代码，需要清晰，可读性强，这里可读性代码检查不是指代码格式（代码格式可以 通过工具检查出），而是指代码语义。在笔者的文章软件可消费性设计中有一些这方面 的讨论和建议。Code中的“地雷区” Review代码中的逻辑，除了业务逻辑，还应该包括技术逻辑。技术逻辑就是实现逻辑， 比如数据 库连接打开是否忘记关闭，是否正确使用线程， Exception 处理，密码是否加密存储等。我把这些最常出现错误的地方，而且是测试不容易发现的地方，称为Code中的“地雷区”。 这些“地雷区”在Code Review中是值得花费一些时间进行维护和检查的。建议，在整个团队中维护并共享“地雷区”注意事项

7、列表，以及统一的处理方式和机制。并 在编码和 Code Review 过程中都按照团队的最佳实践进行。发现代码中的业务逻辑错误业务逻辑指的是代码开发的功能是否符合业务需求，如一个加法函数，检查其是否真的实现 了加法的功能。笔者了解的一些敏捷团队中，把发现代码的业务逻辑错误当做目标和内容，但往往效果都不 是很好，基本都是从形式上泛泛检查一番。原因有两个：1业务逻辑的检查是从需求到代码的全方位检查，需要花费大量时间，投入产出比失衡。2业务逻辑的检查和业务需求紧密关联，已经超出了检查人员的能力范围(一般 Code Review 是开发人员，不是业务人员)。笔者认为，发现逻辑错误，不应该是Code R

8、eview的目的和内容。应该是Unit Test,功能 测试，集成测试的目的。从投入产出比考虑，不应该花费太多时间在 Code Review 阶段去 进行逻辑错误检查。敏捷开发中不推荐的Code Review的目的及内容下面还有一些常见的 Code Review 目的和内容被很多团队广泛使用，但作者认为这些并不是 敏捷开发中的主要目的和内容，团队应该把时间花费在重要的目的和内容上，而不应该投入 精力在下面的这些 Code Review 目的和内容上。发现性能问题有些团队把性能问题，也作为 Code Review 的目的和内容之一，然后提出一些如 String 应该使用StringBuilder

9、，而不能使用+，类似这样的看似有用其实无用建议。笔者认为，性能问题是需要量化的衡量和精确定位，很难通过Code Review检查出来。 而一些粗浅的性能问题可以通过一些工具方便地扫描出来，而无须花费时间去进行 Code Review。如图 1 是 RAD V7.0 (IBM Rati onal Application Developer)中的 Software Analyzer 工具 带有的 Performance 检查：所以笔者认为，开发人员提交的代码，需要是经过工具检查后的代码。而代码审核人员则无须花费时间在性能相关的Code Review上。具体的性能问题交给性能测试。发现开源的授权法律

10、问题开源软件也可以借助一些检查工具， 统一通过工具扫描， 无需在 Code Review 阶段花费 时间。其他问题，如国际化，J2EE Best Practice等这些问题开发人员可以在提交代码之前通过工具发现和解决，不是Code Review阶段的职 责和目的，也无须花费时间去处理。像 FindBugs 和 RAD 这样的工具就具备类似的代码检查功能，如 RADV7.0 中的 Software Analyzer 工具带有如下的检查功能：1设计原则(5)：用于面向对象编程的设计原则的规则。2全球化(47)：基于全球化编码最佳实践的规则，有助于确保代码在局部环境中正确地运 行。3. J2EE 最

11、佳实践(32)：基于最佳的 Java 2 Platform Enterprise Edition ( J2EE)开发 实践的规则，以及支持瞄准IBM WebSphere服务的Web项目的规则；4. J2EE 安全性(17)：验证代码符合 J2EE 技术安全性需要的规则；5. J2SE 最佳实践(71)：基于最佳的 Java2 Platform Standard Edition(J2SE)开发实 践的规则；6. J2SE 安全性(9)：验证代码符合 J2SE 技术安全性需要的规则；7. 命名(2)：关于 Java 代码中命名约定的规则；8. 性能(26)：加强在 Java 应用程序中提高性能和减

12、少存储器足迹的建议的规则；9私有 API （3）：定位那些不属于 Java 代码的 API 的规则。敏捷开发中如何开展 Code Review在清晰明确了敏捷团队进行 Code Review 的目的和内容后，下面介绍如何有效地开展 Code Review。沟通、协作、互助、学习的团队氛围Code Review中，Review人员和开发人员不是对立的关系，而是互助、沟通、协作和学习 的过程。团队形成互助、互学的气氛，既能互相增长团队的知识和经验，还能把产品做得更 好。Code Review 协作过程：a）先由代码的开发人员向检查人员进行大体的介绍，包括设计思想、数据结构、程序代码 结构介绍等。b

13、）双方进行讨论、交流。c） 检查人员单独进一步进行CodeReview，并记录Review结果和建议。d）由检查人员和开发人员一起，检查人员反馈Code Review结果，并和开发人员一起讨论 改进方法，重构。e）最后把可重用的Code Review的经验总结编码规范，或者记录到“地雷区”中。便于整 个团队复用经验。开展以上过程可以以开发人员为主，辅助以工具。但无须规定系列的文档、流程、 Check List 等，这反而会影响开发人员的积极性。Code Review是发现问题的过程，同时也是学习和交流过程。需要是灵活、自由、主动的态 度，而不是行政上的控制和规章流程。笔者建议：和敏捷开发的核心

14、思想一致，让团队明确 Code Review 的思想、作用和目的内容后，充分发挥个体的积极性和学习分享的动力。随时 随地地进行Code Review，讨论，重构，改进。增量式 Review大家都知道，软件开发中存在长鞭效应，即一个问题越在后期发现造成的影响会越大，CodeReview 也是如此，如图 4 所示：软件的开发过程中，应该阶段性地进行Code Review，而不是等到所有代码都开发完毕 后再做一次性的Code Review。那时如果发现问题，造成的改动成本比增量式的检查来的大 得多。笔者了解的一些开发团队，他们在软件开发完毕，并测试后，才临时确定Code Review的人 员，然后再

15、安排半天左右的时间进行Code Reviewo结果尽管发现一些结构或设计方面问题， 但由于修改成本大，也无法进行改进。正确的方式是，在早期就参与设计开发过程，抱着互助、沟通、协作、学习的思想，阶段性 的参与讨论、学习并贡献自己的意见。具体Review的频率、次数则可以由开发人员抱着主 动、积极的态度，按照敏捷的思想自己去把握决定。利用工具进行 Code Inspection有很多的工具可以辅助Code Review :1 如代码格式检查Checkstyle工具，检查如过大的类、太长的方法和未使用的变量等这样 违反编程规范的问题。2. RAD中的Software Analyzer工具，可以基于规

16、则进行国际化、J2EE最佳实践、性能、 安全等检查。3. CSAR，用于扫描代码检查开源软件等。4. JDepend，可以检查包依赖关系。5. CPD工具，Eclipse的PMD插件提供了一项叫做CPD （或复制粘贴探测器）的功能， 用于寻找重复的代码。6. Eclipse 的 Metrics 插件，提供了很多有效地查出代码复杂度的功能。辅助以工具和自动化流程，能花很少时间轻松完成很多基本的CodeInspection工作。让团队有更多的时间和精力去做更重要的Code Review o持续自动化 Code Inspection工具检查可以由开发人员自行检查并修正， 但一种更可持续的做法是自动化

17、的集成工具进 行CodeInspection,可以通过自动化脚本在每日进行Build前进行扫描，并呈现报告给相应人员。Code Review 协作工具为了快速有效地进行人工CodeReview协作，可以使用诸如Jupiter这样的工具辅助进行。可以帮助开发人员有效管理Code Review任务、问题、建议等。总结Code Review 的核心是：互助，沟通，协作，学习的过程，这是一个美妙而享受的过程，是 跨越需求分析、架构设计、编码等各阶段的过程。敏捷团队应该统一达成 Code Review 对 产品、对团队、对个人的巨大好处的共识，发挥出个体的积极性，相信会改变“流于形式” 的现状，发挥Code Review巨大的威力。作者简介：陈序明，IBM公司顾问软件工程师。他目前在IBM中国北京研发中心工作，从事银行多渠 道整合（网上银行、手机银行、柜面等）方面的开发和研究，对软件架构、敏捷开发、产品 管理和银行业务很感兴趣。黄彦军，IBM中国软件研发中心软件工程师，2008年在西安电子科技大学获得计算机系统 结构硕士学位。目前主要从事中间件、Eclipse插件开发，深入理解C、C+、Java。感兴趣 的技术领域包括：分布式计算，网络应用等。本文来自程序员杂志0912期杂志）程序员杂志官方网站：出处：本 文 来 自 CSDN 博 客 ， 转 载 请 标 明