如果真的想要做好Code Review，必须要让参与的所有工程师们充分认识到Code Review的好处和给他们所带来的成长，才能带动大伙积极参与Code Review当中。就像我们团队，现在已经是大伙每周都很期待那一个小时的Code Review了！（我们团队Code Review是每周五，下午下班前半个小时来做）

无论是高手云集的架构师团队，还是以CURD为主的业务开发团队，大家的技术能力、经验都是有差异的。

通过Code Review，对于同样的功能实现，有经验的工程师可以给经验尚浅的工程师提供合理的优化建议。经验尚浅的工程师可以通过阅读优质代码，快速学习相关技术运用的最佳实践。如果大家技术实力相当，可能就是互相刷新思想了。

你有一个苹果，我有一个苹果，彼此交换一下，我们仍然是各有一个苹果；但你有一种思想，我有一种思想，彼此交换，我们就都有了两种思想，甚至更多。

在大部分团队，尤其是采用服务化架构以及微服务架构的团队，通常都是1个开发人员负责多个服务/项目（Project），如果没有Code Review，那么项目中所涉及的架构知识，或者业务知识，就只存在于项目执行过程中产出的架构文档，以及核心流程、功能的说明文档了。

文档可以帮助其他工程师了解服务/项目的情况，但通常其他工程师不会主动去阅读这些文档，等到真的要维护别的工程师写的代码，文档的完整性往往没有最初的效果好了，文档跟代码实现的匹配度也会下降。

Code Review的过程，就是根据提交者的描述阅读代码的逻辑，看代码实现是否跟描述一致。在这个时候，Reviewer就必须阅读文档，知识的传播性就更好，也基本上不会出现只有1个人了解某个项目的情况了。

如果要给代码质量分一下等级的话，那应该是：
可以编译通过->可以正常运行->可以测试通过->容易阅读->容易维护。那么，通过Code Review的代码最起码可以达到易阅读这个级别。

要做到易阅读，可不是说只要有Code Review这个环节就可以了，还要有相关的规范，让大家按照同样的工程风格、编码风格去构建项目和编写代码。统一风格一方面是让大家无论是维护项目还是阅读代码，不用互相适应各自的编码习惯，另外也是给Reviewer一个Code Review的基本依据。

发现Bug不是Code Review的必需品，而是附属品。至于那些低级的问题/bug交给代码扫描工具就可以了，这不是Code Review的职责。

可以用来做Code Review的工具很多，这里主要介绍相对主流的Gerrit、GitLab

• Gerrit

Gerrit是Google开源的代码审查工具，Gerrit也是一个基于Git构建的版本管理工具，Gerrit支持将其他Git仓库的代码跟Gerrit自己的仓库做同步。所有的代码审查的操作以及权限控制都是在Gerrit自己的仓库上进行的。

Gerrit是面向代码审查来构建的，所以在代码审查的权限控制，以及功能上都是非常完善的。
Gerrit是可以强制CodeReview的，支持Develop、Reviewer、Approver三种角色支持对每个Project配置不同的CodeReview的人员以及权限。

如果要根据Gerrit的数据做一些统计报表，就直接访问Gerrit的数据库，如果功能上不满足要求，反正是开源的，有Java研发团队就可以自己定制

总之，Gerrit的Code Review功能是非常完善的，缺点可能就是UI、交互太老了以及平台的管理功能较弱。

• GitLab家族

GitLab是基于Git构建的源代码管理系统，基于GitLab构建的 GitLab.com 是仅次于 GitHub.com 的在线源代码管理平台。

GitLab分GitLab CE（社区版）和 GitLab EE（企业版）两个版本，开源的社区版功能相对会弱一点，但是免费使用，可以自由部署、定制、维护。企业版功能强大，但是需要收费的。

GitLab可以通过MergeRequest来Review代码，也可以做到强制CodeReview，社区版支持Develop、Reviewer两种角色，企业版支持Develop、Reviewer、Approver三种角色，可以给给项目/组分配不同的角色(Master、Developer)来控制Merge代码的权限。

如果需要根据GitLab的数据做一些统计报表，GitLab提供了非常友好的restful API，如果要定制化，建议是通过API来做定制化的工具，不受编程语言限制。

GitLab的Code Review的功能没有Gerrit功能完善，但是GitLab附带的文档功能、以及GitLab完善的管理后台都要比Gerrit更好，如果要做CI/CD，GitLab的社区版几乎是最佳选择

• Gerrit VS GitLab 综合对比

Gerrit强项只有Code Review的控制，GitLab的功能更全面，但GitLab的企业版是收费的。所以，综合来说，我更推荐GitLab社区版

其他一些Code Review的工相关工具

Crucible：Atlassian 内部代码审查工具；

GitHub：程序员应该很熟悉了，上面的 "Pull Request" 在代码审查这里很好用；

LGTM：可用于 GitHub 和 Bitbucket 的 PR 代码安全漏洞和代码质量审查辅助工具；

Phabricator：Facebook 开源的 git/mercurial/svn 代码审查工具；

PullRequest：GitHub pull requests 代码审查辅助工具；

Pull Reminders：GitHub 上有 PR 需要你审核，该插件自动通过 Slack 提醒你；

Reviewable：基于 GitHub pull requests 的代码审查辅助工具；

Sider：GitHub 自动代码审查辅助工具；

Upsource：JetBrain 内部部署的 git/mercurial/perforce/svn 代码审查工具。

没有规则，就没有执行。规则中首当其冲的就是开发规范。
规范中建议包含：

• 工程规范（工程结构，分层方式及命名等等）
• 命名规范（接口、类、方法名、变量名等）
• 代码格式（括号、空格、换行、缩进等）
• 注释规范（规定必要的注释）
• 日志规范（合理的记录必要的日志）
• 各种推荐与不推荐的代码示例

如果团队人数较少，项目的工程复杂度较低，可以自行制定规范。毕竟适合团队的就是最好的。
如果团队有一定规模，且还会不断扩张，还是建议根据大厂的规范进行制定，或者是直接采用。

• 确定Code Review实施环节

CodeReview建议是放在代码提交测试前，也就是开发人员完成代码开发及自测后将代码提交到测试分支时进行Code Review。毕竟，如果测试通过后再进行Code Review，如果需要代码变更，势必会增加测试的工作量，甚至影响项目进度。亦或是顶着项目上线的压力，干脆“以后再说”了

以通用的Git Workflow来说，那就是把Code Review放在Feature分支合并到Develop分支时了。

• 制定角色行为规范

角色规则Developer1、一次提交的功能必须是完整的
2、默认细粒度提交（以独立的方法/功能/模块为单位）。如需粗粒度提交，需提前跟Reviewer沟通确认
3、Commit Message中要清晰描述变更的主题
必要时，可以以链接或者文件的形式附上需求文档/设计文档Reviewer1、不允许自我Review并Merge代码
2、Review不通过打回前需跟Developer说明原因并达成一致
3、Review不通过需明确填写打回的原因
4、单次Review时长需控制在2分钟~2小时内完成（特殊情况请说明原因）Approver1、审批不通过需注明原因
2、审批时长需要控制在1小时以内
3、对于放行的非质量问题，需持续跟进

这样规范，主要是为了：

1. 控制提交Code Review的代码的粒度
2. 控制单次Code Review的时间
3. 提升Commit/MergeRequest描述的质量，减少沟通成本

这样，我们就可以通过细粒度高频次的方式尽可能利用工程师碎片化的时间进行Code Review，一定程度上保证Code Review的效率。

毕竟，粗粒度甚至是集中式的Code Review，时间上难以把控。发现了问题的时候，修复的成本也往往更高。

有了工具、开发规范、流程规范，就可以指引参与的工程师参与Code Review，那么我们也要对Code Review的过程以及结果进行检验，毕竟不进行检查/验收的规则，是无法达到预期效果的。

Code Review毕竟不是数学题，我们无法通过简单的计算去验证。所以我们要通过侧面验证，来帮助Code Review的执行

• 定期分享

我们是期望CodeReview可以让工程师之间互相学习的，那么对于一次Code Review通常只有参与的2-3个工程师有互相学习的机会，那么在这个过程中学到的知识，定期的分享出来，既可以加强知识的流动，又可以检查大家究竟有没有在Code Review过程中学习到知识，或者有没有认真的进行Code Review

至于分享的内容，可以是开发规范中的范例代码，也可以是规范中的正例代码，也可以是针对某个功能实现的最佳算法/最佳实践，也可以是Code Review过程中的争议代码，也可以是自己踩过的坑。

总之，Code Review之后的代码分享，不但可以加强知识的流动，还可以检验Code Review的效果。

• 数据统计

为了在一定程度上保证Code Review的效率，我们在规范里是要求参与的工程师：

1. Developer控制提交Code Review的粒度，或者控制每个Commit的粒度
2. Developer要准确清晰的描述所提交的代码
3. Reviewer&Approver要在规定时间内完成Code Review

这些情况纯粹靠人工是无法检验的，还是需要有一定的数据统计。
如果用Gerrit，可以查询Gerrit的数据库，里面会有Code Review的信息，
如果用GitLab，可以通过WebHook或者restful API获取Code Review信息

我们可以做成报表，来展示Code Review的情况：

1. 每人每周Code Review所消耗的时间
2. 每人每周被Code Review所消耗的平均时间
3. 超过规定时间的Code Review情况
4. 代码提交描述字数过少的情况
5. 等等（根据自己的需要来）

以上情况只是Code Review的侧面反馈，用来帮我们发现Code Review执行过程中可能出现的问题。不过，出现问题并不意味着Code Review的质量/效率一定受到了影响。

比如，工程师A被Code Review的耗时是团队内最高，有可能是有某次代码是周五晚上提交的CodeReviw，这单次CodeReview的耗时就会超过48小时。也有可能是对应的Reviewer是团队新人，要通过相关业务项目了解对应Project的承担的职责及代码，这是个学习的过程，自然耗时加长。

又比如工程师B提交的代码描述文字过少，可能就是中间件团队对某些基础组件进行升级，或者安全团队要求升级某个依赖的开源组件，以修复某个安全漏洞。

但是通过这种的数据，可以让Code Review的情况直观的展示出来。来发现大家执行过程中需要优化的事项， 不断帮助大家完善规则，做好执行。

无论Code Review的工具以及流程是怎么样的，都少不了开发规范作为支撑，毕竟我们期望Code Review达到的效果之一就是，团队中的工程师可以写出像规范中描述那样的高质量代码。

工程师对研发规范的掌握程度，决定了自己编码代码的质量，也决定了自己Review通过的代码的质量。所以，无论如何，加强对研发规范的学习和理解，都是保证Code Review质量的重中之重

Code Review目的是帮助工程师交流和学习进步的。无论是技术能力还是编码习惯，亦或是业务知识。无论规则怎么制定，终究还是需要参与的工程师来执行，如果大家互相睁一只眼闭一只眼，互相降低要求，那么执行的效果一定会打折扣。

虽说三人行必有我师，但收益最大的一定是经验(技能/业务知识)尚浅的工程师，收益最低的一定是团队中最资深的工程师。而恰恰经验尚浅的工程师的收益大部分都要来自资深工程师的付出。

所以，一定要跟资深工程师最好沟通，让他们严格要求，不能对经验尚浅的工程师放水，以帮助他们提升编码能力以及业务知识。

这也可以减少甚至避免他们为经验尚浅的工程师的代码“善后”。

1、每个 Review 至少给一条正面评价。Code Review 本意是改善代码质量，增强团队成员之间的沟通，但是我一提交代码就有人说我写的垃圾，这很打击自信心啊，也不利于团队成员和平相处。代码有问题，指出问题是必须的，要实事求是，但是有的时候也需要给队友一点鼓励，例如简单的 或者“赞一个”我都很开心了。

2、保证发布的代码和评审意见的可读性。大家都是程序员，你提交代码的时候，在符合团队风格的同时，把代码弄的好看点，如果你明确自己这个代码哪个地方不足，Highlight 出来让大家给意见。如果你是来 Review 代码的，把意见写的通顺点，评论有条理一些。对反引号 (`) 嵌入代码或三个反引号 (```) 写代码块，这样看的舒服得多，效率也高。

3、对事不对人。大家是同事，在一个团队工作和气很重要。不要在 Code Review 中说“你写的什么垃圾东西这种话”，你可以说“这个变量名不好理解，咱们换成巴拉巴拉是不是更好”。

4、用工具进行基础问题的自动化检查。用 Tab 还是空格，用两个空格还是四个空格，函数后面怎么换行等基础问题检查，可以使用 eslint 和Rubocop 等类似的工具进行，团队成员应该把更多精力放在代码规范，代码性能优化等地方。

5、全员参加 Code Review，并设定各部分负责人。扩大 Code Review 参与面，参与不是说一定去审核别人的代码，可以是代码被审核，也可以是看别人审核意见，这都是学习的过程。并且每部分设定负责人，该负责人对这部分代码质量负责，负责人需要是资深工程师。全员参与 Code Review 可以让团队成员更快的成长，新人在看大佬 Review 代码的过程就能学到很多。

6、每个代码 PR 内容一定要少。Code Review 效果和质量与 PR 代码量成反比，你一下提交这么多代码，我今天还下不下班了？ 我女朋友你帮我陪？每次 PR 代码量小一些，看起来速度快，又不至于失去耐心，这样才能达到 Code Review 的效果，所以要经常进行 Code Review，但是每个 PR 代码量要少。我建议要少于 300 行/PR。

7、如果你有更好的方案，尽管提出来。在 Code Review 中经常会发现写的不好的地方，如果你有更好的方法，欢迎提出来！首先能改进这个 PR 的代码，其次能体现你的能力，团队应该定期对这种提出好的解决方案的同事进行奖励。

8、在写新代码之前，先 Review 掉需要评审的代码。你让我去 Review 一周前的代码？我还得把思维和项目进度切换到一周前？大家肯定不愿意，所以要形成规定，写新代码之前先把旧的 Review 掉，提交 PR 的时候也保证代码量小，这样 Review 起来不需要大块时间，改起来也快。不能因为 Code Review 大幅耽误项目进度，进度是全团队的事，不是某个人的事。

9. 不要在 review 中讨论需求，review 就是 review。不要在 Code Review 里搞别的，有需要就另安排时间进行，要明确 Code Review 是完善代码，不是需求和功能讨论，始终要以代码质量为中心。

总结了以上代码审查的好处、代码审查的工具和代码审查的一些建议，希望让大家重视起代码审查的工作，如何做好代码审查，这也是关系到团队的技术能力提升，代码质量等工作。