Code Review 的艺术：如何优雅地告诉同事“你的代码是一坨...需要优化”？（附 CheckList）

🤬 前言：CR 不是“吐槽大会”

在开源社区，Linus Torvalds 可以直接喷：“What the f**k is this?” 但在公司里，你如果这么说，HR 明天就会找你谈话。

Code Review 的本质目标只有两个：

1. 提高代码质量（发现 Bug、统一风格）。
2. 知识共享（让更多人懂这块业务，防止单点故障）。

它是**“我们 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++加注释）。
• 测试用例：新功能有对应的单元测试吗？测试覆盖率达标了吗？

💔 四、 遇到“死猪不怕开水烫”怎么办？

如果同事回复：“我就不想改，能跑就行，你管得着吗？”

1. 引用规范：拿出团队统一制定的《开发规范文档》，告诉他“这不是我的规定，是团队的规定”。
2. 拉人仲裁：如果僵持不下，拉上一位更资深的架构师或 Leader 介入。
3. 数据说话：“如果你不改这个循环，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 一遍，看看能发现多少问题？