或许我们不该审查所有代码

# 也许我们不该审查所有代码 来源：https://martinfowler.com/rachels-ramblings/code-review.html **简而言之** *或者，问题可能不在于AI破坏了代码评审，而在于我们一直用代码评审来解决错误的问题* 最近我在 Moderne 举办的 Code Remix 活动上，与来自 DX 的 Brian Houck 共同参与了一个讨论组。这是我参与过的最有趣的讨论之一，主要因为我们意见相左。正如我的同事 Martin Fowler 所说，当参与者意见分歧且各方论据充分时，讨论组会有趣得多。Brian 和我显然就是这样。 Brian 随后写了一篇深思熟虑的文章《代码评审究竟为了什么？》(https://newsletter.getdx.com/p/what-are-code-reviews-even-for)。他显然对自己的立场充满热情，而我也同样坚持自己的观点，因此写下这篇回应。需要明确的是，我认为我们追求的目标基本一致，只是不认为代码评审是实现这些目标的最佳方式。顺便说一句，Brian 很棒，正是他鼓励我写下这篇回应。但如果我说不想让你在最后认同我的观点，那一定是在撒谎:)。 那么我们究竟在争论什么？ AI 正在产出人类无法现实审阅的大量代码。Brian 引用了一些惊人的数据：据报告，Meta 一个人工合并的代码变更中，重要代码行数在一年内增长了 106%；而 DX 自身的数据显示，中等规模的拉取请求大小增加了 64%。 他的担忧（我也有同感）是：仅仅通过自动化取消代码评审，可能会失去我们依赖它实现的其他所有功能。代码评审不仅仅是发现缺陷——它是团队传递知识、培养初级工程师、建立集体所有权和传播架构理解的方式。 我的问题是：**为什么我们要等到代码评审才去做这些事？** 我一直不太喜欢将拉取请求作为软件开发流程的核心。并非因为工程师不该查看彼此的代码，而是我始终难以认同这样一种观念：我们应该先构建、完成、打包，然后扔给别人，*接着*才开始关于“我们是否用正确方式构建了正确产品”的重要讨论。 更别提合并冲突了——我浪费了太多人生hours在上面。 ## **将判断左移** 我在 Thoughtworks 早期学到的原则之一是缩短反馈循环。如果反馈有价值，就不要取消它，而是让它更接近所支持的决策。 拿我们赋予代码评审的那些功能来说： 如果想**探索替代方案**，我宁愿在实现之前就进行探讨。 如果想**传递知识**，结对工作吧。与同事并肩协作（无论物理或虚拟），观察其推理问题的过程，比事后阅读完成的解决方案学到的多得多。 如果想让**初级工程师学习资深工程师的思维方式**，就在他们思考时让其与资深工程师共事。这里又想到了结对编程，但团队也可以在编写任何代码（或指示智能体编写）之前，通过白板进行集体设计讨论。 如果想**建立集体所有权**，就组织团队，让人们真正共同构建和运维软件，而非依赖拉取请求来告知他人某人已完成的工作。这里同样可以运用结对编程、群体编程或围绕白板的团队设计会议。 如果想**对齐架构**，就一起设计（关于结对和团队设计会议我不再赘述，哦等等...）然后将重要约束编码为适应度函数。 至于代码格式化、代码检查、已知安全问题或可通过确定性测试的项目，就让它们自动化吧。我们实在不该在2026年还在为缩进空格争论不休。 结对编程、基于主干的开发、自动化测试、静态分析、适应度函数和安全扫描都能将反馈前移。智能体也越来越多地参与这些循环，挑战设计、检验假设并持续验证构建内容，但真正的思考来自经验丰富的人类。如果我们希望这些经验惠及整个团队，就必须在代码评审之前更早地像团队一样运作。 ## **按例外情况评审** 这并不是说永远不需要评审代码。绝对有些变更需要另一位资深工程师查看。例如根本性架构变更。假设我们已作为更大团队进行了设计会议，可能需要以团队形式评审代码，或确认实现是否正确，或讨论是否需要改动。其他例子包括跨越敏感安全边界的变更、影响范围巨大的改动、关键系统的陌生部分，或团队明确表示“对这个没把握”的情况。 这些正是人类判断力有价值的地方，但这与要求人类检查每个变更有着本质区别——后者只是我们历来用以建立信心的仪式。 现在我们知道这条路不可持续，因此代码评审才会不断成为问题或阻碍。如果智能体能产出十倍代码，但每一行最终都要排队等待资深工程师检查，那我们并非创建了十倍效率的工程团队，而是制造了大量积压工作和新的瓶颈。 我不认为答案是让AI智能体伪装成人类评审员，从而以更高速度维持完全相同的流程。这只是将仪式自动化，而非质疑仪式存在的必要性。 不过Brian的论述中有一点让我担忧。他提到团队积累“认知负债”与“意图负债”：软件不断发展，但负责它的人类对其运作原理的理解却越来越少。我认为这是非常现实的问题。只是不认为强制性的拉取请求是应对此问题的有效防御手段。 如果智能体将产出大部分实现内容，我们需要更审慎地通过协作设计、结对编程、良好边界、可执行架构、共享运维责任（可能还包括尚未发明的实践）来维护人类的理解。 **我们需要工程师理解系统，而非差异。** 也许这正是AI所揭示的问题。多年来，我们将异常多的责任强加于朴素的代码评审之上：质量关卡、安全检查、架构评审、指导机制、知识共享系统、所有权模型。 在人类只能有限产出代码的时代，这种方式尚可运作。但这种限制正在消失。因此，问题或许不在于如何更快完成代码评审，而在于为什么我们要等到代码评审时才进行所有重要对话。