高效代码审查：来自前质疑者的9个建议

理论我知道。代码审查（Code Review）有助于：

• 抓bug
• 保证代码的可读性，可维护性
• 在团队中散播代码的知识
• 让新人适应团队的工作方式
• 让大家接触不同的思路

或者按另一种看法，代码审查就是极大的浪费时间。至少我对代码审查的最初感受就是这样。

当时我是新人，刚毕业，在伦敦一家软件公司开发插件。

随着时间推移，我得提交大量样子都差不多或干脆一样的代码。另一个可怜的家伙（“他是最好的。”我的经理告诉我。好在哪儿啊……）会来Review我的代码。而每次审查之后都会返回不一样的结果。看起来都是全无必要的挑剔又主观的结果。

更糟的是，审查过程的时间，哪怕没有几周，也得有好几天。等代码返回给我的时候，我几乎都记不得那是我写的。这不是那个家伙的错。他肯定也想要个更有经验的开发者，不过他分到了我。他厌倦了处理每个没经验的开发者搞出的那些低级问题，代码审查过程变成了他祛除沮丧情绪的方式。

再加上这些浪费的时间：不同分支的代码同步，上下文切换……我不是代码审查的粉儿，团队其他人也一样。

几年之后，我发现我很同意Jeff Atwood所发表的推特：

“结对代码审查是你能改进代码质量的唯一要事。”

经过这几年的时间我开始赞同代码审查，是因为我发现了代码审查并不是坏事，代码审查执行不好才是坏事。伙计，我们就执行的很不好。

我付出了惨痛代价才意识到这一点。当然不是一夜之间的转变。反思之后，代码审查把我从尴尬的，足以破坏构建的代码修改中拯救出来不少回。而自从我在其他地方工作后，我积累了一些和以前不同的、更好的工作方式的经验。这给了我机会，让我能切身体会到我以前曾错过的代码审查的好处。所以现在我认为自己是一个皈依了的质疑者。

为了你能避免这些痛苦，看看我们的视频，读完这些建议，这样就能带给你更有效的代码审查过程。

一、写给所有人的：

1.只审查正确的东西，让工具干别的

你不需要在代码风格和格式问题上与人争论。有大量的工具可以持续地强调这些内容。确保代码正确、易于理解和可维护性强才是重要的。当然了，编码风格和格式也是这些的一部分，只是你更应该让工具去检查。

2.所有人都该做代码审查

一些人比另一些人更擅长审查。更有经验的人可以发现更多的bug，这很重要。不过更重要的是在总体上维持一个针对代码审查的积极态度，也就是说要避免任何“我们和他们”的对抗态度，或者是让代码审查成为某个人的负担。

3.审查所有的代码

没有代码是因为太短或者太简单而不值得审查。当你审查一切，就没有什么会漏掉。另外这样做会成为流程的一部分，成为一种习惯，而不总是事后诸葛。

4.态度积极

这一点对审查者和提交者都很重要。代码审查不是你要拿全A，发动代码神技的时候，也不是你需要摆出防御姿态的时候。带着对建设性批评的积极态度投入进去，你就可以在此过程中收获信任。

二、写给对审查者的：

5.代码审查应该短期高频

你的审查效率在一个小时后开始下降。所以推迟审查共走，然后在一个极限的周期内赶完对谁也没用。在你的一天中留出时间来定期处理，别打乱自己的工作节奏并养成习惯。你的同事会为此而感谢你。等待会让人沮丧。而且当代码还新鲜的保存在他们脑海里时，他们解决问题也会快一些。

6.It’s OK to say “It’s all good” |“都挺好”挺好

别太挑剔了，你不是一定要每次审查都发现问题。

7.使用一个清单

代码审查清单确保一致性——每个人都了解哪些是重要的，哪些是常见错误。

三、写给代码提交者的

8.保证代码简短

超过200行，审查效率就会显著下降。一旦你超过400行，那基本就没什么意义了。

9.提供上下文

要提供相关的单子，或者规格说明的链接。像Kiln这样的代码审查工具可以提供帮助。应提供简短而有用的提交信息，在代码中留下大量注释。这会帮助审查者，你得到的问题反馈也会少一些。