如何在团队中作好Code Review

1、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的职责。

2、推进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 综合对比

工具	权限 控制	UI 交互	源代码 管理	可维护	数据 统计	工具 配套
Gerrit	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐	⭐ ⭐ ⭐	⭐ ⭐	⭐ ⭐ ⭐ ⭐	⭐ ⭐
GitLab社区版	⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐
GitLab企业版	⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐ ⭐	⭐ ⭐ ⭐ ⭐

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

基于GitLab的CodeReview教程： https://ken.io/note/gitlab-co...

二、制定开发规范

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

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

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

Java开发手册： https://github.com/alibaba/p3c
Google代码风格指南： https://zh-google-styleguide.... （涵盖：C++、Python等）

三、制定流程规范

• 肯定Code Review实施环节

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

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

• 制定角色行为规范

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

这样规范，主要是为了：

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的状况直观的展现出来。来发现你们执行过程当中须要优化的事项， 不断帮助你们完善规则，作好执行。

3、保证Code Review质量的关键

一、工程师对研发规范的认真学习

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

工程师对研发规范的掌握程度，决定了本身编码代码的质量，也决定了本身Review经过的代码的质量。因此，不管如何，增强对研发规范的学习和理解，都是保证Code Review质量的重中之重

二、资深工程师的认真对待

Code Review目的是帮助工程师交流和学习进步的。不管是技术能力仍是编码习惯，亦或是业务知识。不管规则怎么制定，终究仍是须要参与的工程师来执行，若是你们互相睁一只眼闭一只眼，互相下降要求，那么执行的效果必定会打折扣。

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

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

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

4、备注

附录

• Java开发手册：https://github.com/alibaba/p3c
• 基于GitLab的CodeReview教程：https://ken.io/note/gitlab-co...
• Google代码风格指南：https://zh-google-styleguide....
• Jenkins+Sonar执行代码扫描：https://ken.io/note/jenkins-m...

---

本文首发于个人我的博客：https://ken.io/note/how-to-do-code-review-in-a-team