Reviewing code requires reading
Reviewing code requires reading
Reviewing code requires reading 代码审查需要阅读
2026.06.04 :: 3 min :: #ai #culture 2026.06.04 :: 3 分钟 :: #ai #culture
On Lobste.rs I have found today the article written by the Charity Majors - CTO of the Honeycomb.io “AI enthusiasts are in a race against time, AI skeptics are in a race against entropy”. This was pretty good read until there was this question posed: 今天我在 Lobste.rs 上读到了 Honeycomb.io 的 CTO Charity Majors 写的一篇文章《AI 狂热者在与时间赛跑，AI 怀疑论者在与熵增赛跑》。这篇文章读起来很不错，直到文中提出了这样一个问题：
What would it take for you to feel comfortable shipping code to production without reading it? “要达到什么条件，你才会觉得在不阅读代码的情况下将其发布到生产环境是安全的？”
Her proposed solutions were: Better evals? Better tests? Better feature flags, guardrails, observability? Work on decoupling dependencies and reducing blast radius? Start with something small and out of the critical path? What is the work we need to do to prepare? What comes first, ordering-wise? Can we put that on the roadmap? 她提出的解决方案包括：更好的评估？更好的测试？更好的功能开关、护栏和可观测性？致力于解耦依赖并减小影响范围？从非关键路径的小功能开始？我们需要做哪些准备工作？按顺序来说，什么最优先？我们能把它加入路线图吗？
But that is completely missing a point. The point of doing review is to diffuse responsibility. No one want to be the sole person responsible for the downtime of the system. No one want to be the sole person responsible for security issues. No one want to be responsible for accidental data removal. And the sole purpose of reviews is to remove that burden form single individual and instead make it team responsibility. That way, the blame is “spread” among writer and all reviewers. 但这些完全偏离了重点。代码审查的意义在于分散责任。没有人愿意独自为系统的宕机负责，没有人愿意独自为安全问题负责，也没有人愿意为意外的数据删除负责。代码审查的唯一目的，就是将这种负担从个人身上移除，转而成为团队的共同责任。这样一来，责任就“分摊”给了代码编写者和所有审查者。
If someone wants to remove that group responsibility and instead tell you to “approve without reading” then why ask me to push the button manually at all? If you want to pay someone for pushing a button without thinking then there you are, here is a button for them to click: Push me! You probably have JavaScript disabled. Don’t worry, there is probably nothing interesting except some dumb jokes. 如果有人想取消这种集体责任，反而让你“不看代码就批准”，那为什么还要让我手动去点那个按钮呢？如果你想花钱雇人盲目地按按钮，那给你准备好了，点这里就行：按我！你可能禁用了 JavaScript。别担心，除了几个无聊的笑话，这里大概没什么有趣的。
This is demo of my upcoming SaaS - button roulette, which will merge random PR assigned to you that has all CI green. Perfect for “AI enthusiastic” CTOs. 这是我即将推出的 SaaS 产品“按钮轮盘赌”的演示，它会自动合并分配给你且 CI 全部通过的随机 PR。非常适合那些“AI 狂热”的 CTO 们。
Another reason why we do reviews is to learn codebase. In many projects the codebase is too big to be constantly aware of all parts of the system. The review is to force more people to have a look into different parts, to reduce bus factor, increase familiarity of the team with different parts, to teach new team members about codebase and code culture. 我们进行代码审查的另一个原因是学习代码库。在许多项目中，代码库规模太大，以至于无法时刻了解系统的所有部分。审查是为了强迫更多人去查看不同的模块，从而降低“巴士系数”（bus factor），增加团队对各部分的熟悉程度，并向新成员传授代码库知识和代码文化。
If we force everyone to “approve without reading”, then we lose all that. That way it not only increase the bus factor to 1, but also externalise it to 3rd party. 如果我们强迫每个人“不看代码就批准”，那么我们就失去了这一切。这样做不仅会将巴士系数降至 1，还会将其风险外包给第三方。
So to answer Charity’s question: 所以，回答 Charity 的问题：
What would it take for you to feel comfortable shipping code to production without reading it? “要达到什么条件，你才会觉得在不阅读代码的情况下将其发布到生产环境是安全的？”
My answer is: Written waiver of responsibility in case of bugs, security issues, downtime, etc. written by the person that issued such statement. 我的回答是：由提出该要求的人签署一份书面免责声明，承担因代码导致的 Bug、安全问题、宕机等一切后果。
If I am forced to “feel comfortable shipping unread code to production”, then I also want to feel secure from any consequences of such action. Simple as that, but I highly doubt that I will get such waiver from anyone. 如果我被迫“觉得在不阅读代码的情况下发布到生产环境是安全的”，那么我也希望自己能免受此类行为带来的任何后果。道理就这么简单，但我非常怀疑是否有人会给我签这份免责声明。