开始的抵触
团队刚开始做代码审查，大家都很抵触。理由很充分：
- 浪费时间，自己的活都干不完
- 被挑刺，感觉不被信任
- 拖延进度，PR 拖很久才合并
- 没有意义，小问题也要改
虽然抵触，但公司要求，只能执行。执行下来，问题就来了。
执行的问题
执行代码审查，遇到了这些问题：
问题一：没人审查
提了 PR，等了一天，没人审查。催一下，才有人看，但只是随便扫一眼，点个 approve。
原因很简单：大家都很忙，自己的活都干不完，哪有时间看别人的代码。
问题二：审查质量差
有人审查，但质量很差。只看代码格式，不看逻辑。只挑小问题，不提大问题。
真正的问题，比如逻辑错误、性能问题、安全问题，反而没人发现。
问题三：沟通不畅
审查者和作者沟通不畅。审查者提了意见，作者不回复。作者回复了，审查者又不看。
一来一回，PR 拖了很久。有时候还吵架，影响团队氛围。
改进的过程
用了一年多，我们做了这些改进：
1. 建立审查规范
定了审查规范，明确审查重点：
- 功能是否正确？
- 代码逻辑是否清晰？
- 是否有性能问题？
- 是否有安全问题？
- 测试是否充分？
这样审查者知道要看什么，不会只挑小问题。
2. 培训审查技能
做了审查培训，教大家怎么审查代码：
- 不是挑刺，而是找问题
- 不是批评，而是建议
- 不是命令，而是讨论
这样审查质量会提升，真正的问题能被发现。
3. 改善沟通方式
改善沟通方式，让审查更友好：
- 用友好的语气，不要用命令的语气
- 解释为什么，不要只说是什么
- 提供建议，不要只提问题
这样沟通更顺畅，不会吵架。
4. 建立审查文化
建立审查文化，让大家接受审查：
- 审查是学习，不是批评
- 审查是协作，不是对抗
- 审查是提升，不是阻碍
这样大家更愿意审查，审查质量会提升。
现在的状态
改进后，代码审查好了一些：
- 大家更愿意审查，不再抵触
- 审查质量提升了，真正的问题能被发现
- 沟通更顺畅，不会吵架
- 审查速度提升了，PR 能及时合并
甚至有人主动要求审查，觉得审查能帮助自己提升。
如果重新开始
如果重新建立代码审查文化，我会：
- 一开始就建立规范，不要后面改
- 做好培训，让大家知道怎么审查
- 改善沟通，让审查更友好
- 建立文化，让大家接受审查
总结
代码审查文化的建立是个长期过程，不是一蹴而就的。要慢慢培养，让大家接受。
如果你们团队也在做代码审查，建议先建立规范，再培训技能，最后建立文化。规范要明确，培训要到位，文化要培养。
另外，代码审查是团队协作的一部分，不是单方面的。审查者和作者都要配合，才能做好。