> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 也许我们不应该审查所有代码 - URL: https://www.hubwiz.com/blog/maybe-we-should-not-review-all-these-codes/ - Published: 2026-09-23T16:04:42.000Z - Updated: 2026-09-23T16:04:42.000Z - Description: 或者，也许问题不在于AI破坏了代码审查，也许是我们一直在用代码审查来解决错误的问题 - Author: admin - Tags: INDUSTRY, #Import 2026-10-14 14:41 最近，我在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](https://martinfowler.com/rachels-ramblings/code-review.html?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处