在行业激烈竞争业务快速运转的今天，如何在实现快速交付的同时保证代码质量一直以来都是技术团队反复探讨的话题之一。代码评审是结对编程相互切磋相互学习的方式，是敏捷开发模式中的一个重要环节，是保障代码质量的重要手段。有效的代码评审可降低故障率，本篇我们重点介绍团队如何在云效上做好代码评审。
代码质量可以通过两个维度来度量：一是代码的缺陷情况，二是代码可读性。代码缺陷小则引发线上故障影响业务正常运行，大则可能造成企业重大经济损失甚至信用受损，重则引发社会动荡；而代码可读性也尤为重要，可读性差则维护成本高，修改相关模块代码无异于埋雷，一不小心就会炸。
用户的诉求或问题
没有统一的流程管控，团队同学基本不做评审，质量无法得到保障
作为开发者在创建代码评审时，不清楚改动应指派哪些评审人
如何做好代码评审
** 云效代码评审解决方案**
1、如何设置卡点
保护分支允许管理员根据团队的 workflow ，为单个分支或分支规则建立合适、灵活的分支管控，如：发布分支不允许所有人 push，必须通过代码评审才能 merge，以及一些 merge 的卡点条件。合并检查与分支权限协同管控，能为团队提供更加灵活可控的开发工作流程。设置后该代码库下创建目标分支符合改保护分支规则的合并请求，均走该卡点配置。
- 要求合并前通过代码评审
可设置人工评审卡点，如评审最少通过人数、库内什么角色成员能通过等。
- 要求合并前通过自动化执行检查
提供官方插件 Java 代码规约扫扫描和敏感信息检测，且支持卡点设置。
具体参见代码扫描：
链接文字
2、评审人选择
作为开发者进行代码提交后创建代码评审，当代码库较大参与开发同学较多时，不知道该指派哪几位同学作为本次改动的 reviewer。可采用以下几种方式：
- 保护分支默认评审人
不同研发模式，不同分支可能存在不同的负责人。代码库管理员可以通过将分支负责人配置为保护分支默认评审人，达到创建即指派分支负责人的效果。如：交付团队存在基线版本，交付不同定制方，每个定制版本均是一个分支形态，均存在相应版本负责人；
- CodeOwner 模式
理想情况下的 Code Review，是评审人员就是最熟悉这块代码的同学，但是实际上Author并不一定知道谁应该 review 自己的改动。CodeOwner 机制就是去维护一个文件，指明哪些路径下的哪些文件被谁 own 应该谁去 review，当 push 更改中包含这些文件时，就会将 own 这些代码的人自动加到评审人中。
我们使用了一个 CODEOWNERS 文件来记录代码库中各模块或文件的负责人，该文件应位于分支的根目录下。当一次评审发起后，并且代码库启用了 CodeOwner 审核，那么系统会在评审目标分支的根目录下，寻找 CODEOWNERS 文件，并从其中读取相关设置。当文件与CodeOwner 出现了 1:N 的情况时，例如一个文件对应了 A、B、C 三位 Owner，此时只要有一位 CodeOwner 审核通过即可。此外，评审创建时或评审分支更新后，系统会自动检测需要参与评审的 CodeOwner，并把他们自动加入审核人列表中。
CODEOWNERS 文件中，对于路径的定义采用了 Glob 的语法。路径规则追加空格后，采用 @username 的形式定义相关 Owner，username 需使用对应 Owner 已验证并绑定的邮箱。已绑定邮箱可在个人设置-个人信息查看。
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 有意识这不是一个完整的功能，且无法合并。
- 问题追踪
即使大家面对面坐着，讨论非常方便，事后仍要把评审中的问题记录进系统，进行问题沉淀，并由系统跟踪这些问题最终是否得到了解决，进行问题的跟踪和闭环。
- 定期度量
通过数据洞察获得团队质量情况，有策略的提升团队技术能力。代码库统计模块更多能力敬请期待。
-END-
长按识别上图二维码进群，更多干货、优惠活动等你解锁
点击:https://codeup.aliyun.com/?channel=yy_rccb链接文字
进入产品进行体验
快来试试，若有收获，点个赞吧！！！
