代码评审时要盯住的五件事

引言

代码评审（Code Review）很容易流于形式：扫两眼语法、挑几个空格，然后点"通过"。真正有价值的评审，关注的是那些上线后才会爆炸、但此刻就能看出苗头的问题。

下面五件事，是评审时性价比最高的关注点。

一、先看读不读得懂，再看写没写对

评审顺序建议是：命名 → 结构 → 逻辑 → 细节。

先问自己一句：不看注释，这段代码在做什么？ 如果函数名是 handleData、变量叫 temp2、一个函数里有三层嵌套的条件判断，那可读性问题比任何 bug 都优先——因为读不懂的代码，没人敢改，bug 也就永远修不掉。

具体看三个点：

• 命名是否名副其实：看到 getUserList 却返回的是 Map，就是欺骗
• 函数是否只做一件事：一个函数超过一屏，通常可以这样问："它能拆成两步吗？"
• 注释是否在解释"为什么"：解释"这行在循环"是废话，解释"为什么必须重试三次"才是价值

二、边界条件与异常路径

新手写的是"正常流程"，老手写的是"例外情况"。评审要替作者补上没有想到的分支：

尤其要盯资金、库存、权限这三类逻辑——它们的错误代价远高于普通功能。

三、变更的影响半径

很多人只 review 新写的部分，忘了问一句：这次改动会波及谁？

• 改了公共函数签名，有多少调用方？
• 改了数据库字段，历史数据怎么处理？
• 改了配置项，默认值会不会影响现有部署？
• 删掉的导出符号，别的模块还在用吗？

建议做法：评审时对照 diff 搜一遍关键符号的引用，成本很低，收益极高。

四、有没有引入可观测性问题

功能上线之后，出问题能不能快速定位？三个最低要求：

1. 关键路径有日志：尤其是外部调用、异常分支
2. 日志带了上下文：请求 ID、用户标识、关键参数（注意脱敏）
3. 失败有明确错误码：别让调用方只能对着"系统错误"四个字猜

见过太多次：线上报错，日志里只有"处理失败"。这种评审时不把关，出事时就要通宵。

五、改动是否能变小

如果一次评审要读 2000 行 diff，基本等于没有评审——人的注意力在这规模下已经失效。

遇到巨型改动，建议直接要求拆分：

• 重构与业务逻辑分开提：重构单独一个 PR，业务改动单独一个
• 格式化与设计变动分开：否则 diff 里全是噪音
• 能分批上线就分批：大爆炸式发布是事故温床

提意见的方式同样重要

同样一个问题，说法不同效果天差地别：

• ❌ "这样写不对" → 作者不知道为什么，也不知道怎么改
• ✅ "这里如果入参为空会 NPE，建议加个默认值或提前返回"
• ✅ "这段逻辑我理解是想 X，是否可以直接用现成的 Y 方法？"
• ✅ "建议 / 可选 / 必须 明确区分"，别把所有意见都写成 blocking

区分建议等级是高效评审的关键：把"风格偏好"标为 nit，把"会炸的问题"标为必须改，作者的注意力才不会被稀释。

结语

好的代码评审，不是证明自己比作者聪明，而是一起把明天可能出问题的地方提前挡掉。

记住优先级：可读性是地基，边界条件是护栏，影响半径是视野，可观测性是保险丝。这四样盯住了，剩下的风格之争，其实都不重要。