代码评审

本文翻译自"Code Reviews"，来自于《97 Things Every Programmer Should Know》一书中的某个章节。

你应该做代码评审。为什么呢？因为代码评审可以提高代码质量并且降低缺陷比例。但进行代码评审未必是因为你想到的那些理由。

由于之前有过一些代码评审的糟糕体验，因此许多程序员不喜欢代码评审。我曾经见过一些组织，它们要求所有代码在部署到生产环境之前必须通过一个正式的评审。多数情况下由架构师或一名主程序员进行这些评审，这种做法被戏称为“架构师评审一切”。这个要求被写在了他们的软件开发过程手册中，因此程序员必须遵守。可能有一些组织的确需要这样一个严格且正式的过程，不过大多数组织并不需要。在大多数组织中，这样做法只会适得其反。被评审者会感到他们就像是在等待一个假释裁决委员会的判决。而评审者既需要时间阅读源码，还需要时间跟上系统的最新进展，了解系统的全部细节。评审者很快就成为了这个过程的瓶颈。而这个过程也会很快地成为众矢之的并变得愈加糟糕。

代码评审的目的应该是共享知识和建立共同的编码指南，而不是简单地纠正代码中的错误。与其它程序员们分享你的代码使集体代码拥有权成为可能。让任意一个项目成员与组内其它人一起浏览代码。评审代码时，你应该尝试学习并理解这些代码，而不是去找错误。

代码评审过程中保持气氛和谐。确保意见是建设性的，而不是刻薄挖苦。为评审会议引入不同的评审角色，避免成员之间的年资影响代码评审。就角色举例来说，可以有一个专门关注文档的评审者，另外一个评审者重点关注异常，第三个人负责关注功能性。这种方法有助于在项目成员间分担评审负担。

每周进行一次例行的代码评审。在评审会议室里花上几个小时进行评审。每次会议按照一个简单循环的方式轮换被评审者。记住项目组组员承担的评审角色在每次会议上也要轮换。代码评审时带上新手。他们也许经验不足，不过他们从大学带来的新鲜知识可以提供一种不同的看法。带上专家，他们有经验和知识。他们可以更快更准确地识别出容易出错的代码。如果项目组拥有代码规范的检查工具的话，代码评审过程将更加容易和顺畅。那样的话，在代码评审会议上大家永远不会讨论代码格式问题。

让代码评审变得有趣也许才是代码评审成功的最为重要的因素。评审是关于人的评审。如果评审会议是痛苦且枯燥无味的，那么它很难激发出大家参与的热情。让它成为一种非正式的、以在项目组成员间共享知识为主要目的的代码评审吧。抛弃那些刻薄挖苦，用蛋糕或黄包餐（译注：全体成员一起参加的午餐）取而代之。