有一天下午四点，我点开了同事刚提的一个 PR, 先上代码👇：
// PR
async function handle(list) {
const list1 = []
let temp = null
const a = 1
for (let i = 0; i < list.length; i++) {
if (list[i]) {
if (list[i].status) {
if (list[i].status === 'active') {
if (list[i].type) {
if (list[i].type === 'user') {
// 在 for 里 await 查库
temp = await db.query(
'SELECT * FROM users WHERE id = ?',
[list[i].id]
)
if (temp && temp.length > 0) {
list1.push(temp[0])
}
} else {
if (a === 1) {
// 什么都不干
}
}
}
}
}
}
}
return list1
}
第一眼，还行。
第二眼，嗯？
第三眼，我开始怀疑人生。
变量叫 a、temp、list1，if-else 套了六层，在 for 里 await 查库，像一锅没加盖的乱炖。
我当时脑子里只有一个念头：
这玩意要是上线了，今晚谁都别睡😡😡😡。
但问题是——
你不能在评论区直接敲一句🤔：
这段代码太烂了，建议重写。
你可以这么想，但不能这么说。
因为你不是在写技术博客，你是在上班😖。
Code Review 本来是为了让项目更稳，结果很多时候，反而成了团队关系的坟头。
后来我慢慢意识到一件事：
你要做的，不是指出问题，而是—— 让对方愿意帮你把问题改掉。
先说个核心原则：别对人下手，先对代码下手
CR 最容易翻车的点，就一个字：你。
你这里写错了。你为什么不判空。你这逻辑不太行。
只要你用了-你，对方心里的防御盾基本就举起来了😒。
更聪明的做法，是把对象换掉。
- 换成我们
- 换成这段代码
- 换成如果这个场景
- 换成我们下次如何防范
比如：
我们这里可能要考虑一下空变量的情况。这段逻辑在并发高的时候，可能会有点风险，这个写法在数据量大的时候，性能可能撑不住的
意思一点没变，但攻击性直接砍半。 敌人是 Bug，不是你的同事😃。
一些能救命的 CR 话术（真的可以试试）
变量名随便起，看不懂
你心里想的是：
这
list1到底是个啥？
但你可以这么说：
这个
list1里装的主要是什么数据来着？
要不要换个更具体点的名字，比如activeUserList？
这样后面维护的人（包括未来的我们）会省不少事。
重点不在你命名不行，而是以后接受的人会感谢你的🤔。
if-else 套到你头皮发麻
别说逻辑太乱了。
你可以说：
这里我看了一下，逻辑稍微有点绕，我读了两遍才理顺。
要不要考虑用提前 return 的方式拆一下？
缩进少一点，后面看起来也轻松些。
先承认是我读得有点费劲，
再给建议，
最后用商量的语气收尾。
对方台阶都有了，基本不会炸。
明显的性能隐患
比如循环里查库、循环里调接口。
可以这样：
这个写法在当前数据量下应该没啥问题。
我主要有点担心，如果后面数据上来，接口时间会不会被拉长。
要不这里改成批量查或者并发一下？稳一点。
这句话的潜台词只有一个： 我是在给项目兜底🥱。
完全看不懂他在干嘛？
这时候千万别装懂。
你可以说：
这块我好像没太跟上你的思路，
能不能简单说下这里为什么要这么处理？
或者加点注释也行，我怕下次有人接手会有点懵。
很多时候，对方在解释的过程中，
自己就会发现问题。
你甚至都不用再补刀的。
顺便说一句：别做格式检查！
CR 不是让你盯着：
- 少没少空格
- 单引号还是双引号
- 换行对不对
- 有没有写注释
- 有没有加 commit 标签
你在 PR 里留 20 条这种评论，
对方只会想一件事：
这人是不是有点烦😥。
格式这种事，交给工具就完了😖。
ESLint、Prettier、Husky，甚至是AI整理代码
能解决 80% 的低级争吵。
如果真的乱到影响阅读，可以一句话带过：
这一块缩进好像有点乱，
跑一下 lint 自动修一下就行，
我们主要还是看下逻辑。
点到为止😒。
真到必须重写的时候，别在评论区硬刚
有些代码，确实已经到了不改不行的程度。
但就算这样，也别在 PR 评论区写小作文。
人多的地方，没人愿意认输。
更好的方式是：
私聊？语音？当面？
开场也别太重：
刚看了下那个 PR，有一块我有点担心，咱们对一下怎么样？
把风险讲清楚，
把后果讲明白，
共识达成了，再让他自己改。
给成年人留面子，成本真的很低的😁。
说个实在的
Code Review 从来都不是，谁技术更牛谁说了算的。你今天指出的问题， 很可能是为了防止哪天半夜两点， 把他从被窝里拽起来修 Bug。
这不是找茬，这是在剩你的时间。
所以以后 CR 的时候：
- 少一点命令
- 多一点商量
- 少一点你怎么这样？
- 多一点我们是不是可以？
代码是冷的，但一起写代码的人，最好别凉😃。
灵感来自于上面👆这本书，希望对大家有帮助😁。 也整理出来了一些想法，望大家喜欢 👉 为什么我开始减少逛技术社区，而是去读非技术的书？
