如何在云效上做好代码评审

背景

在行业激烈竞争业务快速运转的今天，如何在实现快速交付的同时保证代码质量一直以来都是技术团队反复探讨的话题之一。

代码质量可以通过两个维度来度量：一是代码的缺陷情况，二是代码可读性。代码缺陷小则引发线上故障影响业务正常运行，大则可能造成企业重大经济损失甚至信用受损，重则引发社会动荡；而代码可读性也尤为重要，可读性差则维护成本高，修改相关模块代码难度大。Google最早引入CodeReview的初衷就是为了保证代码具有良好的可读性，并将Readability Review延用至今。

有效的代码评审可降低故障率，本篇我们重点介绍团队如何在云效上做好代码评审。

用户的诉求或问题

• 没有统一的流程管控，团队同学基本不做评审，质量无法得到保障。

• 作为开发者在创建代码评审时，不清楚改动应指派哪些评审人。

• 如何做好代码评审。

云效代码评审解决方案

设置卡点

保护分支允许管理员根据团队的workflow，为单个分支或分支规则建立合适、灵活的分支管控，如：发布分支不允许所有人push，必须通过代码评审才能merge，以及一些merge的卡点条件。合并检查与分支权限协同管控，能为团队提供更加灵活可控的开发工作流程。设置卡点后，代码库下创建符合该保护分支规则的合并请求，均走该卡点配置。

1、要求合并前通过代码评审与自动化执行检查

打开对应代码库的设置页面，点击分支设置，新建保护分支规则（以master分支为例）。

设置人工评审卡点，如评审最少通过人数、什么角色成员能通过等。

评审人选择

作为开发者进行代码提交后创建代码评审，当代码库较大参与开发同学较多时，不知道该指派哪几位同学作为本次改动的reviewer。可采用以下几种方式：

1、保护分支默认评审人

不同研发模式，不同分支可能存在不同的负责人。代码库管理员可以通过将分支负责人配置为保护分支默认评审人，达到创建即指派分支负责人的效果。如：交付团队存在基线版本，交付不同定制方，每个定制版本均是一个分支形态，均存在相应版本负责人；

2、CodeOwner 模式

Author并不一定知道谁应该review自己的改动。CodeOwner机制就是去维护一个文件，指明哪些路径下的哪些文件应该由谁去review，当push更改中包含这些文件时，就会将负责这些代码的人自动加到评审人中。

我们使用了一个CODEOWNERS文件来记录代码库中各模块或文件的负责人，该文件应位于分支的根目录下。当一次评审发起后，并且代码库启用了CodeOwner审核，那么系统会在评审目标分支的根目录下，寻找CODEOWNERS文件，并从其中读取相关设置。当文件与CodeOwner出现了1:N的情况时，例如一个文件对应了A、B、C 三位Owner，此时只要有一位CodeOwner审核通过即可。此外，评审创建时或评审分支更新后，系统会自动检测需要参与评审的CodeOwner，并把他们自动加入审核人列表中。

CODEOWNERS文件中，对于路径的定义采用了Glob的语法。路径规则追加空格后，采用的形式定义相关Owner，username需使用对应Owner已验证并绑定的邮箱。已绑定邮箱可在个人设置-个人信息查看。文件示例如下：

# 注释行，以下为配置正文，每一行代表一个配置。
# 一个路径规则后边，需要有一个或多个Owner

# 用户 Tiger@example.net,Dragon@example.net 作为所有文件的CodeOwner
** @Tiger@example.net @Dragon@example.net

# 用户 Alan@example.net 作为所有java文件的CodeOwner
**.java @Alan@example.net

# 用户 Ben@example.net、Carl@example.net 作为force-api目录下文件的CodeOwner
force-api/** @Ben@example.net @Carl@example.net

# 用户 Mike@example.net 作为force-base/src/main/java目录下文件的CodeOwner
force-base/src/main/java/** @Mike@example.net

代码评审最佳实践

以下为如何做好代码评审的最佳实践：

• 做好提交

将提交做小做好，写小提交就是将问题解耦：“Do one thing and do it well”。开源项目的提交通常都很小，每个提交只修改一个到几个文件，每次只修改几行到几十行。每个提交应该是一个完整的功能，可能是修改某个bug或完成某个小需求的开发，commit message记录本次 commit 详细说明，大体分为：提交标题、主体body、sign签名，使阅读者能够清晰的理解改动的背景。

• 充分描述

对于代码评审描述应介绍本次改动的需求背景，改动范围及影响点。一段清晰的评审描述能让reviewer充分理解需求背景，快速开始评审，降低沟通成本。

• 小步快跑

在团队实践的过程中，经常碰到改动较大的评审，评审越大评审成本越高耗时越长。正确的方式是将CodeReview当做一个“日常习惯”而不是一个“盖章动作”。只有每次提交的内容尽可能的小而独立，才能真正让别人帮你review。因此，我们不鼓励到临上线前才做CodeReview，而是当拉出的分支做完一个小的提交后，就应该开始CodeReview。如：新人入职完成了API的定义想让同学看下模型定义上是否存在问题，就可以采用以上方式。对于开发中的代码评审，Author可将代码评审的标题支持设置WIP标识Work In Progress，使Reviewer有意识这不是一个完整的功能，且无法合并。

• 问题追踪

即使大家面对面坐着，讨论非常方便，事后仍要把评审中的问题记录进系统，进行问题沉淀，并由系统跟踪这些问题最终是否得到了解决，进行问题的跟踪和闭环。

• 定期度量

通过数据洞察获得团队质量情况，有策略的提升团队技术能力。