代码评审的文化：从挑错到共建

很多团队的代码评审形同虚设：要么走个过场无脑通过，要么变成资深工程师的个人秀。问题不在流程，在文化。

评审的目的是什么#

先把目标说清楚：评审不是为了"证明代码没问题"，而是三件更实际的事——

• 知识流动：让至少另一个人理解这段代码为什么这么写；
• 集体所有权：打破"这代码只有作者能改"的 bus factor；
• 早期反馈：设计层面的问题在合并前修正，成本最低。

好的评审意见长什么样#

对比一下：

这里写得不好，应该用 map。

和：

这里用 for 循环处理了映射，如果改用 map 语义会更直接，也方便后续做链式过滤。你觉得呢？

前一句是判断，后一句是建议 + 理由 + 留出讨论空间。评审意见指向代码，永远不要指向人。

规模控制在 400 行以内#

研究数据和个人经验一致：单次评审超过 400 行 diff，发现缺陷的效率断崖式下跌。大改动请拆分：

1. 先发一个"纯结构"的 PR（重命名、抽函数，不改行为）；
2. 再发业务逻辑的 PR，这时候 diff 已经很小；
3. 复杂算法单独出设计文档，不要指望评审者在 diff 里读懂你的架构。

工具只是载体#

模板、checklist、自动化检查都很好，但它们只能兜底格式问题。真正让评审有价值的，是团队对"代码是共同资产"这件事的共识。