[讨论] 在代理时代重新思考代码审查和测试

目的 目前看来，由 AI 生成的大量 PR 已经成为一种常态。SQL 查询引擎是一个高度结构化的机器，其输出可以从给定的输入中预测。我认为我们可以构建一个测试框架，使每个由 AI 生成的代码更改都可以在测试机上运行，并且我们对这些更改的发布具有很高的信心。最近的一个例子是 https://GitHub.com/apache/datafusion/pull/23738，其中 @Xuanwo 提交了 4500 多行代码差异。我相信这种趋势将继续下去，为我们提供了一个机会来审查我们在代理时代如何进行代码审查。 # 运行测试框架后我们期望的结果 * 正确性 * 没有性能回退 * 清晰的 crate 分离（逻辑计划内容不进入物理层，反之亦然） 优秀的 crate 设计，以便明确地确定责任，而不是造成混乱。 # 我们目前拥有的内容 * 正确性 - sqllogictest / datafusion-fuzzer * 性能 - 基准测试机器 * 文档，以告诉 AI 每个 crate 或组件的用途 # 缺口 * 正确性覆盖 我认为我们需要更多的正确性测试覆盖，以便在更改通过测试后，我们可以高度信心地发布代码（例如，在复杂的逻辑中捕获无声的语义错误，而不单纯依赖手动测试编写）。 * 代理的基准测试 我想更多地进行基准测试覆盖，这些基准测试易于在本地运行和重现（假设大多数贡献者在笔记本电脑上运行基准测试），并且具有成本效益的基准测试机器。 * 架构和系统设计 应由审阅人员（人）仔细审查。我们可能需要工具来帮助我们轻松了解更改是否符合我们的系统设计，或者我们可能需要详细的规范来告诉 AI 遵循每个组件的用途 # 目标 此讨论的目的是收集关于代理时代代码审查如何进行的想法，以及我们需要实现目标的缺口。我希望有一天我们可以在没有经过人工仔细审阅的情况下发布大量 PR，但代码具有高质量。