代码审查这事儿，代码我见过太多团队把它搞成了一场“找茬游戏”。审查代码写得像天书，代码reviewer硬着头皮看，审查最后只揪出几个缩进问题，代码核心逻辑漏洞全漏过去了。审查要我说，代码代码审查的审查本质不是“挑错”，而是代码“降低认知负担”——让下一个读代码的人（包括三个月后的你自己）能轻松理解这段逻辑。

我团队里有个规矩：提交的审查PR必须附带一段“设计意图说明”，不超过三句话。代码比如“这里用缓存是审查因为数据库查询太慢，但缓存失效策略选了TTL，代码因为业务容忍最多5秒的审查延迟”。没这个说明，代码reviewer只能靠猜。猜的过程就是浪费生命。有一次新人没写，我硬是花了二十分钟从代码注释里拼凑出他为什么这么写——最后发现他自己也记不清了。这种审查纯粹是浪费时间。

真正的审查流程，第一步不是看代码，而是看“变更范围”。一个PR改了十几个文件，涉及三个模块，那基本没法审。合理做法是让作者自己拆分成小PR，每个PR只解决一个问题。我见过最夸张的一次，有人把数据库迁移、接口重构和bug修复混在一个PR里，reviewer看了半小时就放弃了，直接点了个“通过”。结果上线后出了事故，追责时才发现问题出在没人仔细看的那部分。

第二步才是逐行看逻辑，但别用“这里可以优化”这种模糊说法。要指出具体场景——比如“当用户并发点击提交按钮时，这段代码会产生重复订单。建议加个分布式锁，或者至少用数据库唯一索引兜底”。抽象的建议都是废话，具体的场景才是价值。我常用的句式是：“如果XX发生，这段代码会怎样？”逼作者自己推演边界情况。

还有个小技巧：审查时把代码跑起来，而不是光看静态文本。肉眼看不到的并发问题、资源泄漏，一跑就现形。有次我审查一个文件上传功能，静态看逻辑没问题，但实际测试时发现大文件会内存溢出——因为作者用了readAllBytes()。这种问题靠眼睛看，永远发现不了。

最后，审查语气比内容更重要。写“这段代码写错了”和“这里可能有隐患，帮我确认下”效果完全不同。前者让人防御，后者让人思考。我见过最糟的审查意见是：“这写的什么玩意儿？”——毫无信息量，纯情绪发泄。好的reviewer会说：“我担心这个循环在极端情况下会死循环，你能加个保护条件吗？”

说真的，代码审查做得好的团队，不是因为他们水平高，而是因为他们肯花时间把“为什么”讲清楚。审查不是流程，是沟通。你写下的每条评论，都是在帮未来的同事省时间——包括那个总爱写烂代码的自己。