声明：该文经我翻译后首次发表在伯乐在线上，不论什么形式的转载都请标明原处。

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

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

只是，我有时候会从我们的团队成员里听到以下这种评论：

• “这个项目的代码评审根本就是浪费时间。”
• “我没有时间做代码评审。

  ”

• “我的项目公布延期了。都是由于我那懦弱的同事还没有做不论什么评审。”
• “你能相信我的同事竟想让我在代码中改点东西吗？请向他们解释：假设我那最初的优雅代码受到不论什么方式修改的话，那就意味着宇宙微妙的平衡将要遭到破坏。”

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

首先，让我们谨记为什么要做代码评审。

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

尤其，它们：

• 给予你第二双眼睛来找到做某些事的瑕疵和更好的方法。

• 确保至少有一个其它人员熟悉你的代码。
• 通过向新员工展示更有经验的开发人员的代码来帮助训练他们。
• 通过让评审者和被评审者互相展示好的想法和做法以促进知识分享。
• 鼓舞开发人员在他们的工作中更加尽心尽力，由于他们知道自己的代码将来要被他们的的某个同事评审。

做彻底深入的评审

只是，假设不在评审工作上倾注一定的时间和精力，这些目标都是无法实现的。

只滚动浏览下patch，确保缩进正确、全部的变量採取小骆驼拼写法并不能构成一次彻底的评审。受到业界的启示也能够考虑结对编程，这是一个相当流行的做法。但也在全部的开发时间上添加了100%的额外开销来作为代码评审工作的基准。

你可能会在代码评审中花费非常多时间，但与结对编程相比。使用的整体project时间仍少得多。

我认为花在代码评审工作上的时间应该是原开发时间的25%左右。

比如，假设一个开发人员花两天时间实现了个小项目。那么评审者应该花大致4个小时的时间来评审它。

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

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

• 包括全部必要的測试。
• 合适的设计文档已经写完。

甚至擅长写測试和文档的开发人员也并不总能记得在代码修改之后及时更新。

在适当的时候来自代码评审人员的细微调整对于确保代码在随着时间的推移不会变质是至关重要的。

防止代码评审工作超负荷

假设你的团队强制要求做代码评审，那这是有风险的，由于你的代码评审工作可能一直积压，终于到无法管理的地步。假设你两周之内不做不论什么评审工作，你能够非常easy的花上几天时间来赶补它。

只是这也意味着当你终于决定去处理它们的时候。你自己的开发工作将遭到一定的意外搁浅。

这也使得做好评审工作更加困难，由于正确的代码评审需要强烈、持续的脑力劳动，非常难这样数日保持下去。

因此，开发人员每天应该竭尽全力的清空他们的评审积压工作。

一个方法是早晨的第一件事情就用来解决评审工作。在開始自己的开发工作之前先做全然部的优秀评审工作，你能够防止以后的评审局面失控情况。有些人更喜欢在午休之前或之后或在一天结束后做审查工作。

不管你什么时候做这些事情，通过将代码审查作为正规的日常工作而不是作为一种分散注意力的工作。你能够避免：

• 没有时间处理你的评审积压工作。

• 由于你的评审工作还没做完而延迟项目的公布。
• 做出一些不再相关的评审，由于在此期间代码已经修改的非常多。
• 由于赶在最后一分钟处理它们而导致评审工作终于完毕的非常差。

写易于评审的代码

无法管理的评审积压工作也不能全怪评审人员。假设我的同事不管三七二十一的花费一周的时间来给一个大project项目加入代码。那么他们公布的patch将真的非常难评审，由于在一个阶段里有太多的工作要处理，代码的目的和底层架构体系也会非常难理解。

这是将你的工作分割为一个个可管理单元之所以非常重要的众多原因之中的一个。我们使用scrum管理方法，所以对我们来说合适的单元是重点。

通过一起努力，用单元来组织我们的工作，并提交仅与我们正在进行的某个单元相关的评审，我们能够写出更加易于审查的代码。你的团队可能使用还有一种管理方法。可是原则都是一样的。

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

在你的设计文档里项目架构应该要具体的描写叙述。这不管怎样都是非常重要的，由于它能让一个新的项目成员非常快的赶上进度并理解现有的代码库。它还能帮助评审者更好的做好自己的工作，这是还有一个优点。单元測试也有助于向评审者说明组件应该怎样使用。

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

写出易于评审的代码的最重要步骤之中的一个是给你的代码评审部分加入凝视。这表示你能够自己浏览评审部分，并在不论什么你认为有助于评审者理解代码意思的地方加入凝视。我发现这种凝视仅花费相对较少的时间（常常仅几分钟的时间）却能产生巨大的作用，能让代码评审工作完毕的更快、更好。当然。代码凝视也有很多同样的优点，应该在合适的地方使用，可是通常来说评审凝视更为明智。最后能够说是一个奖励吧， 研究表明，当开发人员又一次阅读和凝视代码时，居然发现他们自己的代码里有非常多的瑕疵。

庞大的代码重构

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

最好的解决方法是递增式重构代码。

在工作代码库的合理范围内找到能达到你目的的某个修改点。一旦改好了，review通过了。接着进行下一个修改，直到整个重构工作完毕。这种方法可能并非每次都行得通。可是有想法和计划，在重构时要避免巨大的补丁一般是实际可行的。像这样来重构代码可能要花开发人员很多其它的时间，但它同一时候也产生了更好的代码质量和更easy的评审工作。

假设真的实现不了递增式重构代码（这可能要说一些关于怎样写好和组织好源码的事情）。一个可能的解决方式是当进行重构工作时用结对编程来取代代码评审。

解决争议

你的团队无疑是由一群聪明的专业人士组成。

当大家对某个确定的编码问题观点不同一时候。基本上都会产生争议。作为一名开发人员，保持开放的心态。在你的评审者更倾向于一个不同的方法时要随时准备妥协。不要对你的代码持专有的态度，也不要带个人评审意见。

假设只是由于有人认为你应该将一些反复的代码重构为一个可反复利用的函数时，这并不能表明你就不是一个有吸引力的、出色的和有魅力的人。

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

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