expensive-to-add-later

# PAGNI：可能以后会需要它 ## 核心洞察 > “什么时候你应该覆盖 YAGNI（你不会需要它）？当以后添加某样东西的成本与早期添加的成本相比极其昂贵，以至于值得承担风险时。” YAGNI 是一个很好的默认原则。但有些东西在初期构建确实比后期改造便宜得多。要学会区分。 ## 为什么这很重要 盲目应用 YAGNI 可能会适得其反，当： - 以后添加它需要触及所有地方（日志记录、时间戳、审计追踪） - 你根本无法追溯添加它（API 版本控制、移动应用终止开关） - 没有它的代价是灾难性的（安全基础、你丢弃的数据） “避免复杂性”的技能倾向于减少。这种思维模式识别了那些“现在添加”胜过“以后添加”的例外情况。 ## 常见的 PAGNI **无法找回的数据：** - 每个表上的 `created_at` / `updated_at` 时间戳 - 审计日志（谁在什么时候做了什么） - 如果有任何迹象表明你需要不止一个，从一开始就使用多对多关系 **改造起来很痛苦的基础设施：** - API 版本控制（即使 v1 是唯一版本） - API 分页（即使现在的列表很小） - 从第一天开始的自动化部署和 CI - 日志基础设施 **安全基础：** - 漏洞披露政策和 security@ 邮箱 - 会话/密码失效机制 - 将脱敏数据移出生产环境的安全方式 ## 测试 在调用 PAGNI 之前，请问： 1. **后期改造是否极其昂贵？**（10 倍以上，而不是 2 倍） 2. **这是基于经验的已知模式吗？**（而不是推测） 3. **现在添加它的成本实际上很低吗？**（分钟/小时，而不是天） 如果以上三点都为是，那就是 PAGNI。否则，YAGNI 仍然适用。 ## 平衡 PAGNI 不是过度工程的逃生舱。它是从痛苦经验中总结出的一小部分特定例外列表。如有疑问，YAGNI 胜出。 **大多数功能：YAGNI。基础设施和数据收集：可能是 PAGNI。** ## 外部参考 - [PAGNIs: Probably Are Gonna Need Its](https://simonwillison.net/2021/Jul/1/pagnis/) - Simon Willison - [YAGNI Exceptions](https://lukeplant.me.uk/blog/posts/yagni-exceptions/) - Luke Plant - [Application Security PAGNIs](https://jacobian.org/2021/jul/8/appsec-pagnis/) - Jacob Kaplan-Moss