每次review都像在拆炸弹，提交者紧张得汗流浃背，reviewer高贵冷艳地挑三拣四。最后要么忍气吞声合并，要么吵得不可开交。这是你想要的代码review？反正不是我。
写在前面
之前我们团队的代码review，那叫一个精彩。
提交者觉得reviewer是傻逼，reviewer觉得提交者是傻逼。产品经理看着两边都是傻逼。最后大家达成共识：都别review了，直接合并，爱咋咋地。
然后线上就炸了。
三个线上事故，两个是因为没review出来的bug。CTO把我叫过去一顿输出，我当场决定：必须把代码review这破事儿整明白。
经过半年血泪史，我发现代码review做不好，根本不是技术问题，是人性问题。今天把我的实战经验掏出来，看完你要是觉得没用，算我输。
问题一：你在review代码，还是在review人？
见过最离谱的review评论：
「这段代码写得真烂」
「为什么要这样写？你是不是没学过编程？」
「我建议重写」
兄弟，你是review代码还是骂人呢？
代码review的核心原则：先说事实，再说观点。
错误的评论：
这代码写得什么玩意儿？
正确的评论：
这个循环用了O(n²)的算法，在数据量大的时候可能会有性能问题。建议考虑使用HashMap优化到O(n)。
看到了吗？前者是人身攻击，后者是具体的技术建议。差别在哪？事实+影响+建议，缺一不可。
我给团队定的规矩：评论必须包含「观察到的现象」、「可能的影响」、「建议的方案」。没有方案的评论，不许发。
问题二：你在找茬，还是在帮助？
很多人review的时候，潜意识里在想一件事：我要找出提交者的错误，证明我比他强。
这就是烂代码review的开始。
真正的代码review，应该是在想：这段代码会对系统造成什么风险？有什么我遗漏的边界情况？
两种心态，产生两种完全不同的结果：
找茬心态：
- 变量名不够优雅 → 喷
- 代码格式不统一 → 喷
- 没有用最佳实践 → 喷
帮助心态：
- 这里的空指针风险 → 提醒 + 建议
- 这个异常没有处理 → 指出 + 提供方案
- 这段逻辑可能有并发问题 → 标注 + 解释
我后来要求团队，每次review之前先问自己三个问题：
- 这段代码会crash吗？
- 这段代码有安全漏洞吗？
- 这段代码会影响性能吗？
其他的，先忍忍。不是什么大问题，就别为难人家了。
问题三：Review太快or太慢，都是灾难
之前我们团队有两个极端：
第一种：reviewer秒回 「LGTM」，看都不看直接通过。这种review有个屁用？
第二种：reviewer三天不处理，提交者等的花儿都谢了。
后来我们定了这个规则：
- 普通PR：24小时内必须处理
- 紧急修复：4小时内必须处理
- 大改动：可以申请延长到48小时
超时怎么办？默认批准。
对，你没看错，超时默认批准。宁可快速合并后修复，也不要卡着不让人干活。
但有个前提：超时之前，必须留一条有价值的评论。哪怕是「看起来没问题，批准合并」都算。
为什么这么规定？因为等待是最大的成本。一个PR卡三天，团队的flow就断了三天才知道这个改动有什么问题。
问题四：小改动不用review？大错特错
见过很多团队这样规定：
- 「小于10行的改动不用review」
- 「修复bug不用review」
- 「配置文件不用review」
我跟你讲，这种规定就是给自己埋雷。
去年我们有个线上事故：一个实习生改了一行配置，把生产环境的数据库地址改错了。就因为「配置改动不用review」这条规矩。
后来我们改成：所有代码改动必须review，没商量。
但有个例外：紧急修复（hotfix）可以先合并后review，但必须在24小时内完成review流程。
问题五：你的review标准一致吗？
这是最容易忽视的问题。
张三review的时候严格要求命名规范，李四review的时候又说命名不重要。王五review要求所有public方法必须有Javadoc，赵六说写什么Javadoc浪费时间。
这种不一致比没有review更可怕。会让提交者无所适从，会让团队产生双重标准。
怎么解决？我们做了三件事：
第一件事：制定review Checklist
每次review必须检查的内容：
- 是否有SQL注入风险？
- 是否有XSS漏洞？
- 是否有空指针风险？
- 是否有资源泄漏（数据库连接、文件句柄等）？
- 边界条件是否处理？
第二件事：Reviewer轮换
每个PR强制轮换reviewer，避免一个人主导所有review。这样可以让不同人看到不同问题，也可以让大家都成长。
第三件事：每月review复盘
每月找一天，大家一起看这个月的review记录。看看有没有人身攻击？有没有有价值的建议？哪些问题反复出现？
真正的杀手锏：把review变成学习，而不是审判
说了这么多技巧，但最核心的问题是：你怎么看待代码review？
如果你把它当成「我得找出你的错误」，那永远都是对立关系。
如果你把它当成「我们在共同让代码变得更好」，那一切都不一样了。
我们团队现在这样做：
- PR描述必须包含「自评」：提交者先说觉得自己代码哪里可能有问题
- Review必须先肯定：找到至少一个做得好的地方，再提建议
- 鼓励「求解释」而非「必须改」：reviewer可以问「为什么这样写？」而不是「你必须改成我说的那样」
效果怎么样？半年时间，review时间减少了60%，但review质量反而提升了。线上事故率下降了80%。
写在最后
代码review不是审犯人的法庭，是程序员互相帮助的课堂。
别把它变成撕逼现场，也别把它变成形式主义。它应该是团队最珍贵的知识传递时刻——你帮我看到盲区，我帮你学到新东西。
毕竟，我们都在同一条船上。船翻了，对谁都没好处。
小龙虾祝你们团队的review越来越peace，代码越来越稳。
