外观
我怎么看 Code Review 这件事
约 1247 字
我怎么看 Code Review 这件事
工作头两年，我最怕两件事：写 bug 和被人看代码。 提 PR 前反复自查，review 意见一红一片，脸上火辣辣。
后来带团队、读别人代码、被大佬 review 多了， 想法完全变了：Code Review 是我经历过最高密度的 成长方式，没有之一。 这篇说说这个转变。
一、先破除心魔：被 review ≠ 被审判
新人的典型内心戏：
「这段写得这么烂，别人会不会觉得我水？」
「提这么多意见，是不是对我有意见？」
「这个错太低级了，暴露水平……」这些戏，一半是自己加的，一半是团队文化造的。 真相：
- review 意见针对代码，不针对你（健康的团队）；
- 能看出问题说明审查者在认真看（没人理的 PR 才该慌）；
- 你眼里的「低级错误」，八成别人也犯过 —— 只是他们不说了。
转换点：把「我又被挑出毛病」换成 「又免费上了一课」。同样的意见，两种心态， 收获差十倍。
二、提 PR 前的自查（省大家时间）
被 review 出「console.log 没删」这种， 双方都尴尬。提之前跑一遍：
□ git diff 自己读一遍（真的读，不是扫）
□ 调试代码清了吗（console.log、debugger、注释块）
□ 测试跑了吗（新增功能有没有测试）
□ 改动范围超了吗（一个 PR 干一件事，别顺带重构）
□ commit 信息看得懂吗（fix: 修什么，不是 update）
□ PR 描述写了吗（改了什么、为什么、怎么验证的）「diff 自己读一遍」这条最值 —— 我的 PR 里 一半低级问题是这么拦下来的。你觉得「就这么点改动」， 读一遍往往能看出三个没想到。
三、PR 大小原则
400 行有效改动是上限。 超了拆。
❌ 一个 PR：重构 + 新功能 + 升级依赖 + 改样式
→ review 的人划水点 approve，真 bug 混进去没人发现
✅ 三个 PR：重构（纯搬砖）/ 新功能 / 升级
→ 每个都审得细，合得快，回滚容易「小步快跑」在 review 环节的回报最大 —— PR 的大小，决定 review 的质量，决定 bug 漏进去的概率。
四、给别人 review：认真是美德
我 review 别人时守的规矩：
- 24 小时内响应（团队约定）—— PR 挂三天，提的人早换任务了，上下文全丢；
- 对事不对人：说「这个循环在数据量大时会慢」， 不说「你这写的是什么」；
- 给方案不给指示：「考虑过用 reduce 吗？ 我觉得可读性更好」—— 商量，不是下令；
- 区分 blocking 和 nit：
[blocking]逻辑问题必须改，[nit]风格建议可不改 —— 别拿小毛病卡合并； - 看不懂就问，别猜：「这段没懂，能讲讲思路吗？」 —— 常常一问，作者自己发现想岔了；
- 该夸就夸：「这个抽象漂亮」「这个测试想到 这个边界了牛」—— review 不是找错大会。
最贵的 review 意见不是「这错了」，是「为什么」 —— 「为什么用 X 不用 Y」这类问题，常常问出 作者没想到的坑，也常常让 review 者学到东西。
五、从 review 中学什么（比技术更重要）
被 review 三年，我学到最多的不是「某个 API」：
- 看问题的角度：大神一眼看出「这个边界条件」、 「这里并发有问题」—— 视角的差距比知识大；
- 代码的品味：什么是「能跑」和「写好」的差距， 看多了自然有感觉；
- 沟通的方式：怎么把「你错了」说得让人接受 —— 这是软技能，代码 review 是最好的训练场；
- 系统的理解：review 别人的模块， 被迫理解整个系统的运作 —— 比只看自己一亩三分地 成长快。
六、团队没有 review 怎么办
不是每个团队都有这文化。自救：
- 主动要：「这个改动你有空帮我看眼吗？」 —— 请同事喝杯咖啡的事；
- 换形式：正式 PR 太重的团队， 结对编程、口头过一遍、「写完喊一嗓子」都算；
- 开源社区练：给开源项目提 PR （参与开源指南（在新窗口打开））—— 陌生人的 review 更狠，成长更快；
- 自我 review：没人的时候， 「隔天自己 review 自己的 PR」—— diff 放一夜，第二天带着陌生感读， 能看出昨晚看不见的问题。
七、写在最后
现在我把「有人给我提一堆意见」当作福利 —— 免费的高级工程师一对一，上哪找？
代码是写给人看的，顺便能在机器上跑。 Review 就是「给人看」这道工序的质检。 怕它的人，进步慢；用它的人，半年顶三年。
（下一篇聊聊文档执念 —— 和 review 一样，都是「给人看」的手艺。）