YAGNI 是什么
YAGNI（You Aren't Gonna Need It）出自极限编程实践：只在真实需要时才实现功能。为将来预留的扩展点、从没被传过的配置项、在没有基准数据时加的缓存，都是要持续支付维护成本的负债，而且多数情况下根本用不上。
基本信息
| 原则 | 按需构建，推迟决策 |
|---|---|
| 对应坏味道 | 夸夸其谈通用性、投机性抽象 |
| 例外 | 已经明确的近期路线图可以适度预留接缝 |
| 检验方法 | 这个扩展点今天真的有人用吗 |
典型使用场景
- 只有一个实现的接口层：抽象没有带来任何替换收益
- 从没被传入过的配置参数：维护成本却要一直付下去
- 从未触发的插件钩子：测试与文档都要跟着维护
- 声称为了性能预留的缓存：没有任何基准数据支撑
- 面向假想的第二种数据库：迁移成本还没发生就先付了抽象成本
YAGNI 不等于拒绝抽象
- 重复出现多次的逻辑仍然应该抽取
- 已经承诺的兼容需求属于真实需求
- 对外发布的产品需要给扩展留出接口
- 判断标准是需求是否真实存在，而不是猜测
常见信号
常见信号
□ 只有一个实现的接口层
□ 从来没有被传过的配置参数
□ 从来没有触发过的插件钩子
□ 声称为了性能预留但没有任何基准数据的缓存信号与处理方向
| 信号 | 处理方向 |
|---|---|
| 单一实现的接口 | 合并回具体类，需要时再抽 |
| 空置的配置项 | 删掉参数，等真实需求出现 |
| 未使用的钩子 | 删除代码路径，减少测试面 |
| 没有基准的缓存 | 先用数据说话，再决定加不加 |
识别投机性设计有个简单办法：把这段代码删掉，如果没有任何行为变化，它大概率是多余的。
打着 YAGNI 拒绝合理抽象：重复逻辑的维护成本比抽象更高，改一处漏一处。