共计 2444 个字符，预计需要花费 7 分钟才能阅读完成。
无效的代码评审可升高故障率，如何在云效上做好代码评审，云效代码评审是结对编程互相切磋互相学习的形式，是麻利开发模式中的一个重要环节，是保障代码品质的重要伎俩。云效代码治理 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 已验证并绑定的邮箱。已绑定邮箱可在集体设置 - 个人信息查看。文件示例如下：
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 无意识这不是一个残缺的性能，且无奈合并。
- 问题追踪
即便大家面对面坐着，探讨十分不便，预先仍要把评审中的问题记录进零碎，进行问题积淀，并由零碎跟踪这些问题最终是否失去了解决，进行问题的跟踪和闭环。 - 定期度量
通过数据洞察取得团队品质状况，有策略的晋升团队技术能力。对于代码库统计模块行将上线，敬请期待。
云效代码治理 Codeup，10 万企业都在用的代码治理平台，提供代码托管、代码评审、代码扫描、品质检测、继续集成等性能，全方位爱护企业代码资产，帮忙企业实现平安、稳固、高效的代码托管和研发治理。
点击立刻体验：云效代码治理 Codeup