代码质量不是靠 Review 喊出来的

很多团队一说代码质量，第一反应就是加强 Code Review。

这话当然没错。Review 很重要。

但如果一个团队平时没有质量标准，需求又赶，设计也没对齐，测试用例也不完整，最后指望 Review 把所有问题都看出来，这就有点像菜都炒糊了，再指望装盘的时候补救。

能救一点，但救不了根。

Code Review 最容易变成一种仪式。

提交一个 MR，几个人点进去看两眼，挑几个命名，问一句“这里为什么这样写”，最后点通过。流程走完了，但质量不一定真的变好了。

我后来越来越觉得，Review 不应该只是最后一道门。

如果需求理解、方案设计、测试边界前面都没说清楚，最后靠 Review 去拦所有问题，基本拦不住，也会把团队关系搞得很紧张。

一、Review 不是最后一道安检

Code Review 最容易变成一种礼貌流程。

提交人发起合并请求，别人看几眼，留两个小建议：“这里命名改一下”“这个空行删掉”。然后点通过。

不是大家不认真，而是很多问题在 Review 阶段已经太晚了。

比如模块边界错了，数据模型不合适，异常流程漏了，权限判断绕开了原有体系。这些问题不是看几行代码就能轻松发现的。

如果需求和方案阶段没有讨论，Review 时再发现，改动成本会很高。

所以 Review 不能孤立存在。它前面要有设计对齐，后面要有测试验证。

二、团队需要一套说得出来的标准

“代码写好一点”是没法执行的。

什么叫好？

不同人理解不一样。有人觉得抽象清楚叫好，有人觉得简单直接叫好；有人喜欢封装，有人讨厌过度设计；有人重视性能，有人重视可读性。

团队需要把一些基本标准说出来。

比如：

业务规则不要散落在多个接口里。
重要状态变更必须有日志。
外部接口调用必须有超时和错误处理。
数据库查询不能在循环里反复打。
涉及权限的接口必须有统一校验。
核心流程要有最小测试覆盖。

这些标准不一定一开始就很完整，但要能被团队反复使用。

否则每次 Review 都像重新讨论价值观。

三、质量问题很多是节奏问题

代码质量差，常常不是某个人不想写好，而是节奏逼出来的。

需求临时插进来，排期又不变；上一个问题刚修完，下一个版本马上开始；线上有个紧急缺陷，先改了再说。

一次两次可以理解。

但如果团队长期靠“先上线再补”，最后就会形成一种默认习惯：质量可以以后再说。

问题是，以后通常不会来。

技术负责人要做的，不是每次都站出来喊“大家注意质量”，而是要在节奏上给质量留位置。

比如关键功能上线前必须留联调和回归时间。比如重构不能永远排在最后。比如技术债要进入任务池，而不是只存在某个人心里。

四、技术债要能被看见

技术债最麻烦的地方，是它平时不吵。

它不像线上故障会报警，也不像需求延期会被追问。它安静地躺在代码里，直到某一天新需求来了，所有人突然发现这里改不动。

这时候再说“早知道当初不要这么写”，已经没什么用。

我更倾向于把技术债写出来。

不用一开始就做复杂系统，简单一点也行：

技术债：订单状态判断散落在 5 个地方。
影响：新增售后流程时容易漏改。
建议：下次改订单流程时收敛到统一状态服务。

写出来以后，它才有机会被排进计划。

没写出来的债，基本都会变成未来某次加班。

五、Review 更像团队学习机制

好的 Review 不只是挑错。

它应该让团队形成共同理解。

为什么这里不要直接查库？为什么这个异常要向上抛？为什么这个字段不能随便复用？为什么这个接口要保持幂等？

这些讨论如果只是负责人单向批改，效果有限。

更好的状态是团队成员逐渐能用同样的标准看代码。

到了这个阶段，Review 的价值就不只是减少 bug，而是让团队的工程判断慢慢对齐。

六、小结

代码质量不是靠 Review 喊出来的。

Review 是重要环节，但它不是万能补救工具。

真正的质量来自更前面的设计对齐、更明确的团队标准、更合理的交付节奏，以及能被看见和处理的技术债。

如果团队每次都在最后一刻靠 Review 抢救质量，那说明问题不在 Review，而在整个交付链路太晚才开始关心质量。

本系列：