首页/开发/代码质量与评审速查/多轮评审:每轮都要收敛
代码评审64 条

多轮评审:每轮都要收敛

评审多轮是常态,但要保证每轮收敛:作者处理完阻塞项再请求复核,评审者聚焦增量变化,避免每轮重新打开已决问题。

多轮评审为什么要收敛

评审多轮是常态,关键是每轮都朝结论走:作者先把阻塞项全部处理完再请求复核,评审者聚焦本轮新增的差异,已决问题除非有新事实否则不再重开。收敛的评审把讨论推向结论,发散的评审把结论越推越远。

基本信息

作者动作处理完阻塞项后再点重新评审
评审者动作先看新增差异,再抽查关联结果
已决问题除非出现新事实,否则不翻旧账
失控信号三轮以上仍在反复,应转同步沟通

典型使用场景

  • 第一轮意见较多属正常:先分清阻塞项与非阻塞项
  • 作者逐条回复:已修复、说明理由、另开任务三选一
  • 评审者复核增量:避免每轮全量重读,注意力有限
  • 反复拉扯时转语音或当面沟通:结论仍要回写到评审里
  • 同类意见反复出现:写进自检清单,减少下一轮往返

每轮复核的固定动作

  • 作者:逐条回复上轮阻塞项,贴出对应提交
  • 作者:阻塞项清零之后再点重新评审
  • 评审者:只看本轮新增差异,确认上轮问题已闭环
  • 评审者:新发现另开线索,不与历史结论混在一起

回复模板

回复模板
已完成:按意见拆出独立查询方法,见提交 3f21ab9。
说明理由:这里保留同步调用,调用方在下游已有超时控制。
另开任务:日志改造拆分到任务单 #1502,不在本次范围内。

轮次状态与处理

轮次状态处理动作
一两轮内闭环正常节奏:高频意见沉淀进自检清单
三轮以上仍反复先查描述与标准:补说明、明确通过条件
反复推倒重来停文字往复,转当面或语音对齐方案后重审
轮次本身不是问题,缺少收敛才是:同一个问题被反复讨论,说明标准没有讲清楚。
把评审往返沉淀成自检清单,下一轮作者自己就能先过一遍。

易错点

  • 每轮全量重读:评审者疲劳,后期的改动反而没人细看
  • 把推倒重写当作回应:评审者需要重新建立上下文
  • 已决问题反复重开:讨论绕圈,改动的必要条件一直对不齐
  • 轮次失控仍不改成同步沟通:文字往复持续拉长交付时间

数据来源与参考

  • Google Engineering Practices · The CL Author's Guide(处理多轮意见)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌