程序员如何做「代码评审」：不是挑刺，是学习
Code Review 是程序员之间最重要的协作方式之一。
做得好能提升代码质量、传播知识、做朋友；做不好就是走过场、引发矛盾。
一、Code Review 的目的
1. 提升代码质量
- 发现 bug
- 发现安全隐患
- 发现性能问题
2. 知识共享
- 团队成员互相了解代码
- 新人能快速熟悉项目
- 减少单点依赖
3. 保持一致性
- 代码风格一致
- 设计思路一致
- 架构规范一致
4. 相互学习
- 学习别人的思路
- 学习新的技术
- 不同的视角碰撞
二、评审者怎么做
1. 先理解代码
- 这段代码是做什么的
- 背景是什么
- 不要上来就挑刺
2. 关注重点
必须看的：
- 逻辑是否正确
- 边界条件
- 错误处理
- 安全问题
建议看的：
- 代码风格
- 命名规范
- 注释完整性
可以不看的：
- 格式化细节（交给 IDE/linter）
3. 反馈要有建设性
❌ 不好："这段代码很烂"
✅ 好："这里可能会 NPE，建议加个空判断"
❌ 不好："为什么要这样写？"
✅ 好："这里我有个疑问，这样写的原因是？"
4. 区分优先级
- blocker：必须改的，影响功能或安全
- suggestion：建议改，能提升代码质量
- nit：可选改，细节优化
三、被评审者怎么做
1. 控制 PR 大小
- 一次 PR 不要超过 400 行
- 每次只改一件事
- 大功能拆成多个小 PR
2. 写好 PR 描述
- 这个 PR 做什么
- 为什么做
- 怎么测试的
- 截图或动图（如果有 UI 变化）
3. 响应反馈
- 及时回复 review
- 有问题就讨论，不要沉默
- 感谢 feedback
四、常见错误
❌ 评审太严格
格式化、命名风格纠结半天，忽略核心问题。
❌ 评审太随意
"看起来没问题"——没有真正看代码。
❌ PR 太大
一次性 review 1000+ 行，没人能认真看完。
❌ 不响应
feedback 提了，开发者不回也不改。
❌ 把 PR 当作批评
被提了意见就觉得被攻击——review 是对代码，不是对人。
五、一句话总结
Code Review = 理解代码 + 关注重点 + 建设性反馈 + 区分优先级，核心是提升代码质量和相互学习。