关于代码审查的一点体会

为什么做

当前代码审查应该是所有团队的标配，只是有做的深入与否、效果好坏之分。如果你加入一个研发团队后，发现没有代码审查，那我的建议是：

• 如果可以，那就建立代码审查机制
• 否则就离开这个团队吧

关于代码审查的好处，主要有：

• 保证代码质量
• 团队成员之间相互学习
• 协助新成员融入团队

怎么做

一提到代码审查，可能大家想到的就是一堆人在一起，对着屏幕上的代码指指点点。其实代码审查是一个系统工程，要想做好，必须不断投入，把控好每个环节，并且不断更新

设定规则

说到规则，可能会有人比较反感，认为太多条条框框会限制创造力，我遇到过因为这个而辞职的人。其实好的规则，不仅不会限制创造力，反而是提高创造力的最佳工具。这里面有一个原则是：

规则要切合团队实际，一定是切实可行

建议制定的规则包括：

1. 代码规范。 可能很多人都会阿里的代码风格规范。我建议作为开发人员，需要仔细阅读下这个规范，并且确认规范里的每一条都适合你的团队。如果不合适，那就提取需要的，或者制定一套公司自己的代码规范。当然这个规范也不能太特立独行，否则新人的融入可能是一个大问题。
2. 审查流程。 如果想做好代码审查，就要把它作为开发流程中的一个必要环节，并且是不能跳过的。
3. 审查标准。 没有标准，那么每个审查都会按照自己的理解，给被审查的代码加评语，那么很难提高团队整体水平。

借助工具

工欲善其事，必先利其器。
这里推荐一个“极其不好用”的好工具——Gerrit，这是Google开源的一个代码审查工具，具体使用方法，我就不再介绍了。作为一个代码审查的工具，绝对是好用的。

先说几个优点：

• 支持多人评审
• 评审权限可以精确划分，包括+1、+2、Submit、Verified
• 页面简洁，可以看到Change Size
• 可以针对不同的分支设定权限
• 插件丰富，可以和Jenkins、IDEA、Jira等各种工具集合，贯穿项目始终

至于不好用的地方，可以慢慢体会。

另外，要把工具的能完成的事情，交给工具来做，比如通过Jenkins做代码的静态检查、跑单元测试等，只有通过工具检查的提交，才能进入到人工审查环节。

能工具化的，一定要工具化

单人与团队

这里主要说的日常行为和非日常行为。如果借助Gerrit，我们可以要求每次提交必须经过：Peer +1、Lead/Arch +2、CI验证等多个环节才能合并到主干分支中。也就说Peer Review是日常行为。

因为Peer Review可能会失去一些全局信息，所以建议还要定期做Team Review。在做Team Review时，每次只看一个或者两个人的代码，要有完整的逻辑，从头讲到尾，在这个过程中，参与的人可以提出问题和改进意见，会议结束后作为改进项。

迭代更新

一个团队开始做代码审核后，就一定要防止流于形式，更要防止例外情况。
每个团队成员的水平都不一样，建议考虑以下几个方面：

• 制定一个代码审查的清单，每个成员都可以按照这个清单自查和审查
• 可以考虑一定时期内，制定一个或几个小目标；比如，10月份以缩减每次提交的大小为目标。这样利于执行，也利于团队逐步提高。

写在最后

总之，代码审查不是看看代码那么简单，而是一个系统工程。