代码 Review 的正确方式

代码 Review 的正确方式

Review 代码不只是找 Bug，更是在问一个问题：这段代码，六个月后的你还能看懂吗？

我做过很多次 Code Review，发现大多数问题不是"代码跑不起来"，而是"代码跑起来了，但没人敢改"。

变量名：第一道关

data、temp、item 这类名字在写的时候省了几秒钟，在维护的时候浪费的是几十分钟。花一秒钟想一个准确的名字，是对未来自己最好的投资。

看一个对比：

// 不好的命名
const data = users.filter(x => x.a > 18);
const res = data.map(x => x.n);

// 好的命名
const adultUsers = users.filter(user => user.age > 18);
const adultUserNames = adultUsers.map(user => user.name);

第二段代码不需要任何注释，读起来就像一句话："筛选出成年用户，然后取出他们的名字。"

函数长度：第二道关

一个函数如果超过五十行，通常意味着它在做不止一件事。拆开它，给每个部分一个清晰的名字，代码结构就自然清楚了。

判断一个函数是不是太长，有一个简单的方法：试着用一句话概括这个函数做了什么。如果你需要用"然后"、"同时"、"另外"这些连接词，说明它做的事情太多了。

注释的时机

不要注释"做什么"——代码本身应该说清楚。要注释"为什么"——这个决定背后的原因，代码里看不出来。

// 不好的注释：解释做了什么（代码本身已经说明了）
// 遍历用户列表并过滤掉未激活的用户
const activeUsers = users.filter(user => user.isActive);

// 好的注释：解释为什么这么做
// 未激活用户的数据可能不完整（注册流程中断），
// 参与统计会导致平均值偏低
const activeUsers = users.filter(user => user.isActive);

AI 时代，Review 更重要了

用 AI 生成代码之后，Review 的习惯更重要了。AI 写得很快，但它不了解你的项目背景。最终要读这段代码的，还是人。

我见过太多这样的情况：AI 生成了一段"能跑"的代码，开发者看了一眼觉得没问题就合并了。三个月后需要改这个功能，打开代码一看——完全不知道当时为什么这么写。

AI 生成的代码需要额外关注这些方面：

• 过度工程：AI 喜欢写得很"完整"，但你可能不需要那么多边界情况处理
• 风格不一致：AI 每次生成的代码风格可能不同，需要统一
• 依赖引入：AI 可能会引入你不需要的库或者过时的 API
• 安全问题：AI 不会主动考虑 XSS、SQL 注入等安全问题

Review 的心态

最后说说心态。Review 不是挑毛病，是帮团队（或者未来的自己）省时间。

好的 Review 应该是建设性的。不要只说"这样写不好"，要说"可以考虑这样改，因为……"。给出理由，才能让对方真正理解，下次不再犯同样的问题。

如果你是被 Review 的一方，收到修改建议时不要觉得被否定了。每一条 Review 意见都是一次免费的学习机会，抓住它。