CodeReview实践

       我们组进行CodeReview已经有一年多的时间，在开发阶段，各位同事对CodeReview都比较重视，我们组的CodeReview流程并不是一开始就确定了的，而是在开发的过程中根据同事们的反馈，逐步沉淀，逐步积累得来的。

       最开始，我们进行CodeReview是比较盲目的，时间安排上也不太合理，譬如，测试完成之后，比较闲的时候才去进行CodeReview，而CodeReview的主要时间花在对同事的代码的一句一句的阅读上面，看似每句代码都过了一遍了，但是效果呢？效果呢？……效果却发现并不尽人意，时间花了，但是并没有发现那些隐藏很深的bug，发现的可能都是一些手误，比较明显的bug。后来，我们读了Google的一个哥么写的一篇关于的Google的CodeReview的经验和实践经验，茅塞顿开，因此而制定了下面的几条CodeReview的流程和制度（或者说经验把）。

       Goolge的那个哥么的写一篇关于google的CodeReview的经验的附在了后面（其实这篇文件的翻译版本已经在2011年10月发表在了CSDN上面http://blog.csdn.net/magictong/article/details/6846167）。

 

       下面是我们组积累的一些CodeReview的经验和流程：

       1、在开发阶段即进行CodeReview过程，而不是等到开发测试完成之后，在需求安排阶段就已经安排了相应需求的开发和相应CODEREVIEW的人（注意是需求阶段，类似于结对编程，这次，1和2配对，下次可能就是1和3配对，灵活配置。这可能需要流程管理的同事进行相应的配合，这应该作为一个需求来完成，而不是作为一个可做可不做的事情来完成，凡事都怕认真）。

       2、对于某个模块或者功能的开发者来说，在相关的开发工作基本完成了之后，在代码提交（Check In）之前，需要亲自邀请在需求里面写明的Reviewer对自己代码进行Review工作（这时可以找Reviwer比较闲暇的时间，譬如喝茶时间），而开发者需要提供可乐，茶之类的东东，o(∩_∩)o 。

       3、长期这样进行可以把代码质量提高。但是经过我们的实际实践发现，代码的问题并不是由Reviewer发现的，实际上Reviewer很少发现隐藏的bug。而是由于有了这样一种机制，写代码的人知道自己的代码即将会被某个同事欣赏甚至是围观（因为可能Reviewer和代码编写者的设计理念有较大的不同，因此可能叫上兄弟们一起讨论），因此开发者在设计框架和编写代码的时候不再随性而为，不再为了快速编码而毫不考虑性能和扩展性，在写之前会更多的考虑代码的通用性，扩展性和正确性，在自己确认无误之后，才会邀请别人来Review自己的代码。

       4、对于Reviewer来说，最大的收获并不是找到了多少bug，而是学到了更多其他的程序员的思想，学到了更多的程序设计理念，拓宽了自己的思路（一百个程序员，对同一个问题会有一百种解决方案，就基于此）。

       5、长期进行这项工作之后，你会慢慢发现，团队的气氛更加融洽了，同事之间的感情更加深了，这是之前没有想到的。

 

 

--------------------------------------------------

每个程序员都应该做的事情：代码审查（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）工作并完成它。如果你坚持这样做，那你的同事就不会在这件事情上再花很长一段时间等你了。