每个程序员都应该做的事情：代码审查（code review）

翻译：magictong（童磊）2011年9月

版权：Mack CC

原文地址：

http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/

原文名称：Things Everyone Should Do: Code Review

 

      之前在一些项目中发现，修改代码所带来的bug比新开发功能的bug并不会少，而且还更不可控制，因为测试人员并不完全知道你所修改的部分到底影响到了哪些子功能或者哪些其它的模块，这就造成很多bug在版本在外发之后才在用户那里出现，而测试用例则显然是没有覆盖的。其实有效避免这个问题的一个方法就是code review，这也是我在项目中大力推崇的，通过对每一个小的改动追根究底的询问和跟踪，能够发现测试无法发现的一些隐藏的诡异的问题，而进行code review的人员不能是本人并且最好是对相关功能最熟悉的开发人员。

      这篇文章最开始是同事推荐到我们开发小组的，我看过之后感觉大受启发，决定翻译出来和大家一起学习和思考……

——Magictong 2011-9-25夜

 

      在我的最后一篇帖子中我曾经提到过，我即将离开google了。但是我还没有完全决定下一家去哪里工作，有几个不错的offer可以供我选择。在这段时期，我已经几乎是一个自由人了（译者注：工作交接阶段，没有具体工作了），因此我准备用这些时间写一些有趣的专业性的文章，但是这可能导致我和同事或者上级关系紧张。

      Google是一个相当酷的公司。而且他们已经做了一些非常了不起的事情——无论是公司外面用户可以看到的地方还是公司内部的一些东西，其中公司内建立的一些好的机制并不是秘密，但是却很少被广泛的讨论，我今天正要和大家一起讨论下这些事情。

      使google的代码健壮、高效而又优美的最重要的方法其实很简单：代码审查（code review）。对于google来说，做这件事情并不特殊——而是被广泛认为是一个好的机制（idea），大量的程序员都在严格执行。我还没看到过另一家大公司把代码审查当成日常开发中的一件普通的质量保证机制。在google，任何产品，任何工程的代码，在被进行严格或者明确的审查（code review）之前，是不允许提交的。

      每个程序员都应该这样做，我很认真的这么讲：这应该是严格的软件开发中一个通用的规则。不仅仅是产品代码这样——而应该是一切。它不会占用特别多的工作时间，但是会带来巨大的不同。

      从代码审查（code review）中我们能获得什么好处呢？

      首先最明显的就是：在代码提交之前多了一双眼睛来审查代码，也就更有可能发现代码中的bug了。这也是引用和讨论的最多的代码审查（code review）的好处。不过，以我的经验，这不过是代码审查（code review）最少的价值之一。程序员在代码审查（code review）中发现的bug，大多数都是不重要的，可能就花了审查者几分钟的时间。代码中真正需要花时间去排查的bug在审查阶段是不太可能被检查出来的。

      代码审查（code review）最大的优点是社交性质的。如果你正在写代码，并且你知道你的同事将会要查看你的代码，那么你编写的时候就会更加的慎重和仔细。你的代码会更加的整洁，注释更加完善，并且更有组织性。因为你知道一个人将要查看你的代码，并且你对他给你的代码的评价很关心。如果没有代码审查（code review），也许你知道在最后总是会有人看你的代码的，但是因为即时性不高，因此绝不会产生那种相同的紧迫感，也不会有那种个人评价的感觉。

      代码审查（code review）的一个更大的好处是，它可以传播知识（译者注：就是同事之间可以分享技术和编程方法）。在许许多多的开发小组里面，每个人都是负责自己的一个核心模块，并且每个人基本上都把主要的精力放在关注自己的模块上面。只要同事的模块没有破坏自己的代码，基本上是不会看别人的代码的。带来的一个（不好的）影响就是，对于某个模块可能只有一个人熟悉它的代码。如果这个人休假了或者——天晓得——离开了公司，（在短时间内）就无人知道这个模块的任何内部细节了。有了代码审查（code review）之后，就有两个人熟悉同一块代码了——作者和审查人。审查者可能不像代码作者那样对代码的细节极其熟悉，但是会熟悉模块的设计和结构，这比想象中的有价值很多。

      当然，没有什么事情是完全简单易做的。从我的经验来看，在你擅长进行代码审查之前是需要花一些时间的。一些缺乏经验的代码审查者，经常频繁的造成一些意想不到的麻烦，譬如他们给予一些即将要进行代码审查的人一些不好的经验，这是将代码审查（code review）作为一项常规事务来做的主要阻碍。

      代码审查的主要目的是在代码提交之前发现代码里面的问题。你要寻找的就是代码正确与否。在代码审查中一个常见和常规的错误——也是每个人第一次做代码审查常犯的错误，就是判断代码是否写得跟自己（代码审查者）想象的一样。

      对于同一个问题，通常有几十种不同的方法来解决它。而给定了一种解决方案，通过代码来表达它的方法通常有上百万种。对于一个代码审查者来说，在进行代码审查时，你的工作不是判断这个代码是不是写得跟自己现象的一样——原因显而易见，肯定不像（译者注：俗话说，对于同一个问题，一百个程序员会写下一百种不同的代码）。代码审查者的工作应该是确保作者的代码实现是正确的。如果这个规则被打破的话，你最终会很有挫败感（译者注：因为你会发现这代码怎么写得和自己完全不一样！）——这不是一件好事情。

      事实上这也是一个很彻底很自然犯得错误。如果你是一个程序员，当你发现一个问题的时候，你可能马上就感觉看到了解决问题的方法，并且你觉得你的解决方案是正确的，但是往往它不是。作为一个优秀的代码审查者，你需要知道这点。

      在代码审查中易犯的第二个主要错误是代码审查者感觉有义务和责任必须要说些什么。因为你觉得代码作者在这份代码上话费了大量的时间和精力——难道不应该说点什么吗？

      不！不要这样做。

      如果代码里面没有发现任何的错误，只需要说：“啊，看起来非常好！”如果你像打猎搜寻一样想找到一些地方来批评，那么最终你的所谓的一些批评都是在损害你的信誉。如果你经常这样做，到后面代码的作者会认为您仅仅为了批评而批评，您的意见也将不再被认真的对待了（译者注：有点像狼来了）。

      第三个易犯的错误就是审查代码的速度了。不要急急忙忙的进行代码审查——但是你需要即时的去做这件事情。因为你的同事正在等你进行代码审查。如果你和同事没有即时进行代码审查（code review），并按时完成，那么最后大家都会感到沮丧，并且这次的代码审查（code review）也仅仅是造成了沮丧和挫折而已。看起来丢下其他的事情去做代码审查（code review）是一种不好的打岔行为，其实不是。在有人叫你去做代码审查（code review）时，你不需要中断任何事情。但是在几个小时之后，你将会打断你正在做的事情——去喝杯茶，去下洗手间，或者去散下步。当你回来的时候你可以进行代码审查（code review）工作并完成它。如果你坚持这样做，那你的同事就不会在这件事情上再花很长一段时间等你了。