或许我们不该审查所有代码
Maybe We Shouldn't Be Reviewing All This Code
最近我和 Brian Houck 在 Code Remix 的 panel 上发生了激烈争论。随着 AI 生成代码的速度远超人类审查能力，Meta 和 DX 的数据都显示代码审查正成为瓶颈。Brian 担心自动化会让我们失去知识共享和架构对齐的机会，但我认为问题在于我们一直把太多责任压在了代码审查这个环节上。我们是否应该把判断左移？通过结对编程、团队设计会议和自动化测试，在编码前就解决架构分歧和知识传递。代码审查不应是万能的仪式，而应只在关键变更时介入。我们需要工程师理解系统本身，而不是盯着 diff。
我们需要工程师理解系统，而不是理解 diff。
HN 评论区
77- Arainach
这种做法无法规模化。
偶尔进行结对编程确实价值巨大。我很乐意随时与人面对面交流，一起过他们的代码，头脑风暴设计方案，或者一起用调试器排查问题。
但如果你要求我一天 8 小时里大部分时间都这么干——更别提长期如此——那我辞职的速度绝对比你填完离职手续还要快。时刻有人盯着你的肩膀，那种压力和过度刺激，我（我想很多人也）绝对无法忍受。
- wgreenberg
我觉得这真是讽刺得可笑：一篇抨击同行评审的文章，配图竟然是 AI 生成的，而且一眼就能看出问题（笔记本里的内容倒过来了，一个孩子正要用剪刀割到手，另一个孩子则在搭一个几何上根本不可能存在的“乐高”结构）。要是发布前能有人审一眼就好了！
- singpolyma3
> 如果我们想探索替代方案，我宁愿在实现之前做这件事。
听起来很美好。但除非你至少动手实现了一个方案，否则你根本不知道它们到底是什么。你可以写规格说明书、开无数次会议，持续好几年，却依然会漏掉某个根本性的问题，而这个问题往往在动手构建的第一个小时里就会暴露出来。
- humbleharbinger
刚开始我还以为是 Fowler 发的，结果其实是 CTO 本人。听着，如果“不审查代码”真的行得通，我相信我们会看到初创公司和新公司把它推到极致。
我自己就在一家初创公司，我们会审慎地决定哪些代码需要审查，哪些不需要。我们的核心系统都会经过代码审查——毕竟，共识总是在早期就建立起来的。
- ramshanker
到了这个阶段，我甚至还没读过我开源项目里 30% 的代码库。我是靠手动测试来了解我们工作的。AI 一直在自己给自己写测试用例，哪怕我并没有明确要求它这么做，我也并不抱怨。