Code Review都有哪些坑

代码审查是许多高效团队的工程实践。即使你的软件已经有很多优点了，但团队在做代码审查时仍然会遇到一些陷阱。

这篇文章我讲向你介绍一些需要特别注意的陷阱，以防代码审查工作拖累你的团队。知道可能遇到的问题或陷阱，将会帮助你进行更加高效、有效的的代码审查工作。这是我们调查了900名微软员工后得到的结论。

一个典型的代码审查过程

一个典型的使用工具进行的代码审查过程大致是这样的：开发者完成一段代码，她提交代码准备开始让别人review。然后她选择需要审查她的代码的人。审查代码的人开始查看代码并给出一些评论。作者按照这些评论完善代码。当所有人都觉得没问题了以后，代码就可以合并进代码库了。

代码审查并不总是一个平稳的过程

这些步骤听起来像是 一个很平稳的过程，其实并不是，像其他所有事情一样，实际过程往往不如预期。在代码审查过程中，经常会遇到一些陷阱，这会降低整个审查代码的积极性。如果不能正确处理，代码审查会对整个团队的工作效率产生影响。所以让我们来看一下代码审查过程中究竟存在哪些坑。

关键问题主要有两种：代码审查花费的时间和代码审查所能提供的价值。

等待回复是一种煎熬

作者需要面对的一个最主要的陷阱就是及时收到回复。等待评论的过程中不能在代码中做其他工作是一个巨大的问题。即使开发者可以完成其他任务，如果代码审查工作耗时过长，也会对开发者对工作效率和满意度造成不好的影响。

开发者必须兼顾多项职责

代码审查并不是代码审查人员唯一的任务。相反，它只是开发者日常工作之一（即使需要每天花费大量时间来做）。所以代码审查人员很可能在做其他工作，并且必须在开始代码审查之前停下或完成这些工作。

如果时间不理想，或者代码审查人员在之前没有预料到这种变化，那么她可能在代码审查之前需要一点时间。远程团队还需要注意时差，这意味着代码审查可能花费更多的时间。

开发者会面对代码审查不被当作实际工作的问题

对于作者和代码审查人员来说，时间都是有限的，如果团队想要开发者做代码审查工作，但又不把它计入工作时间，这是有很大问题的。

大量的代码更改非常难以审核，另外，如果审核人员对这部分代码并不熟悉，那这将是一场噩梦。

理解代码修改需要一些指导

大多数审核人员会面临无法理解代码修改的动机的困境。如果没有任何对修改的描述和解释，代码审查工作将会非常难以进行。研究表明如果审核人员不理解代码修改的目的，或者由于量大而不堪重负，那么她很难给出良好的建议。

It’s just this big incomprehensible mess… then you can’t add any value because they are just going to explain it to you and you’re going to parrot back what they say.

没有得到有价值的反馈会降低开发人员审核代码的动力

毫无疑问，花费时间去等待代码审查，却没有得到有用的反馈是一个常见的问题。虽然团队可能从知识分享中受益，但这样仍会降低开发者的动力和收益。

审核人员不能给出有效建议的原因通常有这样几种

1. 审核人员不具备这方面专业知识

2. 审核人员没有时间去完整的审查代码

3. 审核人员没有理解修改的目的

一旦主要讨论代码格式，你就需要采取行动

另一个在代码审查过程中很重要的问题叫做bikeshedding。它的意思是开发者专注于小问题的讨论（例如代码格式）而忽略了更严重的问题。导致这种行为的原因有很多，通常是由于审核人员并不理解改动的目的或者没有时间做代码审查。有时bikeshedding可能代表团队的动力出了问题。

达成共识可能需要面对面讨论

有时候会发生代码作者和审核人员或者是审核人员之间很难达成共识的情况。由于团队动力和这件事紧密相关，因此必须小心处理这种情况通过工具和书面形式只会加剧这种问题。如果要讨论有争议的问题，那么面对面或者视频也许是更好的方案。

代码审核的好处大于工作量

我希望这些陷阱不会改变你对代码审核的想法，因为如果你了解了这些陷阱并妥善处理它们，代码审核工作对于整个技术团队是非常有好处的，而且会有更有效的方法来做代码审核。