每个人都要做的事：代码审查

原文： Things Everyone Should Do: Code Review

是什么使得Google的代码质量这么好？其实很简单，就是代码审查。代码审查不是Google特有的，大家都认为这是一个好主意，很多人也都在做。但我还从未见到别的大公司把代码审查做得这么普遍。在Google，无论对于什么产品，什么项目，在通过审查之前，任何代码都不能签入。

每个人都应该这么做。我可不是随便这么一提：这确实是正式的软件开发都应该遵守的规则。不仅仅针对产品代码，无论什么都应该这样。代码审查不需要多大的工作量，但带来的改变是巨大的。

那么，从代码审查中能得到什么呢？

很明显，代码在签入前，用另一双眼睛检查一下，能够发现一些BUG。代码审查带来的这种效益被广为传扬，也被广为接受。但在我的经验中，这是其价值最低的一部分。通过代码审查确实能发现BUG，但坦率地说，代码审查所能发现的BUG，绝大多数都是表面上的，作者化个几分钟就能发现。需要花时间去找的BUG，通过代码审查不会找到。

代码审查的优势纯粹是团队性的。如果编程时，知道你的同事会看你的代码，那你编程的方法就会不一样了。你的代码会更简洁，有更好的说明，代码组织得也会更好。这是因为你在乎其意见的那个人会看你的代码。如果没有代码审查，你知道你的代码最终也会有人看，但不是马上看，就不会有那种紧迫的感觉，也不会有那种受到个人评判的感觉。

还有另一项更大的好处：代码审查能传播知识。在大的开发团体中，每个人都有一个要负责的核心组件，每个人也都专注于他自己的组件。对于同事的组件，只要不会影响他的代码，他看都不会看上一眼。这样的结果就是，对于每一个组件，只有一个人熟悉。如果这个人请假了，或者辞职了，那就没人知道了。通过代码审查，至少有两个人熟悉这段代码：作者和审查者。审查者了解的没有作者那么多，但他们熟悉代码的设计和结构，这有不可估量的价值。

当然，什么事情都不是轻而易举能做好的。就我个人经验来看，要花些时间才能做好代码审查。我见过一些陷阱，它们会带来诸多麻烦。那些缺乏经验的审查者，会非常频繁地掉到这些陷阱中，这给想要做代码审查的人们带来很差的体验，因而极大地影响了代码审查的执行。

首先要牢记，代码审查的目的是在代码提交前发现其中的问题，你所追求的是代码的正确性。代码审查中最常见的错误是，评审者根据个人的编码习惯来判断他人的代码。刚开始做代码审查的每个人都会犯这个错误。

给定一个问题，常常会有十来种解决方案。给定一个解决方案，会有无穷多的代码实现方式。作为一个审查者，你的工作不是要确保代码和你写的一样，因为肯定不会一样。作为一段代码审查者，你的工作是确保作者所写的代码是正确的。如果违背了这条规则，你的感觉会很差，也会有挫折感，这就不是一件好事了。

问题是，这是一个太容易犯的错误。如果你是一个程序员，当你注意到一个问题时，你自然会看到一个解决方案，而且你自认为你看到的就是这个问题的解决方案。但它往往不是。而作为一个好的审查者，你需要得到正确的解决方案。

审查中的第二个主要陷阱是，人们觉得必须得说点什么。你知道作者花了大量的时间和精力才写出了代码，难道不应当说点什么？

不，真的不用。

“呀，看起来不错哦！”只说这个好了，没有一点问题。如果你总是要找点什么来品评一番，那最终只会损害你的信誉。如果你评来评去，目的只是找点话头，被你审查代码的人就会意识到，你是为说而说，目的在于打破沉默而已。这样你的意见就没人被重视了。

第三个陷阱是速度。审查当然不能草草而就，但也应该尽搞定。你的伙伴正在等你哪。如果你和你的伙伴不愿意花时间去做代码审查，而且是很快搞定，那么人们将会感到灰心，代码审查带来的也只有挫折感。做代码审查，看起来得打断手头的事情。其实不然。当有人要你做审查的时候，不必中断手头的事情。但在几个小时的工作期间，你肯定会从手头的事情中抽身去休息一会儿，比如喝一杯，冲个澡，散散步什么的。休息回来之后，你就可以进行审查并将其完成。如果这么做，就不会有人为了等你而停上很长时间了。