也许我们不应该审查所有代码

梯形图转SCL | 自然语言生成梯形图 | 自然语言生成SCL | 梯形图在线查看 | 博途编程文档MCP | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace

最近，我在Code Remix上与DX的Brian Houck一起参加了一个小组讨论，由Moderne主办。这是我参加过的更有趣的小组讨论之一，主要是因为我们意见不合。正如我的同事Martin Fowler所说，当人们意见不合且双方都有充分的论据时，小组讨论会有趣得多。Brian和我确实如此。

Brian后来写了一篇深思熟虑的文章，题为《代码审查到底是为了什么？》。他显然对自己的立场充满热情，而我对我自己的立场也充满热情，所以我写了这篇回应。需要明确的是，我认为我们大多想要相同的东西。我只是不认为代码审查是实现它们的最佳方式。顺便说一句，Brian很可爱，他鼓励我写这篇文章。但如果我说我不想让你在最后认为我是对的，那我就是在撒谎。

那么我们在争论什么呢？

AI正在产出比人类实际能够审查的更多的代码。Brian引用了一些相当惊人的数字：据报道，在Meta，每个 landed diff 的重要代码行数在一年内增加了106%，而DX自己的数据显示中位拉取请求大小增加了64%。

他的担忧，也是我的担忧，是简单地自动化代码审查会让我们失去我们使用它的所有其他用途。代码审查不仅仅是发现错误。它是团队分享知识、指导初级工程师、建立集体所有权和传播架构理解的方式。

我的问题是：为什么我们要等到代码审查才做所有这些事情？

我从来不喜欢将拉取请求作为软件开发过程的中心。并不是因为工程师不应该查看彼此的代码，而是因为我一直难以接受这样的想法：我们应该构建一些东西，完成它，将其打包，抛给其他人，然后才进行关于我们是否以正确的方式构建了正确的东西的重要对话。

更不用说合并冲突了。我已经在上面浪费了太多时间。

1、将判断左移

我在Thoughtworks很早就学到的原则之一是缩短反馈循环。如果反馈有价值，就不要移除它。将它移近它所支持的决策。

拿我们说代码审查给我们的东西来说。

如果我们想探索替代解决方案，我宁愿在实现其中一个之前就做这件事。

如果我们想知识传递，结对编程。与某人坐在一起，无论是物理上还是虚拟上，当他们推理问题时，这比事后阅读他们的完整解决方案教你更多。

如果我们想让初级工程师学习资深工程师如何思考，让他们在资深工程师思考时与他们一起工作。结对编程再次浮现在脑海中，但团队也可以在编写（或指示代理编写）任何内容之前，集体进行设计会议，使用白板。

如果我们想集体所有权，组织团队，让人们真正共同构建和运营软件，而不是依靠拉取请求来告诉每个人其他人已经构建了什么。为此，再次使用结对编程、群体编程或团队设计会议，围绕白板。

如果我们想架构对齐，一起设计（我不重复结对编程和团队设计会议了，哦等等……），然后将重要约束编码为适应度函数。

如果我们审查代码的格式、代码检查、已知安全问题或可以确定性测试的内容，请自动化它们。我们真的不应该在2026年还在争论空格问题。

结对编程、基于主干的开发、自动化测试、静态分析、适应度函数和安全扫描都将反馈提前。代理越来越多地参与这些循环，挑战设计、测试假设并持续验证正在构建的内容，但真正的思考来自经验丰富的人类，如果我们希望这种经验惠及整个团队，那么我们必须在代码审查之前更早地表现得像一个团队。

2、按例外审查

这并不意味着没有人审查代码。绝对有一些变更我希望另一个经验丰富的人查看。一个例子是根本性的架构变更。假设我们作为一个更广泛的团队进行了设计会议，我们可能希望作为团队审查代码或同意它被正确实现，或者讨论我们是否想更改任何内容。其他例子可能涉及敏感安全边界、影响范围巨大的变更、关键系统的不熟悉部分，或者团队说"我对这个没有信心"的简单事情。

这些正是人类判断有价值的地方，但这与要求人类检查每个变更非常不同，因为那是我们历史上用来建立信心的仪式。

我们现在知道继续走这条路是不可行的，这就是为什么代码审查一直作为一个问题或障碍出现。如果代理可以产出十倍的代码，但每一行最终都排队等待高级工程师检查，我们并没有创建一个十倍的工程组织，我们创建了一个大的积压和新的瓶颈。

我不认为答案是AI代理假装是人类审查者，以便我们可以在更高速度上保留完全相同的流程。这是在自动化仪式，而不是质疑仪式为什么存在。

然而，Brian的论点中有一件事让我担心。他谈到团队积累认知和意图债务：软件在增长，而负责它的人对其工作方式的理解越来越少。我认为这是一个非常现实的问题。我只是不认为强制性拉取请求是抵御它的特别有力的防御。

如果代理将产出更多的实现，我们需要更加谨慎地通过协作设计、结对编程、良好的边界、可执行架构、共享操作责任以及可能一些我们尚未发明的实践来维护人类理解。

我们需要工程师理解系统，而不是差异。

也许这正是AI所暴露的。我们多年来将大量的职责加载到了不起眼的代码审查上：质量门、安全检查、架构审查、指导机制、知识共享系统、所有权模型。

当人类只能以这样的速度产出代码时，它是有效的。那个限制正在消失。所以也许问题不是我们如何更快地获得代码审查。也许是我们为什么等到代码审查才进行所有重要的对话。

原文链接：Maybe We Shouldn't Be Reviewing All This Code

汇智网翻译整理，转载请标明出处