代码评审的最佳解决方案

有效的代码评审可降低故障率，码评审是结对编程相互切磋相互学习的方式，是敏捷开发模式中的一个重要环节，是保障代码质量的重要手段。云效代码管理 Codeup，10万企业都在用的代码管理平台，提供代码托管、代码评审、代码扫描、质量检测、持续集成等功能。

​​立即体验​​

​代码评审是结对编程相互切磋相互学习的方式，是敏捷开发模式中的一个重要环节，是保障代码质量的重要手段。​

背景

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

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

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

用户的诉求或问题

• 没有统一的流程管控，团队同学基本不做评审，质量无法得到保障
• 作为开发者在创建代码评审时，不清楚改动应指派哪些评审人
• 如何做好代码评审

云效代码评审解决方案

​如何设置卡点​

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

​说明 ​

立即体验：​​云效代码分支设置​​

​​1、要求合并前通过代码评审​​

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

​2、要求合并前通过自动化执行检查​

提供官方插件 Java 代码规约扫扫描和敏感信息检测，且支持卡点设置。具体参见：​​链接文档​​

​评审人选择​

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

​1、保护分支默认评审人​

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

​2、CodeOwner 模式​

理想情况下的 Code Review，是评审人员就是最熟悉这块代码的同学，但是实际上Author并不一定知道谁应该 review 自己的改动。CodeOwner 机制就是去维护一个文件，指明哪些路径下的哪些文件被谁 own 应该谁去 review，当 push 更改中包含这些文件时，就会将 own 这些代码的人自动加到评审人中。

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

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

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

# 用户 [e-mail],[e-mail] 作为所有文件的CodeOwner
** @[e-mail] @[e-mail]

# 用户 [e-mail] 作为所有java文件的CodeOwner
**.java @[e-mail]

# 用户 [e-mail]、[e-mail] 作为force-api目录下文件的CodeOwner
force-api/** @[e-mail] @[e-mail]

# 用户 [e-mail] 作为force-base/src/main/java目录下文件的CodeOwner
force-base/src/main/java/** @[e-mail]

​3、智能评审人推荐​

即将上线，敬请期待。

​代码评审最佳实践​

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

• ​​做好提交​​

将提交做小做好，写小提交就是将问题解耦：“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 有意识这不是一个完整的功能，且无法合并。

• ​问题追踪​

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

• 定期度量

通过数据洞察获得团队质量情况，有策略的提升团队技术能力。关于代码库统计模块即将上线，敬请期待。

​​立即体验​​

---

关于我们

了解更多关于云效DevOps的最新动态，可微信搜索关注【云效】公众号；

彩蛋：公众号后台回复【指南】，可获得《阿里巴巴DevOps实践指南》&《10倍研发效能提升案例集》；

看完觉得对您有所帮助别忘记点赞、收藏和关注呦；