同行代码评审过程中的实践经验

标签: 开发 Code Review 代码评审 程序员 | 发表时间:2014-10-22 03:04 | 作者:敏敏
出处:http://blog.jobbole.com

数百万年前,猿从树上下来,进化出了对生拇指,最终,变成了人类。

我们以类似的眼光来看下强制性代码评审(Code Review):好像是一种能在软件开发这块广阔的领域里将人类从兽里分离出来的东西。

不过,我有时候会从我们的团队成员里听到下面这样的评论:

  • “这个项目的代码评审根本就是浪费时间。”
  • “我没有时间做代码评审。”
  • “我的项目发布延期了,都是因为我那懦弱的同事还没有做任何评审。”
  • “你能相信我的同事竟想让我在代码中改点东西吗?请向他们解释:如果我那最初的优雅代码受到任何方式改动的话,那就意味着宇宙微妙的平衡将要遭到破坏。”

为什么我们要做代码评审?

首先,让我们谨记为什么要做代码评审。对于任何专业的软件开发人员来说,最重要的目标之一是能够持续的提高他们的工作质量。 即使你的团队里尽是优秀的程序员,你也不能将你自己与一个有能力的自由从业者区分开来,除非你能够作为一个团队工作。代码评审是达到这个目的的最重要方式之一。尤其,它们:

  • 给予你第二双眼睛来找到做某些事的瑕疵和更好的方法。
  • 确保至少有一个其他人员熟悉你的代码。
  • 通过向新员工展示更有经验的开发者的代码来帮助训练他们。
  • 通过让评审者和被评审者互相展示好的想法和做法以促进知识分享。
  • 鼓励开发者在他们的工作中更加尽心尽力,因为他们知道自己的代码将来要被他们的的某个同事评审。

做彻底深入的评审

不过,如果不在评审工作上倾注一定的时间和精力,这些目标都是无法实现的。仅仅滚动浏览下patch,确保缩进正确、所有的变量采取小骆驼拼写法并不能构成一次彻底的评审。受到业界的启发也可以考虑结对编程,这是一个相当流行的做法,但也在所有的开发时间上增加了100%的额外开销来作为代码评审工作的基准。你可能会在代码评审中花费很多时间,但与结对编程相比,使用的总体工程时间仍少得多。

我认为 花在代码评审工作上的时间应该是原开发时间的25%左右。例如,如果一个开发者花两天时间实现了个小项目,那么评审者应该花大致4个小时的时间来评审它。

当然,花在评审工作上多少时间并不是最重要的,只要评审能够准确无误的完成即可。特别地,你必须要能理解你正在审查的代码。这不仅仅意味着你只要懂该代码所采用语言的语法即可,它还意味着你必须了解该代码如何适应于更大的应用环境、组件或库下。如果你不抓住每一行代码的全部含义,那么你的评审就不是非常有价值的。这也是为什么好的评审都不可能非常快的完成:因为还要花时间去调查触发某个给定函数的不同代码路径,要去确保第三方API能够正确使用(包括任何边缘情况),等等。

除了寻找你所审查的代码中的瑕疵或其它问题之外,你还应该确保:

  • 包含所有必要的测试。
  • 合适的设计文档已经写完。

甚至擅长写测试和文档的开发人员也并不总能记得在代码改动之后及时更新。在适当的时候来自代码评审人员的细微调整对于确保代码在随着时间的推移不会变质是至关重要的。

防止代码评审工作超负荷

如果你的团队强制要求做代码评审,那这是有风险的,因为你的代码评审工作可能一直积压,最终到无法管理的地步。如果你两周之内不做任何评审工作,你可以很容易的花上几天时间来赶补它。不过这也意味着当你最终决定去处理它们的时候,你自己的开发工作将遭到一定的意外搁浅。这也使得做好评审工作更加困难,因为正确的代码评审需要强烈、持续的脑力劳动,很难这样数日保持下去。

因此,开发者每天应该竭尽全力的清空他们的评审积压工作。一个方法是早晨的第一件事情就用来解决评审工作。在开始自己的开发工作之前先做完所有的优秀评审工作,你可以防止以后的评审局面失控情况。有些人更喜欢在午休之前或之后或在一天结束后做审查工作。无论你什么时候做这些事情,通过将代码审查作为正规的日常工作而不是作为一种分散注意力的工作,你可以避免:

  • 没有时间处理你的评审积压工作。
  • 因为你的评审工作还没做完而延迟项目的发布。
  • 做出一些不再相关的评审,因为在此期间代码已经改动的非常多。
  • 因为赶在最后一分钟处理它们而导致评审工作最终完成的很差。

写易于评审的代码

无法管理的评审积压工作也不能全怪评审人员。如果我的同事不管三七二十一的花费一周的时间来给一个大工程项目添加代码,那么他们发布的patch将真的很难评审,因为在一个阶段里有太多的工作要处理,代码的目的和底层架构体系也会很难理解。

这是将你的工作切割为一个个可管理单元之所以非常重要的众多原因之一,我们使用scrum管理方法,所以对我们来说合适的单元是重点。通过一起努力,用单元来组织我们的工作,并提交仅与我们正在进行的某个单元相关的评审,我们可以写出更加易于审查的代码。你的团队可能使用另一种管理方法,但是原则都是一样的。

为了写出易于评审的代码,还有一些其它的必备条件。如果要做出一些很棘手的架构决策, 为满足评审者的要求,事先进行讨论是合理的。这将使得评审者更加容易的理解你的代码,因为他们将知道你在代码中试着达到什么目的以及怎么计划来达到该目的。这也有助于避免这样一种情况:在评审者提出一个不同的更好的方法后,你必须要重写你的大段代码。

在你的设计文档里项目架构应该要详细的描述。这无论如何都是很重要的,因为它能让一个新的项目成员很快的赶上进度并理解现有的代码库。它还能帮助评审者更好的做好自己的工作,这是另一个好处。单元测试也有助于向评审者说明组件应该如何使用。

如果你的patch里包含了第三方代码,请单独提交。例如当jQuery的9000行代码被插入代码中间时,要做好代码评审工作就难上加难了。

写出易于评审的代码的最重要步骤之一是 给你的代码评审部分添加注释。这表示你可以自己浏览评审部分,并在任何你觉得有助于评审者理解代码意思的地方添加注释。我发现这样的注释仅花费相对较少的时间(经常仅几分钟的时间)却能产生巨大的作用,能让代码评审工作完成的更快、更好。当然,代码注释也有许多相同的优点,应该在合适的地方使用,但是通常来说评审注释更为明智。最后可以说是一个奖励吧,  研究表明,当开发者重新阅读和注释代码时,竟然发现他们自己的代码里有很多的瑕疵。

庞大的代码重构

有时有必要重构能影响许多组件的某个代码库。对于一个庞大的应用程序,这个过程可能花费好几天(甚至更久)且导致庞大的补丁。在这些情况下一个标准的代码评审工作可能是不切实际的。

最好的解决方法是递增式重构代码。在工作代码库的合理范围内找到能达到你目的的某个改动点。一旦改好了,review通过了,接着进行下一个改动,直到整个重构工作完成。这个方法可能并不是每次都行得通,但是有想法和计划,在重构时要避免巨大的补丁通常是实际可行的。像这样来重构代码可能要花开发人员更多的时间,但它同时也产生了更好的代码质量和更容易的评审工作。

如果真的实现不了 递增式重构代码(这可能要说一些关于如何写好和组织好源代码的事情),一个可能的解决方案是当进行重构工作时用结对编程来代替代码评审。

解决争议

你的团队无疑是由一群聪明的专业人士组成。当大家对某个确定的编码问题观点不同时,基本上都会产生争议。 作为一名开发人员,保持开放的心态,在你的评审者更倾向于一个不同的方法时要随时准备妥协。不要对你的代码持专有的态度,也不要带个人评审意见。如果仅仅是因为有人觉得你应该将一些重复的代码重构为一个可重复利用的函数时,这并不能表明你就不是一个有吸引力的、出色的和有魅力的人。

作为一个评审者,一定要机智。在改变建议之前,认真考虑下是否你给的提议真的更好或仅仅只是你个人风格问题。如果你选择的战场集中在一些源代码中明显需要改进的区域,你将能获得更多的成功。说一些诸如“考虑下……可能是值得的”或“有人建议……”的话更适合,而不是“连我的宠物仓鼠都能写出一个比这更高效的排序算法”。

如果达不到一个中间立场(即双方都不愿意妥协),那么就邀请一个双方都尊敬的第三方开发人员过来看看,让他们给出一些观点和建议。

同行代码评审过程中的实践经验,首发于 博客 - 伯乐在线

相关 [同行 代码评审 实践] 推荐:

同行代码评审过程中的实践经验

- - 博客 - 伯乐在线
数百万年前,猿从树上下来,进化出了对生拇指,最终,变成了人类. 我们以类似的眼光来看下强制性代码评审(Code Review):好像是一种能在软件开发这块广阔的领域里将人类从兽里分离出来的东西. 不过,我有时候会从我们的团队成员里听到下面这样的评论:. “这个项目的代码评审根本就是浪费时间. “我的项目发布延期了,都是因为我那懦弱的同事还没有做任何评审.

代码评审介绍(3)

- - 研发管理 - ITeye博客
什么是Code Review. Code Review 是一种通过复查代码提高代码质量的过程,在XP方法中占有极为重要的地位,也已经成为软件工程中一个不可缺少的环节. 本文通过对Code Review的一些概念和经验的探讨,就如何进行Code Review和Code Review中应该注意什么提出一些建议.

代码评审介绍(2)

- - 研发管理 - ITeye博客
1.关于Code Review. 1.1 Code Review的目的. Code Review是一种用来确认方案设计和代码实现的质量保证机制,通过这个机制我们可以对代码、测试过程和注释进行检查. Code Review主要用来在软件工程过程中改进代码质量,通过Code Review可以达到如下目的目的:.

代码评审介绍(1)

- - 研发管理 - ITeye博客
代码审核分为自我审核和同行评审. 代码自我审核可以借助工具来进行,工具分为两种,一种是动态审核,一种是静态审核. 静态审核是直接对代码源文件进行审查, 重在在于检查代码编写是否符合规范. 一般来说, 静态审核主要检查如下内容:. 潜在的Bug, 如空的try/catch/finally/switch申明;.

Phabricator —— Facebook 的代码评审工具

- - 开源中国社区最新新闻
在代码审查(Code Review)方面,Facebook做了一个可视化的工具,现已开源,叫Phabricator;工程师可以在页面上非常方便的针对每一段(单行或者多 行)代码进行交互讨论;负责审查的工程师可以接受代码改变,可以提出疑问要求原作者继续修改,可以提出自己不适合以推出该代码审查,等等.

评审的艺术——谈谈现实中的代码评审

- - 博客园_知识库
  曾经写过一点关于代码评审(code review)的文章,比如 这篇和 这篇,现在觉得关于它的认识又有了不少更新. 软件工程的技术和实践分成两部分,一部分是和书本知识一致的,大约占一半,这部分基本上在大学里就可以学,自学只要方法得当、刻苦努力也可是途径;但是第二部分来自于实际团队、经验,内容通常无法从书本当中获得,而且难说对错,不同的人和不同的经历造就了不同的认识.

11 个高效的同行代码审查最佳实践

- - 博客 - 伯乐在线
简介: 这 11 项针对轻量级高效同行代码评审最佳实践被证明是有效的,它们建立在一个通过结合使用 IBM® Rational Team Concert™ 与 SmartBear CodeCollaborator 对 Cisco 系统的开发进行案例研究的基础之上. 它们可以帮助您确保评审既能够改进您的代码,又能利用好开发人员的时间.

OpenStack实践

- - 开放博客
作者:Baihuogou DevOps Team. 我们在公司内部部署OpenStack主要是内部管理虚拟机的需要. 公司内部之前使用virt-manager来管理内部虚拟机,但是缺点有二:. 虽然提供图形界面,但是是桌面软件形式,需要安装软件. 所以现在需要一个新的管理软件来解决这些问题,满足两个特性:.

jQuery最佳实践

- andi - 阮一峰的网络日志
上周,我整理了《jQuery设计思想》. 那篇文章是一篇入门教程,从设计思想的角度,讲解"怎么使用jQuery". 今天的文章则是更进一步,讲解"如何用好jQuery". 我主要参考了Addy Osmani的PPT《提高jQuery性能的诀窍》(jQuery Proven Performance Tips And Tricks).

PHP最佳实践

- xiangqian - 阮一峰的网络日志
虽然名字叫《PHP最佳实践》,但是它主要谈的不是编程规则,而是PHP应用程序的合理架构. 它提供了一种逻辑和数据分离的架构模式,属于MVC模式的一种实践. 我觉得,这是很有参考价值的学习资料,类似的文章网上并不多,所以一边学习,一边就把它翻译了出来. 根据自己的理解,我总结了它的MVC模式的实现方式(详细解释见译文):.