如何做好后端代码评审提升代码质量

做好后端代码评审的关键不在"审得多细"，而在三件事：把单次改动的规模压到 400 行以内、把格式与静态检查交给 CI 自动跑、把人的注意力集中在安全、并发、事务、数据兼容这四类工具查不出的问题上。做到这三点，评审从"看心情挑刺"变成稳定的质量闸门。

为什么大多数代码评审流于形式？

结论：评审低效的根因是两个——单次 diff 过大导致审查者疲劳，以及没有统一清单导致每人只看自己熟悉的部分。

被广泛引用的 Cisco/SmartBear 代码评审研究发现：单次评审 200-400 行代码时缺陷发现密度最高，超过 400 行后每行代码被发现的缺陷数量明显下降；单次评审超过 60 分钟，审查者的有效注意力会快速衰减。也就是说，一个 2000 行的 PR，即使你认真读了两小时，漏掉的缺陷大概率比一个 300 行的 PR 多。

另一层问题是标准不统一。A 审查者盯着命名规范，B 盯着括号换行，真正可能引发线上事故的并发和事务边界反而没人看。解决办法不是要求"更认真"，而是把检查项写下来，让每个人按同一张清单走。

单次 PR 应该控制多大？

结论：后端 PR 的有效改动控制在 200-400 行，超过 400 行就拆。

拆分方式有三种：按功能垂直拆（先提交数据模型变更，再提交业务逻辑，最后提交接口暴露）、按"重构"与"行为变更"拆（重构 PR 不改行为，改行为的 PR 不顺手重构）、按 commit 拆（一个 commit 只做一件可描述的事，评审者可以逐个 commit 看）。

例外只有两类：自动生成的代码（proto 生成物、SDK 桩代码），以及纯粹的版本号/配置更新。这两类可以直接跳过人工审查，只跑 CI。

评审前应该先让工具做什么？

结论：格式、静态检查、单元测试、依赖漏洞扫描这四件事必须由 CI 完成，人不该在评审里提这些。

典型配置：Go 项目用 gofmt + golangci-lint，Java 用 Checkstyle + SpotBugs，Node 用 ESLint + npm audit。覆盖率门槛建议加在"新增代码覆盖率"（diff coverage）上，例如新增行覆盖率不低于 80%，而不是看整体覆盖率——整体覆盖率 70% 的老项目，新增代码可以是 0% 覆盖也能过闸。

落地顺序是：pre-commit hook 跑格式化和 lint → CI 跑单测和静态扫描 → 全部绿了才进入人工评审。这一步能把人工评审里 30% 以上的机械性评论消掉。

后端评审必须盯住的关键点是什么？

结论：后端评审的重点是工具查不出、但线上会出事的六类问题。

1. 安全：SQL 拼接、越权访问（改 ID 就能看别人数据）、敏感字段写进日志、接口未做鉴权。
2. 并发：共享可变状态有没有加锁、锁的粒度是否跨了远程调用、异步任务是否幂等。
3. 事务：事务边界是否包住了远程调用（长事务会拖垮连接池）、跨服务写操作是否有补偿逻辑、事务内是否发 MQ 消息。
4. 数据库变更：DDL 是否能在线上平滑执行（MySQL 加索引用 ALGORITHM=INPLACE 或 gh-ost）、新字段是否兼容旧代码（先加字段、再双写、最后切读）。
5. 接口兼容：新增字段可加，删除字段和改类型必须走版本号或灰度。
6. 性能：循环里查数据库（N+1）、循环里调远程接口、无上限的 IN 查询和分页。

评审意见怎么写才不被当成挑刺？

结论：用前缀标注严重级别，用提问代替断言。

推荐用 Conventional Comments 的写法：blocker: 表示不改不能合，issue: 表示这是缺陷，suggestion: 表示可以不改，nit: 表示纯粹个人偏好、可忽略，question: 表示我没看懂请解释。示例：blocker: 这里的 Redis 锁没有设置过期时间，进程崩溃后会死锁。

这套前缀的价值是：作者一眼能分辨哪些必须处理，避免为了一条命名建议来回拉扯三轮。

评审节奏怎么定？

结论：第一轮反馈在 24 小时内给出，每人同时挂着的待审 PR 不超过 3 个。

超过 24 小时不给反馈会直接阻塞作者，作者只能转去做别的任务，上下文切换成本远高于评审本身。团队可以把"每日固定两个评审时间窗口（如上午 10 点和下午 4 点）"写进规范，胜过随时被打断。

评审经验怎么沉淀？

结论：同一个问题被提第三次，就该写进 lint 规则或团队文档。

每月统计一次评审意见，按类别归并。如果"日志里打了手机号"出现 5 次，就写一条静态扫描规则；如果"事务里调 RPC"出现 3 次，就写进后端开发规范文档并在新人 onboarding 里讲。评审的终点不是这行代码改对了，而是这类问题以后不再出现。

把这几点收一下：PR 控制在 200-400 行、机械检查全交给 CI、人工只看安全/并发/事务/数据兼容、意见分级标注、24 小时内响应、重复问题规则化。做到这六条，代码评审才会从流程负担变成真正的质量防线。