第二个使用场景出现前，别急着加抽象层

前言

三个拆掉过早抽象的真实案例，加上一条简单规则：重复的代码要撑到什么程度，才值得搬进共享模块。

为什么这个问题反复出现

每一场 Pattern 的讨论最后都会落在同一个张力上：对团队当下舒服的选择，和项目一年后真正需要的东西。光靠辩论，哪一边都赢不了。

一种思考方式

• 默认值比意图活得久——请刻意设计它。
• 决策本身很便宜，沟通很贵——为后者留出预算。
• 分歧是数据。把「什么证据会改变你的想法」写下来。

我会怎么做

从「小到觉得没什么用」的规模开始，把理由写进 commit 或 RFC，然后在日历上定一个日期重访它，而不是凭感觉。

写在最后

Pattern 的品味，大多是记忆。请刻意收集属于你的那份。