为什么你的代码 review 总是流于形式

代码 review（Code Review）是程序员最常见的活动之一。但大多数团队的 CR 都是走形式：

• "LGTM"（Looks Good To Me）
• 打个 ✓
• 不看 diff 直接 approve

这篇文章说说我见过的 CR 问题，以及怎么改进。

一、为什么 CR 流于形式

1. 时间压力

"这个 PR 赶紧 merge，还有下一个需求等着"——这是最常见的理由。

但"节省"的 10 分钟 CR 时间，可能换来未来 2 小时的 debug 时间。

2. 不知道怎么 review

很多人 review 只看"代码能不能跑"，不看不跑也能发现的问题：

• 命名不规范
• 函数太长
• 没有测试
• 逻辑有漏洞

3. 反馈太泛

"代码写得好"、"逻辑清晰"——这种反馈没有意义。

二、好的 CR 应该怎么做

1. 先问目的

在 review 之前，先问自己：这个 PR 在解决什么问题？理解目的才能判断实现是否合理。

2. 检查清单

✅ 代码逻辑是否正确
✅ 命名是否清晰
✅ 函数是否过长（>50行考虑拆分）
✅ 是否有测试
✅ 是否有文档（新增接口需要）
✅ 边界情况是否处理
✅ 有没有安全隐患

3. 具体反馈

❌ "这段代码写得不好" ✅ "这个函数超过 80 行，建议拆分，把验证逻辑抽成一个函数"

三、团队 CR 文化

1. 作者：减少 review 成本

• PR 不要太大（< 400 行）
• 写清楚 description（解决什么问题）
• 自我检查后再提 PR

2. reviewer：认真负责

• 分配时间认真看
• 问"这段代码为什么这样写"
• 提出"更好的做法"（不是"错的"，是"可以更好"）

四、一句话总结

CR 是团队最重要的知识传递方式，不是走形式。

标签: 代码审查, Code Review, 团队协作, 程序员, 开发流程