代码评审64 条

评审度量怎么用

评审度量用于发现流程瓶颈:首次响应时长、评审完成时长、轮次与 CL 规模分布;用于改进流程,而不是考核个人。

  • 首次响应时长:反映评审是否卡在队列(参考目标:一个工作日)
  • CL 规模分布:拆不动的大改动从哪里来
  • 评审轮次:轮次异常多为描述不清或标准不一致
  • 反面用法:评论数与批准数排名会扭曲行为

可按周采集的评审口径

可按周采集的评审口径
首次响应时长:请求评审到首条实质反馈(中位数与 P90)
完成时长:请求评审到批准(P50 / P90)
轮次:每个 PR 的评审轮数(均值与长尾)
改动规模:PR 行数分布与超阈值占比
积压:等待超过一个工作日的 PR 数量
口径固定后按周看趋势,不逐周改定义。

指标异动时先查什么

指标异动先查什么
首次响应变慢评审人负载与值班安排是否变化,队列是否失衡
完成时长变长大改动占比与反复轮次:拆分缺位还是标准不清
评论多而缺陷仍多注意力是否集中在风格细节,回到设计、功能、测试层次
度量若不透明会被博弈:先公开口径,再用数据谈改进。

易错点

  • 把评论数当勤奋指标:产生无意义评论
  • 只测个人不测流程:改进空间被错过

数据来源与参考

  • Google Engineering Practices · Speed of Code Reviews(度量用途)
  • 《Accelerate》(指标治理)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌