代码审查的要求
团队定了规矩，所有代码都要经过至少一个人审查才能合并。听起来很合理，能保证代码质量。
但实际执行下来，问题就来了。
问题一：没人看
最明显的问题是没人看。提了 PR，等了一天，没人审查。催一下，才有人看，但只是随便扫一眼，点个 approve。
原因很简单：大家都很忙，自己的活都干不完，哪有时间看别人的代码。而且看代码很费时间，一个 PR 要看 10-20 分钟，一天看几个 PR，时间就没了。
问题二：挑刺
有人看，但专门挑刺。变量名不对、注释不够、格式不对，各种小问题都要改。
不是说这些问题不重要，但有些问题真的没必要。比如变量名，userName 和 user_name 有什么区别？但有人就是要改。
更烦的是，改了一个问题，又提出新问题。改来改去，PR 拖了一个星期才合并。
问题三：拖延
有些 PR，审查意见提了，但作者不回复。等了一天，催一下，才回复。回复了，审查者又不看。一来一回，PR 拖了很久。
有些 PR，审查者提了意见，作者改了，但审查者不重新审查。等作者催，才看。看了，又提新意见。循环往复，没完没了。
问题四：审查质量
即使有人审查，审查质量也不高。大部分审查都是：
- 看代码格式，不看逻辑
- 看变量名，不看功能
- 看注释，不看实现
- 提小问题，不提大问题
真正的问题，比如逻辑错误、性能问题、安全问题，反而没人发现。
我们的改进
用了一年多，我们做了这些改进：
1. 审查清单
定了审查清单，审查者按清单检查：
- 功能是否正确？
- 代码逻辑是否清晰？
- 是否有性能问题？
- 是否有安全问题？
- 测试是否充分？
这样审查者知道要看什么，不会只挑小问题。
2. 审查时间限制
定了审查时间限制，PR 提交后 24 小时内必须审查。如果没人审查，自动分配给其他人。
这样不会拖太久，PR 能及时合并。
3. 审查轮换
审查任务轮换，每个人都要审查，不能总让一个人审查。
这样大家都有审查经验，审查质量会提升。
4. 审查培训
做了审查培训，教大家怎么审查代码。不是挑刺，而是找问题。
这样审查质量会提升，真正的问题能被发现。
现在的状态
改进后，代码审查好了一些：
- 审查时间缩短了，大部分 PR 24 小时内能合并
- 审查质量提升了，真正的问题能被发现
- 审查氛围改善了，大家更愿意审查
但还是有问题，比如审查者不够、审查质量不稳定等。这些问题还在改进中。
如果重新开始
如果重新建立代码审查流程，我会：
- 一开始就定好审查规则，不要后面改
- 做好审查培训，让大家知道怎么审查
- 建立审查文化，让大家重视审查
- 用工具辅助，比如自动化检查
总结
代码审查很重要，但执行起来很难。没人看、挑刺、拖延、质量不高，都是常见问题。
如果你们团队也在做代码审查，建议先定好规则，再执行。规则要明确，执行要严格，不然很容易变成形式主义。
另外，代码审查是团队协作的一部分，不是单方面的。审查者和作者都要配合，才能做好。