YAGNI：你不会需要它

YAGNI 是 “You Ain't Gonna Need It” 的缩写，常译为“你不会需要它”。它来自极限编程（Extreme Programming，XP），核心意思是，只有当功能真的成为当前需求时，才实现它。

这个原则针对的是一种很常见的冲动。开发者看到未来可能出现的需求，于是提前增加配置项、抽象层、插件机制、通用数据结构或多个数据库适配器。代码因此变得更长，当前任务却没有得到更多能力。

YAGNI 反对什么

YAGNI 反对投机性功能，也就是为了一个尚未确认的需求，提前把功能做进产品。这样的功能通常会带来几笔确定的成本。

它需要被实现、测试、记录和维护。它会增加用户界面、配置和文档的复杂度，也会限制未来真正需求的设计空间。等需求终于出现时，早期猜出的接口和数据模型还可能与实际情况不合适，之前的工作就变成了迁移负担。

Wikipedia 对 YAGNI 的介绍把它和 XP 中“做出能工作的最简单方案”联系在一起，也特别提到持续重构、自动化测试和持续集成。YAGNI 单独使用可能把人带向凌乱的代码，重构和测试是它能够长期工作的配套实践。

假设一个网站当前只有一种通知方式，产品需求是发送邮件。实现一条清楚的邮件发送流程已经足够。此时为了“以后可能支持短信、站内信、推送和企业微信”，提前建造一套完整消息平台，通常就超出了当前问题。

等第二种通知方式真的出现，再从已经验证过的邮件流程中提取共同部分，往往能得到更贴近实际的抽象。那时我们知道哪些数据确实相同，哪些错误需要统一处理，哪些能力只属于某一种渠道。

这里的重点不是拒绝抽象。若当前已经有两种通知方式，或者系统明确要求多个渠道共享重试、审计和权限，那么抽象就是眼前需求的一部分，不能拿 YAGNI 当理由回避它。

YAGNI 经常被误解成“永远只写最短的代码”。这会把原则推向另一个极端。

Martin Fowler 对 YAGNI 的解释强调，它主要针对为假想功能提前构建的能力。让代码更容易修改，属于当前工程质量的一部分，并不等于提前实现未来功能。清晰的命名、合理的模块边界、自动化测试、稳定的数据约束和可回滚的发布流程，都可能是现在就值得做的事情。

可以把两类工作分开。未来功能是“以后也许要支持多租户”，可修改性是“今天把用户边界写清楚，让未来修改时不必猜”。前者需要需求证据，后者是在降低当前代码的维护风险。

KISS 通常提醒人选择简单的解决方案，YAGNI 进一步追问某个功能是否现在就有必要。DRY 关注重复知识和重复逻辑，提醒人避免让同一条规则散落在多个地方。

这些原则可能互相支持，也可能发生拉扯。为了消除两段暂时相似的代码，开发者可能抽出一个过早通用的模块，结果让两个变化方向被绑在一起。此时 DRY 的机械应用会伤害 YAGNI 和可维护性。

更稳妥的做法是先确认两段代码表达的是同一条业务知识。若只是表面上长得相似，保留重复可能更容易理解。若它们确实会一起变化，再提取共享逻辑。

YAGNI 不适合用来推迟已经明确的约束。安全、隐私、数据一致性、可观测性、备份、合规和灾难恢复，不能因为“现在还没有出事”就省掉。它们服务的是系统正确运行的条件，不是某个尚未确认的产品功能。

它也不能成为拒绝所有架构判断的口号。数据库选型、数据迁移策略、接口兼容性和依赖方向，有时会因为切换成本很高而需要提前考虑。考虑风险和提前实现功能是两件事。可以先保留清晰的边界和迁移路径，等需求出现时再增加具体能力。

Hacker News 上关于 YAGNI 的讨论长期存在分歧。一种观点担心过度提前设计，认为大多数未来需求都不会按原来的样子出现。另一种观点提醒人，核心架构决策的返工成本可能很高，不能把所有预见性设计都归为浪费。这个分歧说明 YAGNI 更像判断工具，而不是一条脱离上下文的禁令。

可以先问几个简单问题。

第一，需求是否已经被用户、产品或系统约束明确提出。第二，这项工作现在是否解决一个可观察的问题。第三，如果未来需求真的发生，今天不做它会产生什么具体代价。第四，当前实现是否已经让代码更容易修改，还是只增加了一个没人使用的入口。

如果答案只有“以后可能会用到”，通常应该先不做。把这个假设记在设计记录里，等证据出现后再实现，往往比把猜测埋进生产代码更诚实。

YAGNI 提醒开发者把实现和真实需求绑定起来，少为想象中的未来功能付出确定成本。它并不要求代码粗糙，也不反对提前思考。当前应该完成的是必要功能、正确性和可修改性，未来功能等证据出现以后再实现。