代码评审检查清单与提交合并规范落地.docxVIP

代码评审检查清单与提交合并规范落实

评审范围界定与准入前置条件

××团队划了一条硬线：改动触及约3个文件、涉及1个核心模块或新增1张数据表时必须走评审，纯格式化与注释微调可免审。准入门槛把日均评审量压到每人约5个合并请求，免得评审队列堆到30个却没人细看。

评审前先自检一遍：本地编译通过、单元测试跑绿、静态扫描无高危项。缺任一项当轮退回，约10分钟内就能判定，不占用别人的时段。返工记录显示，跳过自检的请求平均多花约1.5个人日才合并。

范围模糊是评审拖期的首因。××要求每个请求标注受影响接口数与预计回滚耗时，回滚超过30分钟的按高风险单独排会，评审人提前2小时到场读码。

改动规模

评审方式

参与人数

最长时长

回滚要求

1到2个文件

结对快评

2人

约15分钟

无需预案

3到5个文件

单人评审

1人

约30分钟

口头确认

6到10个文件

双人评审

2人

约45分钟

书面预案

跨模块大改

专项评审会

4人

约1.5小时

演练1次

资金核心链路

架构加签

3人

约60分钟

双人复核

检查清单条目分级与覆盖

清单不是一张通用表，××把它拆成3级共约40项：一级红线12项（越权、注入、密钥硬编码、金额精度），二级健壮性16项（超时、重试、并发、降级），三级风格与可读性12项。一级任一项不过直接打回。

每项给可判定的表述，不用“看着还行”这类含糊话。××示例：核对分页参数上限是否小于500条