🤬 前言：CR 不是“吐槽大会”
在开源社区，Linus Torvalds 可以直接喷：“What the f**k is this?” 但在公司里，你如果这么说，HR 明天就会找你谈话。
Code Review 的本质目标只有两个：
- 提高代码质量（发现 Bug、统一风格）。
- 知识共享（让更多人懂这块业务，防止单点故障）。
它是**“我们 vs Bug”，而不是“我 vs 你”**。
🧠 一、 心法篇：优雅喷人的三个原则
1. 对事不对人 (Talk about Code, not You)
- ❌错误示范：“你这里写错了，你怎么没做空指针判断？”（攻击性强，对方会防御）
- ✅优雅示范：“这段代码在
user为空时可能会抛出异常，我们是不是加个判空更稳妥？”（把“你”换成“我们”或“代码”）
2. 区分“建议”与“必须” (Nitpick vs Blocking)
不要让你的个人喜好阻碍代码合并。
- Blocking (必须改)：逻辑错误、安全漏洞、严重性能问题。
- Nitpick (建议/吹毛求疵)：变量名不够完美、换行位置不好看。
- 技巧：对于非原则性问题，前缀加上
[nit](Nitpick)，表示“我觉得这样更好，但你不改我也给你过”。
3. 给出方案，而不只是问题
- ❌错误示范：“这块写得太烂了，性能很差。”
- ✅优雅示范：“这里用了双层循环，在数据量大时可能会超时。建议使用
Map做一次预处理，将复杂度从 O(N^2) 降到 O(N)。”
⚙️ 二、 流程篇：建立标准的 CR 管道
不要把所有压力都放在人工 CR 上。机器能做的，绝不让人做。
高效 CR 流程图 (Mermaid):
关键点：
- Lint 工具（ESLint, Pylint, Checkstyle）必须集成在 CI 里。如果只是缩进不对，CI 直接挂掉，别浪费同事的时间去肉眼看缩进。
📝 三、 实战篇：通用 Code Review CheckList
复制这份清单，贴在你们团队的 Wiki 里，每次 CR 对照检查。
1. 🛡️ 安全性 (Security)
- 输入校验：所有的 API 参数是否都做了长度、类型、特殊字符校验？
- SQL 注入：是否使用了预编译（PreparedStatement）？有没有直接拼接 SQL？
- 敏感数据：日志里有没有打印密码、Token、手机号？
- 权限控制：水平越权/垂直越权检查，A 用户能不能删 B 用户的数据？
2. 🏗️ 架构与设计 (Architecture)
- 复用性：这几十行代码是不是在别的地方见过？能否提取成公共方法？
- 单一职责：一个函数是不是写了 200 行？是否同时负责了“读库”、“计算”和“发邮件”？
- 硬编码：URL、Token、魔法数字（Magic Number）是否提取到了配置或常量中？
3. 🚀 性能 (Performance)
- 循环数据库查询：有没有在
for循环里调用 SQL？（N+1 问题）。 - 大对象：有没有一次性把整张表加载到内存里？
- 锁竞争：并发场景下，这个
synchronized或Lock会不会导致死锁或严重阻塞？
4. 📖 可读性 (Readability)
- 命名：变量名是
data,list,temp这种无意义的名字吗？能做到“见名知意”吗？ - 注释：复杂的算法逻辑有注释吗？（注：好的代码本身就是注释，不要给
i++加注释）。 - 测试用例：新功能有对应的单元测试吗？测试覆盖率达标了吗？
💔 四、 遇到“死猪不怕开水烫”怎么办？
如果同事回复：“我就不想改，能跑就行，你管得着吗？”
- 引用规范：拿出团队统一制定的《开发规范文档》，告诉他“这不是我的规定，是团队的规定”。
- 拉人仲裁：如果僵持不下，拉上一位更资深的架构师或 Leader 介入。
- 数据说话：“如果你不改这个循环，QPS 超过 100 时 CPU 会飙升到 90%。”
🎯 总结
Code Review 是程序员精进技术的最佳捷径。
作为 Reviewer（审查者），你的职责是把关和教学。
作为 Author（提交者），请收起你的 Ego（自我），把每一次 Comment 当作免费的私教课。
一句万能的 CR 结束语：
“LGTM! (Looks Good To Me) Just a few nits above.”
（整体很棒！上面只有几个小建议。）
Next Step:
今天就开始！把你最近的一次 Pull Request 找出来，用上面的 CheckList 自己先 Review 一遍，看看能发现多少问题？
