约定式设计的成功案例
Ruby on Rails 是「约定大于配置」最经典的实践者。文件放在什么目录、数据库表叫什么名字、路由怎么映射，Rails 都给你定好了规矩。开发者只要遵循约定，就能用极少的代码搭建出一个完整的 Web 应用。这种体验是革命性的。
在前端领域，Next.js 的文件系统路由是另一个成功的约定。pages/about.tsx 就是 /about 路由，不需要任何配置。Umi 在国内也走了类似的路线，通过目录约定覆盖路由、布局、数据流等方面。这些框架的流行证明了：好的约定能大幅降低认知负担。
约定带来的效率提升
约定的核心价值在于消除决策成本。一个团队如果每个项目都要讨论「目录结构怎么组织」「状态管理用什么方案」「API 层怎么封装」，这些决策的累积成本是惊人的。约定把这些问题预先解决了，团队可以把精力集中在业务逻辑上。
更深层的好处是一致性。当所有项目遵循同一套约定时，任何一个同学都可以快速上手另一个项目。代码审查也变得更高效，因为大家对「代码应该长什么样」有共同的预期。
过度约定的陷阱
然而约定也有失控的时候。当框架的约定变得过于复杂或过于隐式，开发者就会陷入「魔法」的困境——代码能跑但不知道为什么，出了问题也不知道从哪里查起。Umi 早期版本中一些过于隐式的约定就曾引发社区的批评。
另一个陷阱是约定的僵化。业务需求千变万化，当你遇到一个不符合约定的场景时，框架是否提供了优雅的逃生口？如果绕过约定比遵循约定更痛苦，那约定就变成了束缚。
找到平衡点
好的约定应该满足三个条件：覆盖高频场景、行为可预测、提供逃生口。它不应该追求覆盖所有情况，而是让 80% 的常见路径变得极其简单，同时为 20% 的特殊需求保留灵活性。这个度的拿捏，是框架设计中最考验品味的部分。
相关文章