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

TL;DR 或者，也许问题不是人工智能破坏了代码审查，也许是我们一直在使用代码审查来解决错误的问题。我最近在由 Moderne 主办的 Code Remix 上与来自 DX 的 Brian Houck 一起参加了一个小组讨论。这是我做过的最有趣的小组之一，主要是因为我们不同意。正如我的同事马丁·福勒（Martin Fowler）所说，当人们意见不一致且双方都有充分的争论时，小组讨论会更有趣。布莱恩和我确实做到了。此后，布莱恩写了一篇深思熟虑的文章，名为“代码审查的目的是什么？”他显然对他的立场充满热情，而我对我的立场也充满热情，所以我写了这篇回应。需要明确的是，我认为我们大多想要相同的东西。我只是不认为代码审查是获得它们的最佳方式。顺便说一句，布莱恩很可爱，他鼓励我写这篇文章。但如果我说我不想让你认为我最后是对的，那我就是在撒谎:)那么我们在什么方面存在分歧呢？人工智能生成的代码数量超出了人类实际查看的数量。 Brian 引用了一些相当惊人的数字：据报道，在 Meta 上，每个人为差异的重要代码行在一年内增加了 106%，而 DX 自己的数据显示拉取请求大小中位数增加了 64%。他的担忧（我也同意）是，简单地自动化代码审查可能会导致我们失去所有其他用途。代码审查不仅仅是发现错误。这是团队分享知识、教授初级工程师、建立集体所有权和传播架构理解的方式。我的问题是：为什么我们要等到代码审查才做所有这些事情？我从来没有特别喜欢将拉取请求作为软件开发过程的中心。不是因为工程师不应该查看彼此的代码，而是因为我一直在思考我们应该构建一些东西，完成它，打包它，把它交给其他人，然后就我们是否以正确的方式构建正确的东西进行重要的对话。甚至不让我开始讨论合并冲突。我已经失去了太多的生命时间。左移判断 我很早就在 Thoughtworks 学到的原则之一是缩短反馈循环。如果反馈有价值，请勿将其删除。将其移近它所通知的决策。以我们所说的代码审查给我们带来的东西为例。如果我们想探索替代解决方案，我宁愿在实施其中之一之前这样做。如果我们想要知识转移，就配对。坐在某人旁边，无论是物理上的还是虚拟的，当他们推理问题时，你学到的东西远比事后阅读他们完整的解决方案要多。如果我们希望初级工程师了解经验丰富的工程师如何思考，就让他们在思考时与经验丰富的工程师一起工作。这里再次想到配对，但团队也可以在编写（或指示代理编写）任何内容之前使用白板集体进行设计会议。如果我们想要集体所有权，请组织团队，以便人们实际上集体构建和操作软件，而不是依靠拉取请求来告诉每个人其他人已经构建了什么。为此，再次使用配对、群体编程或围绕白板的团队设计会议。如果我们想要架构对齐，请一起设计（我不会重复有关配对和团队设计会议的内容，哦等等……），然后将重要的约束编码为适应度函数。如果我们正在审查代码的格式、检查、已知安全问题或可以确定性测试的内容，请将其自动化。到了 2026 年，我们真的不应该还在争论空白。结对编程、基于主干的开发、自动化测试、静态分析、健身功能和安全扫描都将反馈提前。代理也越来越多地参与这些循环，挑战设计、测试假设并不断验证正在构建的内容，但真正的想法来自经验丰富的人，如果我们希望这种经验使整个团队受益，那么我们必须比代码审查更早地采取行动。通过例外进行审查这并不意味着没有人审查代码。我想要另一个有经验的人来看待，这绝对是有变化的。一个例子是根本性的架构变化。假设我们作为一个更广泛的团队进行了设计会议，我们可能希望作为一个团队审查代码或同意其实施正确，或者讨论我们是否想要更改任何内容。其他例子可能是跨越敏感安全边界的事情、具有巨大爆炸半径的变化、关键系统的不熟悉的部分或者只是团队说的“我对此没有信心”的事情。这些正是人类判断有价值的地方，但这与要求人类检查每一个变化有很大不同，因为这是我们历史上用来建立信心的仪式。我们现在知道继续沿着这条路走下去是不可行的，因此代码审查不断成为一个问题或障碍。如果一个代理人可以生产十个