代码评审出现负载不均时，常见表现是少数评审人长期排队、另一些人空闲、紧急合入被卡住。处置时先判断成因属于分派规则、评审人范围还是提交节奏，再按“冻结新增分派—盘点在途评审—按专长与在途量重新指派—通知交接—观察验证”的顺序推进。本文聚焦评审与合入管理，不涉及代码质量优化。
要点总览（TL;DR）
- 先看三个信号判断是否属于结构性问题：排队集中在少数人、部分合格评审人长期空闲、紧急合入被单点阻塞。
- 用分派记录、评审人池与专长对应关系、在途评审数、提交时间分布四类证据，区分熟人路径、专长集中、缺少在途上限和提交高峰四种成因。
- 重新分派按冻结新增分派、盘点在途评审、按专长与在途量改派、通知交接的顺序执行；接近合入和高风险改动的评审谨慎改派。
- 防复发靠单人同时在途上限、评审人池与专长标签、按模块与轮值分派、定期复盘分派分布四项机制，并预先定义复发信号与升级路径。
- 改派后用评审在途量分布、最长等待时长和改派后完成情况验证恢复，观察窗口覆盖两到三个提交周期。
负载不均的表现与影响范围
负载不均首先是一种分布问题：同样的评审总量，在不同评审人身上呈现出明显不同的等待时间和在途数量。判断时看三个可观察信号：一是评审请求的排队时长集中在少数人身上，二是部分具备资格的评审人长期没有收到评审请求，三是紧急合入因为等待某位评审人而延期。这三个信号同时出现，基本可以确认分派环节存在结构性问题，而非个别人的临时忙碌。
症状背后通常对应三类来源，区分清楚才能选对处置手段。
- 个人偏好导致的集中：提交者习惯找熟悉的评审人，或评审人习惯承接某类请求，形成固定的“熟人路径”。表现为分派记录中同一提交者与同一评审人反复配对。
- 模块专长集中：某些模块只有少数人熟悉，评审请求自然向这几个人聚集。表现为模块与评审人的对应关系高度集中，其他评审人即使有空也无法有效承接。
- 分派规则缺失：没有明确的评审人池、在途上限或轮值机制，分派完全依赖临时指定。表现为分派记录无规律，个别人在途评审数持续偏高。
本文的范围限定在评审与合入管理：讨论谁来看、看多少、如何交接、如何避免再次堆积。代码本身的写法改进、算法选择、性能优化不在讨论范围内；评审等待时长作为研发流动效率指标的系统分析，也属于另一类议题，本文只在验证恢复时使用相关数据。
先分清原因：分派规则、评审人池还是节奏问题
把现象直接当成结论，容易做出错误处置。例如看到某位评审人积压就立刻增加评审人，但如果真实原因是提交节奏集中，新增人手在高峰过后又会闲置。更稳妥的做法是先列出原因假设，再用可查证据逐条验证。
| 原因假设 | 典型表现 | 可查证据 | 排查顺序 |
|---|---|---|---|
| 分派靠人工指定，熟人路径集中 | 同一提交者反复找同一评审人 | 近一段时间的分派记录，按提交者与评审人配对统计 | 先查，成本最低 |
| 评审人池过窄或专长标签缺失 | 可指派的候选人只有少数几个 | 模块与评审人的对应关系、评审人池名单 | 次查，决定可选范围 |
| 缺少在途上限，个别人被反复指派 | 个别人在途评审数持续偏高 | 每位评审人当前在途评审数的时间序列 | 与第一项同时查 |
| 提交节奏集中，短时高峰造成排队 | 排队集中在特定时段，过后缓解 | 评审请求的提交时间分布、排队时长按时间分段 | 最后查，用于解释残余波动 |
排查时建议按上表顺序推进：先看分派记录，确认是否存在明显的配对集中；再看评审人池和专长标签，确认可选范围是否足够；随后统计在途评审数，判断是否缺少上限约束；最后用提交时间分布解释高峰时段的排队。四类原因可能同时存在，处置时按影响程度排序，优先处理证据最充分的一类。
需要提醒的是，证据要覆盖足够长的时间窗口。只看一两天的分派记录，容易把某次集中提交误判为规则问题；建议至少覆盖两到四个完整的提交周期，并区分工作日与发布前的特殊时段。
重新分派的操作步骤
确认原因后进入处置。重新分派的目标是把在途评审从过载的评审人转移到有余量且具备专长的人手上，同时保证评审上下文不丢失。按以下顺序执行。
第一步：冻结新增分派。暂停自动或人工的新分派动作，让当前分派状态稳定下来。冻结期间新提交的评审请求进入待分派队列，不直接落到任何人身上。冻结的时间不宜过长，通常以完成一次完整盘点为准。
第二步：盘点在途评审。列出所有尚未完成的评审，按模块、紧急度、当前评审人在途量三个维度排序。盘点结果要能回答：哪些评审卡在最忙的人手上，哪些评审已经接近完成，哪些模块缺少可接手的评审人。
第三步：按专长匹配与在途量均衡重新指派。对每条待改派的评审，先筛出具备该模块专长的候选人，再在其中选择在途量较低的人。原评审人已经给出的意见保留在评审记录中，作为新评审人的参考输入，避免重复劳动。改派时同步更新评审人字段和截止时间。
第四步：通知交接。分别通知原评审人与新评审人，说明交接范围、已完成的评审内容、剩余关注点和新的截止时间。通知内容要具体到评审条目，避免只做口头转达导致上下文丢失。
改派存在风险边界，需要提前划定：
- 已经接近合入、仅剩少量意见确认的评审，谨慎改派。此时更换评审人可能引入新的关注点，延长整体周期。
- 涉及安全、权限、数据迁移等高风险改动的评审，改派前确认新评审人具备相应判断能力。
- 同一评审被多次改派会累积上下文损耗，单条评审的改派次数建议设上限，超过上限时改为补充评审人而非替换。
在工具承载上，评审请求可以作为工作项管理，评审人、模块、在途状态作为字段记录，改派动作留下变更历史，便于后续复盘分派分布。ONES 的工作项与流程配置可以承载这类记录和状态流转，具体字段与规则设置需结合团队实际流程确定。
如何验证恢复并防止再次发生
改派完成不等于问题解决，需要用数据确认分布是否回到合理区间。建议观察以下指标：
- 评审在途量分布：各评审人的在途评审数是否落在相近区间，是否仍有明显的高位个体。
- 最长等待时长：排队最久的评审请求等待时间是否下降，紧急合入是否不再被单点阻塞。
- 改派后完成情况：被改派的评审是否在约定截止时间内完成，是否出现因交接不清导致的返工。
观察窗口建议覆盖两到三个提交周期，避免用单日数据下结论。若分布仍未收敛，回到原因排查环节，检查是否遗漏了节奏因素或专长覆盖缺口。
防复发的机制建设可以从四个方面入手：
- 设定单人同时在途评审上限。为每位评审人设置可同时承接的评审数量上限，达到上限后新请求自动流向其他候选人。上限值按团队评审能力和提交量确定，并在复盘中调整。
- 建立评审人池与专长标签。按模块维护可承接评审的人员名单，标注专长领域和可承接的改动类型。名单定期更新，人员变动或模块调整时同步修订。
- 按模块与轮值规则分派。在专长匹配的基础上引入轮值，让同一模块的评审请求在合格候选人之间轮转，减少熟人路径。规则要写明优先级：专长匹配优先，在途量均衡其次，轮值兜底。
- 定期复盘分派分布。按固定周期统计分派记录和在途量分布，发现集中趋势及时调整评审人池或上限设置。
复发信号需要提前定义，便于及时升级处理：某位评审人的在途量连续超过上限、紧急合入再次因等待评审而延期、分派记录中重新出现固定的提交者与评审人配对。出现任一信号时，先暂停相关规则的分派，复查评审人池和上限设置，必要时重复一次重新分派流程。把复发信号和升级路径写进团队的分派规则文档，可以让处置动作在下次出现时更快启动。
常见问题
重新分派时，原评审人已经写了一半的意见怎么处理？
把原评审人已提交的意见保留在评审记录中，作为新评审人的参考输入，改派时在交接说明里注明哪些问题已确认、哪些仍待判断。这样新评审人不必从头读一遍改动，也能避免同一问题被重复提出。若原评审人的意见涉及对实现方向的否定，建议在交接时一并说明理由，减少新评审人重新走一遍讨论的成本。
团队规模小、每个模块只有一两位合格评审人，还能做负载均衡吗？
可以，但手段要从“扩大候选人范围”转向“控制节奏和补充评审人”。具体做法包括：为关键模块设置备份评审人并安排交叉熟悉，让在途量高时由备份人承接低风险改动；对同一模块的评审请求按到达顺序排队，避免插队加剧集中；在提交高峰前预留评审时间，减少短时堆积。人员确实无法扩充时，把在途上限设得更保守，并接受部分评审等待时间变长，比让个别人长期过载更可持续。
改派后多久能判断负载是否恢复？
建议覆盖两到三个完整的提交周期再下结论。单日数据容易受集中提交影响，可能把正常波动误判为未恢复。判断时同时看三项：各评审人在途量是否落在相近区间、最长等待时长是否下降、被改派的评审是否在约定截止时间内完成。三项中若只有等待时长下降而在途量仍集中，说明改派只缓解了表面排队，分派规则还需要调整。
在途上限设多少合适，设了之后紧急评审怎么插队？
上限值没有统一标准，可以按团队历史在途量的中位水平起步，再根据复盘结果调整。设置时要为紧急评审留出通道：明确哪些情况属于紧急（如线上故障修复、发布阻塞），紧急请求可以突破上限，但需要记录原因并在复盘中统计频次。若紧急插队频繁发生，说明上限设置或提交节奏本身有问题，应回到原因排查环节，而不是持续靠例外放行。
评审分派规则写进文档后，如何保证执行时不走回熟人路径？
规则文档只是起点，执行要靠可见的记录和定期检查。把每次分派的评审人、模块、分派依据记录在评审请求上，复盘时按提交者与评审人配对统计，出现固定配对就及时提醒。轮值规则要写明优先级顺序，让分派结果可以解释。新成员加入或模块负责人变动时同步更新评审人池，避免规则与实际人员脱节。
