Content

YAGNI（You Aren’t Gonna Need It）是极限编程中的一条核心原则，主张不要为未来可能需要的功能提前编写代码，直到那个需求真正出现时才去实现。它基于一个现实洞察：大部分预先构建的“推测性功能”最终可能用不到，提前开发会带来构建、延迟、携带和修复等多重浪费。与 TDD 结合时，YAGNI 确保我们只做最少的事，但做得可靠；同时，它强调通过重构、测试等实践保持代码的可修改性，以便在需求来临时能灵活应对。微软的研究数据支持了这一观点：即使经过仔细规划，平均也只有约三分之一的功能能真正改善产品目标指标。

Acceptance

YoYo's Note
2026-03-21-yagni-and-tdd

Question

在做项目时，你有没有”提前做了但最后没用到”的功能？回想一下成本。
在 AI 辅助编程中，AI 特别爱过度设计，你怎么判断哪些是 AI 多加的”推测性功能”？
没有 TDD，YAGNI 是不是一句空话？
写框架时还能用 YAGNI 吗？
YAGNI 说不做，但 Spec-First Development 说先设计，听谁的？
YAGNI 真能省钱吗？那些“携带成本”算过吗？
AI 总是过度设计，YAGNI 怎么管住它？

Reference

2026-03-21 YAGNI & TDD 分析
Martin Fowler - Yagni
Ron Jeffries, Kent Beck — Extreme Programming (C3 Project, 1990s)
Kohavi et al — 微软研究：仅 ⅓ 功能改善了目标指标

YoYo’s Note

YAGNI（You Aren’t Gonna Need It）：不要为预想的未来需求写代码，直到真正需要的那一刻才写。

来自极限编程（XP），由 Kent Beck 和 Ron Jeffries 在 C3 项目中提出。

四种成本

提前构建”推测性功能”会带来：

构建成本 — 花时间做了没用的东西
延迟成本 — 这时间本可以做现在就能产生价值的东西
携带成本 — 多余代码增加复杂度，拖慢后续所有功能
修复成本 — 就算猜对了需求，6 个月后的你会用不同的方式实现

关键数据

微软研究：即使经过仔细前期分析，只有 ⅓ 功能最终改善了目标指标。⅔ 是浪费。

常见误解

YAGNI ≠ 不做设计。它只禁止”为未来需求提前写的功能代码”，不禁止重构、写测试、搭 CI——这些是让代码保持可修改性的工作，没有它们 YAGNI 就是灾难。

YAGNI 的悖论：它既被进化式设计所启用，也启用了进化式设计。

Answer

没有 TDD，YAGNI 是不是一句空话？
是的，如果没有 TDD（提供测试保护）和持续重构（保持代码可修改性），YAGNI 会因代码僵化而无法响应未来真实需求，从而变成一种诅咒。它们共同构成“安全地做最少之事”的实践基础。

写框架时还能用 YAGNI 吗？
可以，但需区分“战略性的接口设计”与“推测性的功能实现”。为应对变化的扩展点（如插件架构）进行设计是必要的，但实现具体的、未被要求的插件则违反 YAGNI。关键在于设计可扩展的接口，而非填充实现。

YAGNI 🌱 Seed