代码审查需要认真阅读代码

# Hauleth的博客 - 代码审查需要真正阅读代码 来源：https://hauleth.dev/post/review-requires-reading/ 今天在 Lobste.rs (https://lobste.rs/) 上，我看到了一篇由 Honeycomb.io CTO Charity Majors 撰写的文章——["AI爱好者在与时间赛跑，AI怀疑者在与熵赛跑"](https://charitydotwtf.substack.com/p/ai-enthusiasts-are-in-a-race-against)。文章读起来相当不错，直到出现了这样一个问题： > 怎样才能让你安心地把没读过的代码发布到生产环境？ 她给出的解决方案是： > 更好的评估体系？更好的测试？更好的功能开关、护栏机制、可观测性？着力解耦依赖、缩小影响范围？从不在关键路径上的小事开始？我们需要做哪些准备工作？优先级怎么排？能否把这些列入路线图？ 但这完全没有抓住要点。代码审查的真正目的在于[分散责任](https://en.wikipedia.org/wiki/Diffusion_of_responsibility)。没有人想单独承担系统宕机的责任，没有人想单独承担安全漏洞的责任，没有人想独自背负意外删除数据的责任。代码审查的核心意义就在于将这份重担从个人身上卸下，转化为*团队责任*。如此一来，"责任"便由代码作者和所有审查者共同承担。 如果有人想取消这种集体责任，转而让你"不读代码就批准"，那还有什么必要让我手动按下那个按钮呢？如果你想花钱雇人不假思索地按按钮，那好，这里有个按钮让他们点： --- 这是我即将推出的 SaaS 产品的演示——"按钮轮盘"，它会随机合并分配给你的、所有 CI 检查都已通过的 PR。专为"AI热情派"CTO量身打造。 --- 我们做代码审查的另一个原因是*了解代码库*。在很多项目中，代码库规模庞大，任何人都很难时刻掌握系统的每一个部分。审查机制会促使更多人关注系统的不同模块，从而降低[巴士因子](https://en.wikipedia.org/wiki/Bus_factor)，提升团队对各部分的熟悉程度，也帮助新成员了解代码库和代码文化。 如果强迫所有人"不读就批准"，这一切都将付之东流。这不仅会把巴士因子推高至1，还会[将其外包给第三方](https://www.independent.co.uk/tech/claude-down-not-working-anthropic-ai-b2987749.html)。 --- 所以，针对 Charity 的那个问题： > 怎样才能让你安心地把没读过的代码发布到生产环境？ 我的回答是： > 由提出该主张的人书面签署一份免责声明，内容涵盖因此产生的 bug、安全问题、服务宕机等一切后果。 如果非要让我"安心地把未经阅读的代码发布到生产环境"，那我也希望能免于承担任何相应后果。就这么简单——但我高度怀疑，不会有任何人愿意给我签这份声明。 ∎