代码评审轮数
| 属性 | |
|---|---|
| 指标定义 | 开发者请求代码合并后，评审者与开发者之间进行评审交流的轮数。 |
| 指标价值 | 1. 代码评审轮数体现开发者提交代码的质量，评审轮数越少，代表一次性通过率越高，即代码质量越高。 |
| 指标来源 | 版本控制系统 |
| 实践域 | 开发 |
| 认知域 | 交付质量 |
| 度量范围 | 项目、团队 |
MARI 方法
度量
- 分别统计开发者和评审者的代码评审轮数。
- 从项目或团队维度，对所属成员的代码评审轮数进行聚合统计。
分析
开发者平均代码评审轮数
选定时间段，并结合任务复杂度，统计开发者的平均代码评审轮数。这个指标可以一定程度反映出该开发者的代码质量，也为定位项目瓶颈提供了参考信息。
在选定时间段内，某位开发者的
平均代码评审轮数 = 该时间段内该开发者提交的所有合并请求所经历的评审轮数总和 / 代码合并请求数。关注连续排名靠前或高于基线水平的开发者，分析是否存在聚类现象。
评审者平均代码评审轮数
选定时间段，并结合任务复杂度，统计评审者的平均代码评审轮数。这个指标可以一定程度反映出评审者的评审风格，也为定位项目瓶颈提供了参考信息。
在选定时间段内，某位评审者的
平均代码评审轮数 = 该时间段内该评审者的评审轮数总和 / 该评审者处理的代码合并请求数。关注排序连续靠前及靠后的评审者，分析是否存在聚类现象。
评审者代码评审总轮数
选定时间段，并结合任务复杂度，统计评审者的总评审轮数。这个指标可以一定程度反映出评审者在评审环节的活跃度和工作负载，也为定位项目瓶颈提供了参考信息。
关注连续排名靠前或高于基线水平的评审者，以及排序连续靠后的评审者，分析团队成员评审工作负载是否健康。
项目/团队维度统计
从项目或团队维度，结合项目所属阶段与团队任务复杂度，对所属成员的代码评审轮数进行聚合统计，获得平均代码评审轮数，代码评审总轮数等数据，可以一定程度反映出项目与团队评审工作人员分配是否合理，当前负载是否健康。
回顾
针对代码评审轮数指标异常偏高或偏低的情况，结合团队及项目实际情况，调研原因。
以下以代码评审轮数过高为例，列举几条可能的原因：
- 开发者方面
- 编码不符合规范，代码可读性较低
- 合并请求颗粒度过大，不易理解
- 代码质量问题较多，包括缺陷及软件工程质量问题（如结构设计不合理）
- 未能清晰理解业务需求
- 评审者方面
- 因主观因素评审尺度较严格
- 评审尺度未符合编码规范
- 项目性质方面
- 项目处于早期阶段，或者任务难度较高
调查多个案例后，可继续统计分析异常原因的分布情况，观察是否某一类原因偏多，更进一步调研。
以下以开发者代码质量问题较多为例，列举几条可参考的调查思路：
- 团队是否使用开发自测工具？是否设置了关键自查项？是否建立了自测缺陷处理规范？
- 代码提交人工评审前，开发者是否使用工具进行自测？是否按照规范进行了严重缺陷的修复?
- 编码规范培训、实施、考核是否到位？
- 开发者是否需要业务、技术、规范方面的进一步培训？
- 代码评审的反馈中，有无高频出现的质量优化建议？可否沉淀为规范,或用于优化自动检测工具？
改进
针对回顾结果，对阻塞环节，从规范、流程、工具、行为等方面给出针对性改进措施，明确提升目标、改进措施、验证周期及责任人。
以下为可参考的改进思路:
- 定期基于代码评审的典型问题，更新《编码规范》及代码评审检查单，保证规范及检查单的可用性。
- 根据代码评审的典型问题，优化静态检测工具的检测规则，减少编码规范类问题遗漏到人工评审。
- 当代码评审轮数持续偏高时，需根据调研结果从编码规范、代码评审检查单、面向作者进行培训及考核。
- 明确代码提交人工评审的入口规则（如：先解决静态扫描出的重点问题再人工评审，建立核心10-20条代码评审自查/检查项。）
- 建立评审专家抽查制度，保证代码评审的质量，避免代码评审不充分造成的缺陷向下游测试泄露。
- 根据功能实现的复杂度、业务类型等，为代码评审选择合适的代码评审者。
改进成果也应当是可量化的，便于持续度量，追踪改进效果。