What Is the Best Code? — The Code That Does Not Exist
What Is the Best Code? — The Code That Does Not Exist
什么是最好的代码？——不存在的代码
For a few months, every code review I did ended the same way: with a deletion. Not because the code was bad. It compiled, it had tests, it had sailed through review once already. But again and again the real fix was to remove the thing entirely — the wrapper function, the defensive regex, the helper that guarded a state my own schema could never produce. 在过去的几个月里，我做的每一次代码审查都以同样的方式结束：删除。并不是因为代码写得不好。它能编译通过，有测试用例，甚至已经通过了一次审查。但事实一次又一次地证明，真正的修复方案是彻底移除它——无论是那个包装函数、防御性正则表达式，还是那个为了保护某种我的架构根本不可能产生的状态而存在的辅助函数。
And here’s what kept surprising me: the system got stronger every time. Races disappeared because there was nothing left to race. Whole classes of bugs became unrepresentable. Semantics that had been smeared across five functions became visible in one place. At some point I stopped and asked the question properly. What is the best code? The code that does not exist. 令我惊讶的是：系统每一次都变得更健壮了。竞态条件消失了，因为已经没有什么可竞争的了。整类 Bug 变得不再可能出现。原本分散在五个函数中的语义逻辑，现在一目了然。在某个时刻，我停下来认真思考了一个问题：什么是最好的代码？答案是：不存在的代码。
It has no bugs. Nobody reads it, so nobody misreads it. It needs no tests, no migration guide, no comment explaining why it’s safe. It has never paged anyone at 3am. Absent code has perfect uptime. This sounds like a fortune cookie until you take it literally. Then it becomes a design method. 它没有 Bug。没人读它，所以没人会误读它。它不需要测试，不需要迁移指南，也不需要注释来解释为什么它是安全的。它从未在凌晨三点把人从睡梦中叫醒。不存在的代码拥有完美的在线时间。这听起来像是一句鸡汤，但如果你把它当真，它就变成了一种设计方法。
It was never really about code. Say it fully and it gets bigger: The ultimate optimization of any entity is its absence. An entity is anything you could create and then have to own. A function, sure. But also a service, a table, a dependency, a feature flag, a nightly cron, a policy document, a checklist, a recurring meeting. 这从来都不只是关于代码。把它完整地说出来，意义就更深远了：任何实体的终极优化就是它的“不存在”。实体是指任何你创建后必须负责维护的东西。函数当然算，但服务、数据库表、依赖项、功能开关、定时任务、政策文档、检查清单、例会，这些也都算。
The need an entity serves — that’s the asset. The entity itself is a liability with a maintenance schedule: a surface for bugs, a thing that drifts from reality, a thing someone new has to learn exists. We spend careers optimizing entities. Cleaner code, faster queries, better-run meetings. All of that is polishing the liability. The fundamental move is ruder: ask whether the thing deserves to exist at all, and measure every cleanup not by what it beautified but by what it deleted. 实体所满足的“需求”才是资产。而实体本身则是带有维护成本的负债：它是 Bug 的温床，是会偏离现实的东西，是新人必须学习才能理解的东西。我们花费整个职业生涯去优化这些实体。更整洁的代码、更快的查询、更高效的会议。所有这些都只是在打磨负债。最根本的举措要“粗鲁”得多：问问这个东西是否真的有存在的必要，并衡量每一次清理工作——不是看它美化了什么，而是看它删除了什么。
The code half of this idea is old and in good company. Jeff Atwood wrote “the best code is no code at all” back in 2007; Gordon Bell said the cheapest, fastest, most reliable components are the ones that aren’t there. And the principle’s shadows are everywhere: YAGNI is it, projected onto the time axis — a need that isn’t a fact yet justifies nothing. KISS is it on complexity, DRY on information. The razor named after Occam distilled it seven centuries early: entia non sunt multiplicanda praeter necessitatem — entities are not to be multiplied beyond necessity. Each of these is one shadow of the same lamp, thrown on a different wall. 这个理念中关于代码的部分并不新鲜，且拥趸众多。Jeff Atwood 在 2007 年就写过“最好的代码就是没有代码”；Gordon Bell 也说过，最便宜、最快、最可靠的组件就是那些根本不存在的组件。这一原则的影子无处不在：YAGNI（你不会需要它）是它在时间轴上的投影——尚未成为事实的需求无法证明其合理性。KISS（保持简单）是它在复杂度上的体现，DRY（不要重复自己）则是它在信息层面的体现。奥卡姆剃刀在七个世纪前就提炼出了这一点：entia non sunt multiplicanda praeter necessitatem —— 如无必要，勿增实体。这些都是同一盏灯投射在不同墙面上的影子。
What’s new here is bigger and smaller at once. Bigger: it was never about code. Smaller: it compiles into a procedure an agent can actually run. 这里的新意在于，它既宏大又具体。宏大之处在于：它从来都不只是关于代码。具体之处在于：它被编译成了一套代理（Agent）可以实际执行的流程。
The Existence Ladder / 存在阶梯
A principle without a procedure is a poster. So here’s the procedure — seven rungs, every proposed entity starts at the top. And because the principle claims to work on anything, let’s climb it with a problem that has zero code in it: “Our people keep losing travel receipts, accounting drowns in reimbursements. Please write a receipts policy, a reimbursement form, and a reminder schedule for HR.” Three mechanisms requested. The actual need: receipts must not get lost, accounting must not drown. 没有流程的原则只是一张海报。所以，这里有一套流程——七个阶梯，每一个提议的实体都从顶端开始。既然这一原则声称适用于任何事物，让我们用一个完全不涉及代码的问题来演示： “员工总是弄丢差旅发票，财务部门被报销单淹没了。请写一份发票政策、一张报销单，并为人力资源部制定一个提醒时间表。” 这里请求了三种机制。而真正的需求是：发票不能丢，财务不能被淹没。
0 · Nothing. Does the entity need to exist at all? Meal receipts don’t: per-diem allowances (where tax rules allow them) need no receipts — an entire category of the problem just… leaves. 0 · 无（Nothing）。 这个实体真的有必要存在吗？餐费发票其实没必要：如果税务规则允许，直接发放每日津贴就不需要发票了——这一类问题直接消失了。
1 · Exists. Does it already exist — in this project, the stdlib, the world? Corporate travel services already push closing documents straight to accounting. Look before you build. 1 · 存在（Exists）。 它是否已经存在了——在这个项目中、标准库中，或者世界上？企业差旅服务已经可以直接将结算单推送到财务系统。在构建之前，先看看现有的。
2 · Structure. Reshape what exists so the bad state becomes unrepresentable. Everything else goes on a corporate card: a bank transaction doesn’t get lost in a jacket pocket. 2 · 结构（Structure）。 重塑现有事物，使不良状态变得无法产生。其他所有支出都通过公司信用卡支付：银行交易记录不会丢在夹克口袋里。
3 · Declaration. Tell the rule to an engine that enforces it — machines enforce, humans forget. No expense report, no next travel advance: forgetting now blocks itself. 3 · 声明（Declaration）。 将规则告诉执行引擎——机器会强制执行，而人类会遗忘。没有报销单，就无法获得下一次差旅预支：遗忘行为本身就构成了阻断。
4 · Derivation. Derivable things are never maintained by hand. The expense report assembles itself from the statement and receipt photos. 4 · 推导（Derivation）。 可推导的事物绝不应手动维护。报销单应根据银行账单和发票照片自动生成。
5 · Reaction. Respond to change automatically, only where the outside world changes. The app nags and escalates when the trip ends; HR is out of the reminder business. 5 · 响应（Reaction）。 仅在外部世界发生变化时自动响应。当行程结束时，App 会自动提醒并升级处理；人力资源部不再需要负责提醒。
6 · Orchestration. Imperative glue you own — the last resort. The requested policy, form, and schedule survive only if you genuinely can’t issue cards. 6 · 编排（Orchestration）。 你所拥有的指令性胶水代码——这是最后的手段。只有当你确实无法发放公司卡时，最初请求的政策、表格和时间表才有存在的必要。
The tally: the two-page policy became four lines in a company directive, and the form and the reminder calendar were never written. Nothing to lose, nothing to sort, nobody to remind. 总结一下：那份两页纸的政策变成了公司指令中的四行字，而表格和提醒日历根本没写。没有东西可丢，没有东西可整理，也不需要提醒任何人。
You fall one rung only when the current rung provably can’t meet the need. “Feels more natural” is not a proof — habit is not best practice. “We might need it later” is not a proof — a need is a fact, not a forecast. “The user asked for this mechanism” is not a proof — a mechanism is not the need. “Everyone does it this way” is not a proof either; common practice is half the time just the industry-standard way of living with a problem instead of removing it. 只有当当前阶梯被证明无法满足需求时，你才能降到下一级。“感觉更自然”不是证明——习惯不等于最佳实践。“我们以后可能需要”不是证明——需求是事实，而不是预测。“用户要求这个机制”不是证明——机制不等于需求。“大家都这么做”也不是证明；通常情况下，所谓的行业惯例只是人们忍受问题而非解决问题的标准方式。
Notice the first two rungs don’t ask about form at all. They ask about being — should it exist, does it exist. Most engineering starts at rung 6 and works overtime to stay there. The excuses were beautiful. 注意，前两个阶梯根本没有询问形式。它们询问的是“存在”——它应该存在吗？它已经存在了吗？大多数工程实践从第 6 级开始，并加班加点地维持在那里。那些借口听起来都很动听。