我今天参与的大多数项目都有相当严格的代码审查政策。我的工作要求对我们大多数代码进行审查，随着我们为夏季招募了一大批实习生，我负责审查大量代码。此外，大约五个月前，我开发的项目采用了正式的预提交审查政策。我必须坦白：我讨厌强制性的代码审查。
我应该明确，我仍然相信代码审查是开发者在项目中协作的有用工具。审查者会标记出你在自己工作时放过的糟糕风格、不高效或丑陋的东西。审查者在审查代码时没有你对其工作方式的假设，通常能够发现你因为混淆了意图的心理模型与实际编写的代码而犯的错误。
此外，代码审查是确保至少两个人熟悉你基础设施中每个部分的好方法。不同的开发者往往自然倾向于对特定的代码或基础设施部分负责，并且是唯一接触或维护它的人。但当他们度假时，这段代码可能会出现问题，其他人则不得不试图弄清楚这段代码本该如何工作。强制性的代码审查政策通常是缓解这类问题的好方法。
但是，撇开代码审查的理论和观察到的好处，作为开发者和审查者，我发现这确实是一个令人沮丧的过程。
作为作者#
作为开发者，我讨厌代码审查给我的开发工作流程带来不可预测的长延迟。一旦我完成并测试了一个功能，并将其发送进行代码审查，我必须等待很长时间才能真正标记它为完成。这意味着，在决定接下来要做什么时，我基本上有三个选择：
- 忙等。喝咖啡，浏览 reddit，查看我的邮件，直到审查请求回来。
- 在我刚刚发送进行代码审查的代码上继续开发。
- 从事完全不同的工作。
这三种选择都很糟糕。(1) 如果我可以期待审查很快回来，那是方便的，因为做一些闲散的事情，比如阅读 reddit 或查看邮件，可以让我在心中保持对代码的关注，这样当审查回复回来时，我就不必重新回忆起它。但显然，这效率低下，浪费时间，如果我不期待在最多一个小时内收到回复，那就不可接受。
(2) 通常是我想做的事情。我经常在一个项目上工作，该项目有几个逻辑上不同但相关的阶段。通常为每个阶段发送审查请求是有意义的，因为它们可以单独部署和审查。
然而，如果审查者对我发送的代码提出了重大意见，我现在不仅需要更新那段代码，还需要在结果的基础上重新整合我自那时以来所做的工作，如果我正在处理某个密切相关的内容，这可能会非常麻烦（例如，如果我的工作使用了我之前构建的 API，而审查者要求对这些 API 进行某种方式的更改）。
选项 (3) 避免了这两个问题，但意味着我不断在不同项目之间切换。这让我变得缓慢，因为我必须不断重新记住我在每个项目中的位置，我使用了哪些 API，等等。任何开发者都可以告诉你，他们讨厌频繁切换不同的项目。
在大型项目中，选项 (3) 可能更可容忍，因为开发 / 审查周期通常是几周。但这些并不是我正在处理的项目。
作为审查者#
审查代码是我如果有无限时间会享受的事情，但在我没有时间的时候，我觉得这很烦人。我确实喜欢阅读其他人的代码，找出如何改进，并给予反馈以帮助实现这一目标。
但做好这一点需要大量时间，而我现在很少有时间。此外，由于我作为开发者处理代码审查时的上述抱怨，我总是敏锐地意识到，可能有人在等待我的回复以完成工作。因此，我总是感到急于回复代码审查请求。
所以，尽管我总觉得代码审查应该是我享受的事情，但我往往发现这是一种令人沮丧的经历，感觉就像是我必须完成的任务，然后才能回到真正的工作中。
当然，这在某种程度上只是过于忙碌的症状，但代码审查使其成为一项让我比其他时间消耗更烦恼的任务。如果客户报告了一个我必须放下所有去调查的关键错误，我会感到恼火，但我至少觉得我在做一些重要的事情，修复一个真实的问题，并希望最终能让客户满意。如果我花一天时间只是在阅读代码审查，我会感到不满意和无所事事。因为代码审查在根本上感觉是可选的 —— 尽管我相信它是有益的，但这是我们选择做的事情，而不是为了项目或业务继续运作而绝对必须做的事情 —— 因此，我发现自己花大量时间在这上面更令人沮丧。
总结#
我相信代码审查是一种强大的工具。但在实践中，我发现与之合作令人沮丧。我想听听你的想法：代码审查对你有用吗？在某些方面我做错了吗？这只是改变我态度的问题吗？
我知道关于如何有效进行代码审查已经写了很多。我会很感激你能指引我一些你发现特别有说服力的内容。