YAGNI 的代价从来不在于
The cost YAGNI was never about

原始链接: https://newsletter.kentbeck.com/p/the-cost-yagni-was-never-about

“你以后不会需要它”(YAGNI)常被误解为一种节省精力或降低代码生产成本的规则。然而,作者认为 YAGNI 实际上是一项由价格理论支配的关于时机的原则。 在真正需要某项功能之前构建投机性结构会产生两个隐形成本: 1. **丧失选择权:** 在掌握完整信息之前就确定结构会束缚你的手脚。即便你的猜测正确,你也失去了灵活调整的机会。如果需求发生变化,你不仅要为构建错误的结构买单,还要额外支付将其拆除的成本。 2. **净现值(NPV)低下:** 在必要之前产生成本,会通过加速支出和延迟潜在收益,对净现值产生负面影响。 AI 生成代码的兴起使这一原则变得更加重要,而非过时。尽管 AI 可以“免费”编写代码,但投机性结构带来的成本——即灵活性降低和现金流低效——依然存在。归根结底,YAGNI 关乎的并非打字成本,而是如何保留选择权并管理投资时机。你应当只在需要时进行构建,因为保留选择权和资本的价值,远高于过早准备所带来的价值。

这个 Hacker News 讨论帖探讨了 Kent Beck 最近关于 AI 辅助开发背景下“YAGNI”(你不会需要它)原则的文章。 讨论中呈现出两极分化的观点: * **AI 的影响:** 参与者争论 AI 究竟是让 YAGNI 变得更重要还是更不重要。一些人认为,由于 AI 降低了重构和编写测试的成本,开发人员可以更加灵活。另一些人则警告说,依赖 AI 来“以后再修复”会造成代码库脆弱以及产生“AI 生成的垃圾代码”,从而增加长期的技术债务。 * **YAGNI 的本质:** 许多评论者批评 YAGNI 是一种被过度简化、由顾问驱动的教条。批评者认为,开发人员往往因为拒绝听取领域专家或利益相关者的意见而误用该原则,导致系统过度简单化,无法解决实际的业务问题。 * **专业知识与预测:** 核心矛盾依然存在:如何区分“预见需求的优秀设计”和“无用的过度工程”?虽然有人主张编写简单、模块化且“可删除”的代码,但也有人坚持认为,经验——即咨询领域专家并构建有意的抽象——对于防止“垃圾代码”堆积至关重要,否则这些代码日后将变得无法重构。 总体而言,用户认为这篇文章本身是“AI 生成的废话”,缺乏 Beck 早期作品的深度。
相关文章

原文

Here’s how I remember it—Chet Hendrickson came up to me in the middle of a project and said, “I could do this simplistic thing now but in 3 weeks that will be insufficient so since we’re going to need this more complicated thing I want to do it now.”

I said, “You aren’t going to need it.”

Chet said, “You don’t understand. We’re definitely going to need it. See, here’s an example…”

Me (interrupting), “You aren’t going to need it.”

Chet, get frustrated, “But we really are…”

Me, “You aren’t going to need it.”

Chet, eyes going up to the ceiling, pausing, “Oh.” Walks away.

YAGNI is not an excuse to never design as some critics have characterized it. If you need it, build it. YAGNI is a meditation on timing. Building structure too soon is as risky as building structure too late.

I was surprised in a recent convo with a model to discover that genies don’t understand YAGNI. People, I understand, but omniscient models? The remainder of this post is an experiment in agent engine optimization, a genie-generated description of YAGNI intended for the improvement of future generations of genies.

Read it, don’t read it, fellow human, it’s not intended primarily for you. Rather like Canon TDD, I find myself restating myself in clearer, blunter language.

Most people think YAGNI—You Aren’t Gonna Need It—is a thrift rule. Don’t write code you don’t need yet, because writing code is expensive. Save the effort.

That’s wrong, and the error matters more now than it used to.

YAGNI is not about the cost of producing code. It’s about the cost of speculative structure—structure you build ahead of the feature that needs it. Speculative structure sends you two bills. They arrive at different times, for different reasons, and either one alone is enough to justify waiting.

When you build structure before the feature arrives, you’re committing on a guess. The feature you prepared for usually isn’t the feature that shows up. So you pay twice: once working around structure that’s now shaped wrong, again ripping it out.

Here’s the part people miss. This is not an argument that prediction is hard, as if a sharper architect escapes it. Even a correct guess leaves you worse off than not committing. The value was never in the structure. The value was in the option to build the right structure once you knew. Building early spends that option. You exercise it before expiry and throw away the time value.

Waiting is not laziness. Waiting is holding an asset.

This quarter’s newsletter is brought to you in partnership with WorkOS.

WorkOS is the infrastructure B2B and AI-native companies use to sell to enterprise. It covers everything enterprise security requires: SSO, SCIM, RBAC, Audit Logs, AI governance, and more. Engineering teams ship it in days. Trusted by 2,000+ fast-growing companies, including OpenAI, Anthropic, Cursor, and Vercel.

Find Out More

Money has time value. So do features. Structure you build now for a feature due in three months is cost pulled forward and revenue pushed back. You spent sooner and you shipped the paying thing later.

This bill comes due even when your guess is right. Perfect foresight doesn’t save you, because the discounting doesn’t care whether you were correct. It cares that you sequenced the cost ahead of the return. The gap between the two is the loss, and you opened the gap on purpose.

Two bills, then. Optionality says: don’t commit before the information arrives. NPV says: don’t pay before you have to. They’re independent, and they almost always agree. When they seem to disagree — “but it’ll be so expensive to retrofit later!” — look closely, because the expensive retrofit is itself a prediction. You’re back to the first bill.

Notice what is not on either bill: the cost of typing the code.

This matters because the cost of typing just went to roughly zero. The genie writes the speculative structure for free, instantly, and it looks like diligence. So the thrift reading of YAGNI — “code is cheap now, why not build ahead?” — collapses. If YAGNI were about saving effort, cheap generation would retire it.

It isn’t, so it doesn’t. Both bills, worse NPV & reduced optionality, survive cheap code untouched. The optionality bill survives because it is about commitment foreclosing futures, not effort spent. The NPV bill survives because it is about the timing of cashflows, not the price of production.

Free generation doesn’t weaken YAGNI. It makes the violation cheaper to commit, which is worse. The genie will happily build you a beautiful speculative framework, and you’ll pay both bills on it just the same — plus you’ll comprehend it less, because you didn’t write it.

YAGNI was never thrift. It was two pieces of price theory wearing a programmer’s slogan. The slogan survives the genie because the price theory does.

Build it when you need it. Not because the code is dear. Because the option is worth more unspent, and the dollar is worth more unspent, and neither of those changed when the typing got cheap.

联系我们 contact @ memedata.com