代码审查 (Google牛人谈Code Review)

代码审查 (Google牛人谈Code Review)

在上一篇博客里我暗示自己将不在为Google工作。 我还没有决定好去哪儿-有几个非常不错的工作机会让我选择。鉴于这段时间内我不受雇于任何公司，我想我可以写点和专业相关的东西，这些东西很有趣，但是如果我还在职，可能会导致与同事/老板的关系紧张。

Google是一个相当酷的公司。它们完成了一些非常让人吃惊的事情-包括外部用户可以看到的，也包括公司内的。有些关于公司内部的东西是非保密性的，但是在公司外部讨论的并不广泛，这些就是我想说的。

保证Google的代码质量如此之好的最大原因是代码审查。这不是Google专有的-这是被广为接受的好主意，而且很多人都在做。但是我从来没有见过另外一个大公司会应用的这么普遍，在Google,任何产品/项目的代码只有得到正面的审查才可以提交。

每个人都应该这么做，我不是指非正式的:这是一个严格的软件开发过程必备的普遍规则，其范围不只包括产品代码而是所有的代码。这并不需要做很多工作，但是产生的效果非常大。

你可以从代码审查里得到什么呢？

有一点很明显，在代码提交之前如果有很多双眼睛盯着看可以发现Bug.这是代码审查最广为人知的好处，但是以我的经验看这是价值最小的一点。人们的确可以在代码审查中发现Bug,但是这些Bug大部分都是显而易见的小Bug,开发者分分钟就可以发现，而那些真正需要花时间发现的Bug通常不是在代码审查中发现的。

代码审核最大的好处是纯社会性的。如果你编程的时候知道你的同事将要看你的代码，你的编程方式会不一样。你的代码会写的更整洁，注释更清楚，组织的更好-因为你知道其他人会看你的代码，他们的意见是你需要你关注的。如果没有审查，你虽然知道人们最后会去看你的代码，但是那样不会给你一种紧迫感，也不会给你同样的个人评判的感觉。

还有一个更大的好处就是代码审查可以传播知识。在很多的开发小组里，每个人都负责某一块核心组件，专注于自己的这一块，只要其他同事的模块不会破坏自己的代码就不会去关注。这种模式导致一个模块只有一个人熟悉对应的代码。如果一个人请假或离职，其他人对他负责的模块将一无所知。如果采用代码审核，那么至少有两个人熟悉代码-作者和审查者。审查者知道的代码不如作者多，但是他们都熟悉代码的设计和结构，这意义重大。

当然，没有什么事情会这么简单的，以我的经验，你需要花一些时间来做好代码审查。我已经见过一些坑导致的问题-由于他们在经验不足的审查者中出现的很频繁，这使得那些尝试代码审查的人们体验很不好，以至于成为了实践代码审查的障碍。

最重要的一个规则就是代码审查的关键是在代码提交之前发现代码存在的问题-你要找的是正确性。代码审查最常见的错误-每个初次接触代码审查的人都会犯的错误-就是判断代码是否是以审查者期望的方式编写。

给定一个问题会有一打不同的方’案来解决，给定一个方案，会有一百万种方式用代码实现。作为一个审查者，你的工作不是确保代码是以你所想象的那种方式编写-这是不会的。你的工作是确保代码是正确的。如果打破了这个规则，你会觉得代码审查很难，充满挫折感-这不是好事。

事实上，这是一个很自然的会犯的错误。如果你是一个程序员，当你看到一个问题的时候你会想到一个解决方案-而你会想当然的认为你所想到的就是那个解决方案。然而实际上不是-要成为一个好的审查者，你需要理解这点。

代码审查第二个主要的坑就是人们觉得有义务说点什么。你知道作者花了很多时间和精力写代码-你难道不需要说点什么吗？

不，你不需要。

只是说“哇，不错”从来都不是一个错误。如果你总试图费劲心思来找些什么东西批评一下，那么你所作的只会损害你的个人信誉。如果你只为了说点什么而不断的制造点东西来评判，那么找你做代码审查的人会觉得你所说的只是为了打破沉默，你的意见不会被认真考虑。

第三个坑和审查速度有关。你不应该匆忙的完成代码审查，但是你也应该立刻开始。你的同事正在等你的反馈，如果你和你的同事不愿意花时间来完快速成代码审核，人们会变得沮丧，这种方式只会带来挫折感。看起来代码审查会中断一些手头的事情，但是事实上不会如此，如果有人要求你做审查，你不需要马上放下所有事情，但是在接下来几个小时里，你总会稍停你当前的工作-比如喝杯饮料，去洗手间或者散步闲聊。当你回来的时候，你可以开始审查并完成它。如果你这么做，那没有人会因为等你而耽误很长时间。

[英文原文：Things Everyone Should Do: Code Review ]