程序员如何做「代码审查流程」：不是形式，是质量门禁
代码审查是软件质量的重要保障。
但很多团队的 CR 只是走形式：合并了就行，没人在意质量。
一、代码审查的目的
1. 发现 Bug
审查能发现测试没发现的问题。
2. 保证质量
代码风格、设计、架构的一致性。
3. 分享知识
团队成员互相学习，共同进步。
4. 知识传承
让团队知道每个人在做什什么。
二、代码审查的流程
1. 开发阶段
- 本地跑测试
- 自 review（换位思考：如果你是 reviewer，你会怎么看）
- commit 不要太大（一次审查不超过 400 行）
2. 创建 PR
- 写好 PR 描述（做什么、为什么、怎么测）
- 指定 reviewer
- 关联 issue
3. Review 阶段
- reviewer 尽快响应（不要让对方等几天）
- 先看整体设计，再看细节
- 提建议，不是命令
4. 修改阶段
- 根据反馈修改
- 回复每条评论（已修改 / 不同意要解释）
- 标记已解决
5. 合并阶段
- CI 通过
- 至少 1 个 approval
- 没有未解决的讨论
三、Reviewer 的职责
1. 看什么
- 功能是否正确
- 设计是否合理
- 代码是否清晰
- 是否有测试
- 是否有安全漏洞
2. 怎么说
- 先肯定，再提建议
- 问问题，不做假设
- 区分重要和非重要
3. 多久响应
- 24 小时内响应
- 不要积压
四、作者的职责
1. 准备 PR
- 控制大小
- 写好描述
- 自 review 一遍
2. 回应反馈
- 不要防御
- 解释设计选择
- 标记已修改
3. 保持沟通
- 主动推进
- 有问题及时同步
五、常见的错误
❌ Review 只是走形式
"反正有人过了就行"——没有意义。
❌ PR 太大
500 行代码 reviewer 看不完。
❌ 不回应反馈
提了建议但没下文。
❌ 审查时间太长
等 3 天才能审查 = 开发节奏被打断。
六、一句话总结
代码审查流程 = 开发阶段准备 + PR 清晰 + 快速响应 + 认真反馈 + 及时合并。