CodeReview 规范 - Mr X 百花齐放

1 目标

CodeReview 是业界公认的能够提升代码质量，促进知识共享的工程方法。通过高质量的 CodeReview ，帮助开发测试提前发现代码缺陷和深层次风险问题，降低线上问题发生的机率。

为了提高 CodeReview 的质量，避免人力的浪费，我们对 CodeReview 的方式和过程做了规范。整个规范包含评审前、评审中、评审后三个阶段；同时规范包含建议和强制等规则。

2 评审委员

整个 CodeReview 流程参与者有两种，一种是 CodeReview 审核人员，对提交的代码进行审核，称之为评委；另一种是提交代码的人员，称之为代码提交人员。两部分角色各不相同，共同完成 CodeReview 的整个流程。该部分重点介绍评委相关。

2.1 评审委员认证机制

为了落实严格的 CodeReview 机制，来把控我们的代码研发质量、代码研发规范和业务实现的合理性，并通过日常 review 反馈机制，形成价值导向，促进部门整体的研发水平提升，我们将对评委的筛选做一定的条件认证。

1）CodeReview 评委，必须熟知相应的编码规范内容，尤其对强制约束条件有深刻理解。

2）为保证 Review 质量，CR 评委须为 L7 以上人员或对该模块精通的资深人员.

3）CodeReview 评委，必须满足一定的要求，考核通过方可参与 Review 代码。

2.2 评审委员奖罚措施

在进行 Review 过程中，为了保证职责明确，对有多个评委的仓库来说，会对每个 CR 指定对应的评委，并采取 OWNER 制度，保证制度运行。同时对于评委会给予适当的奖罚措施。

1）与 HR 商定，在其头像上增加 CodeMaster 勋章；

2）在内部晋升方面，评委人员工作可作为内部考核材料之一。

3）对多次违反部门 CR 流程规范的，取消评委资格。

3 CodeReview 流程

3.1 评审前:

【强制】评委需通过 CodeMaster 相关认证，非认证人员无CR通过权限。

【强制】提交 CR 前，必须完成并通过代码自测。

【建议】提交 CR 前，建议 Peer 或 Mentor 提前进行 Preview。

【建议】 CR 系统需要提供工具保证 CR 流程执行。

【建议】每个仓库至少增加两位评委，但不多于5位。

3.2 评审中：

【强制】评委人员须有效、真实反应代码问题；

【强制】评委人员至少有一人参与代码主评审；

【强制】代码提交人员必须解决并回复评委提出的问题；

【建议】评委需在 CR 提交后24小时内给予 review 建议，特殊情况除外。

3.3 评审后：

【强制】线上代码必须有至少一个评委通过后，才能合并到 Master 和上线。

【强制】每个开发分支，提交时，需要关联 ones 或任务 id，使用 ones 创建的分支除外（该分支会自动关联）。

在第一次git commit 时需输入开发任务/缺陷任务编号，commit message 需包括三部分内容：任务编号、Header 和 Body 。格式如下：

      
  
# git commit 3033235                                                             // 任务编号支持多个，多个直接英文逗号,分割
简要描述此次 commit 的改动范围/内容                                       // Header，说明 commit 类型、范围和简短描述
如果出现重大改变填写(例如版本升级、接口升级、架构调整、项目分离迁移etc)        //可选，是对 commit 的详细描述

【建议】核心模块建议配置两人以及以上评委通过方可提交。

4 CodeReview 落地的工具和数据支持

4.1 CR相关工具支持

基于如上 CodeReview 落地到研发交付流程中的规范说明，需要在代码管理系统中提供对应功能卡点和数据度量支持。概述说明如下：

卡点功能	功能描述	卡点场景	备注
【提测准入pr卡点】	1. 提测前以组织维度进行 pr 校验的配置； 2. 配置支持开启/关闭； 3. 开启卡点必须配置 approve 大于等于的人数。	触发卡点需同时满足条件pr 卡点校验内容说明pr 卡点结果，须同时满足校验条件 • RD 同学开始【准入】流程 • 迭代创建人所属组织是否开启pr卡点 • 当前准入的所有分支是否作为源分支创建过 pr • pr approve 人数大于等于卡点设置的要求 • 通过，进行准入下一步。 • 失败，准入失败。	【准入】卡点的范围覆盖 rd 联调自测及交付 QA 之前的所有准入流程；对于未pr的分支，准入自测会失败。
【代码合并pr卡点】	1. 代码合并 Release 分支前，以仓库维度进行pr校验的配置； 2. 支持使用fsd的应用pr配置模版，或使用code平台的pr配置模版； 3. 需要指定pr的目标分支； 4. 开启卡点必须配置approve大于等于的人数； 5. 其他模版中的选项。	触发卡点需同时满足条件pr卡点校验内容说明pr卡点结果，须同时满足校验条件 • 在code平台触发分支合并 • 分支名称遵守分支开发规范命名。 • 当前合并的源分支创建过pr • 根据应用的pr设置项目进行校验（包含目标分支类型、approve人数、指定审核人的审批情况、成功构建、pr待解决评论是否解决等） • 通过，分支合并成功 • 失败，分支合并失败

4.2 CodeReview 数据统计支持

为了更好赋能研发落地 CodeReview 工程实践，针对CodeReview提炼了一些核心指标提供可视化报表，为各团队提供运营落地提供数据抓手。

整体原则：开发分支通过发起pr的方式发起CodeReview动作或通过pr向目标分支发起merge动作，审核人通过评论的方式处理审核各pr，针对审核后需要优化的点可以通过问题进行追踪处理解决形成闭环，最终审核通过后完成Approve或代码合并的动作。

详见指标口径详见如下。

指标名	统计口径描述
分支总数	搜索时间范围内上线分支总数 • Jar类型：release包在st或prod有构建 • 非Jar类型：部署prod机器大于80%
分支发起pr占比	发起pr分支数/分支总数分支总数=分支部署prod环境时间搜索范围内发起pr分支数=分支部署prod环境时间在搜索范围内 & 在pr记录表中有创建pr的分支数备注：“有创建pr的分支”是指作为源分支创建pr，目标分支不计入统计下钻中根据目标分支判断是提测前还是上线前pr
待处理pr占比	待处理pr分支数/pr分支总数 pr分支总数=分支部署prod时间 &pr创建时间在搜索范围内待处理pr分支数=pr创建时间在搜索范围内 & 搜索范围内分支最新创建pr的all_user_approve=false
评审通过pr占比	pr通过分支数/pr分支总数 pr分支总数=分支部署prod时间 &pr创建时间在搜索范围内 pr通过分支数=pr创建时间在搜索范围内 & 搜索范围内分支最新创建pr的all_user_approve=true
未进行PR直接上线的分支占比	未进行pr分支数/分支总数分支总数=分支部署prod时间在搜索范围内未进行pr分支数=分支部署prod时间在搜索范围内 &在pr记录表中没有作为源分支的pr分支数
有评论pr占比	有评论pr分支数/pr分支总数 pr分支总数=分支部署prod时间有评论pr分支数=分支部署prod时间 & pr评论数>=1
有评论pr分支平均评论数	评论总数/评论pr分支总数评论pr分支总数=分支部署prod时间 &pr评论数>=1 评论总数= 分支部署prod时间在搜索范围内 & 所有评论数总和
PR问题解决率	分支已解决评论数/分支pr需要解决评论总数分支pr需要解决评论总数=pr创建时间在搜索范围内 & 所有勾选了「待解决」评论总和分支已解决评论数=pr创建时间在搜索范围内 & 所有勾选了「待解决」评论 &评论状态为已解决