李纪

AI 产品 · 游戏开发

YAGNI（You Ain't Gonna Need It）— 你不会需要它的

YAGNI 是极限编程（Extreme Programming, XP）的核心原则之一：永远不要为"以后可能会用到"的功能写代码，只在当前需求真正需要时才实现。

由 Kent Beck 在其 XP 方法论中系统化提出，与 KISS（Keep It Simple, Stupid）、DRY（Don't Repeat Yourself）并称软件工程三大原则。

核心思想

YAGNI 反对预测性设计（anticipatory design）——即程序员基于对未来的猜测而提前添加功能：

| 思维模式 | 做法 | 结果 | |---------|------|------| | 预测性设计 | "以后可能会需要一个通用缓存层，先建好" | 80% 的抽象从未被使用 | | YAGNI | "只在需要缓存时再建缓存" | 代码量少、复杂度低、易维护 |

YAGNI 的底层逻辑：

  • 预测未来通常是错的——你猜的需求多半不会发生，或者发生时形态完全不同
  • 未使用的代码是纯负债——阅读成本、编译成本、测试成本、重构时的迁移成本
  • 延迟决策更优——在真正需要时做决策，信息更多、设计更准
  • 代码越少，Bug 越少——每行代码都是潜在的 Bug 点

与 Ponytail 的关系

Ponytail 是将 YAGNI 原则系统化引入 AI 编码 Agent 的工具。它在 AI 写代码前强加一把决策梯子：

1. 这东西需要存在吗？   → 不需要就删掉（YAGNI）
2. 标准库能不能做？     → 用它
3. 平台原生功能？       → 用它（如 <input type="date">）
4. 已安装的依赖？       → 用它
5. 一行能搞定？         → 写一行
6. 以上都不行，才写最简实现

基准测试（vs 无规则 baseline）：

  • 代码量 -54%
  • Token 消耗 -22%
  • 成本 -20%
  • 耗时 -27%
  • 安全 100%

与相近原则的对比

| 原则 | 含义 | 区别 | |------|------|------| | YAGNI | 不做还不需要的 | 聚焦"不做什么" | | KISS | 保持简单 | 聚焦"怎么做简单" | | DRY | 不重复自己 | 聚焦"抽象复用" | | Occam's Razor | 如无必要勿增实体 | 哲学层面的简约原则 |

常见误区

❌ "YAGNI 就是不写测试"

YAGNI 不砍测试、错误处理、安全、可访问性。这些是当前必须的，不是"以后可能需要的"。

❌ "YAGNI 会导致难以重构"

恰恰相反。YAGNI 减少未使用代码，让重构时的受影响的代码更少。真正导致重构困难的是过度耦合的抽象。

❌ "框架本身就有很多抽象，这不违反 YAGNI 吗？"

框架是当前选择的依赖——它提供的能力是"已付款"的，使用已有依赖不是违反 YAGNI。违反的是自己额外封装一层。

实践建议

  1. 写代码前问"这行代码解决当前什么问题？"——答不上来就别写
  2. 区分"现在需要的抽象"和"可能需要的抽象"——前者来自重复代码，后者来自想象
  3. 先写内联实现，等重复三次再提取抽象——Rule of Three
  4. 用 Ponytail 类工具约束 AI Agent 的过度构建倾向
  5. 代码审查时留意 gold plating（镀金）——无需求的泛化和灵活性预留

参考