原文以及参考译文
最近有位朋友问我为什么做代码评审很有价值。至少大多数硅谷科技公司都会对每一个变更进行代码评审，以确保至少有两个人看过该变更。在我之前的工作中，我们选择性地（很少地）进行代码评审，后来团队来了一位来自谷歌的新员工，他鼓励我们评审所有代码 - 而我们照做了。事实证明这是个很好的决定。
如果你按正确的方式进行代码评审，它不会让你觉得麻烦。你和审阅你代码的人不是对手关系，你们是一起努力构建最好的软件。（重点是不要把反馈太个人化的看待 - 即使你得改动代码，也不代表你有问题。获得反馈很正常，因为它帮助你成长！）
有些公司严格规定了每一段代码必须有多少人评审，以及每一段代码必须有严格的归属者。我觉得这么做完全没有必要，我更喜欢简单点的系统，唯一的规则是每段代码都至少有一个人评审过。事实上，你仍然得向维护你所改代码的人提交评审意见，但不做硬性要求会更好一些。
以下是我想到的为什么代码评审很有价值的几大原因。这有很多了！
- 代码本身。代码评审最明显的价值是“发现错误”。或者如果你再深入一些，发现了一些作者不知道的最佳实践或潜在规则的情况，你可以反馈给他以改进那些具体的代码。
- 宏观层面的知识分享。当你评审别人的代码时，你其实是在学习对你有益的新技术 - 反之亦然，可能别人在评审你代码时也给你提出了更好的建议。如果你能够学以致用，你必将成长为一个工程师。
- 微观层面的知识分享。通过增加熟悉所有代码的人数，来缓和“公车因子（bus factor）”。（译注：公车因子越大，代表关键人物流失导致项目受到影响的概率越小）
- 趋势分享。相应地，代码评审迫使你与队友交流你们正在做的事情，这也确保了你们方向的正确性，而不至于数天或者数周之后才发现走在错误的方向上。
- 沟通实践。无论是在团队内部还是外部，清晰的沟通都是成功工作的最重要技能！代码评审给了你机会去练习怎么写作更清楚，不论是描述变更目的还是提交反馈的时候。而且幸运的话，下次你要写一些“非常重要”的东西时，你会发现自己已经准备好了。
- 历史记录。根据我的经验，如果人们知道他们写的东西会有人看，他们会写出更好的提交描述消息。这在回顾旧变更时非常有用！
- 可以讨论的东西。有时候你想同意某一变更，你会发现很难口头描述以及表达对比如特定算法细节等的赞同。通过一段代码进行交流会更精确些，因为代码往往比较明确。
- 团队凝聚力。当代码评审变成常规活动时，你会感觉更像是一个团队一起工作，而不是每个人“都在自己的轨道上”。
- 阅读练习。练习阅读别人的代码，有助于你把自己的代码写得更具可读性（因此，更具可维护性）。 这会让你之后写出更好的代码！ 如果非得做个选择，那么原因 2、5、6 对我来说可能是最有价值的。
