过早抽象会固化错误结构
别名: 过早抽象 · 错误关节 · freeze the wrong joints
概念解释
前两处调用常常共享的不是职责，而是巧合：这一页的边距、这一次接口返回的字段名、这一位设计师当时喜欢的分段方式。把这些巧合提成组件，等于宣布「这些接缝就是真接缝」。之后第三处、第四处若接缝在别处，它们必须扭曲自己去迁就那份已经入库的结构，或把组件撕开。过早抽象（premature abstraction）固化的是还在移动的关节，不是名字取得太泛，也不是中间又加了一层间接——它发生在「关节被认错」的那一刻。
抽象是一次打赌：当前切分会在未来的调用里重复。调用还太少时，赌局的样本不够。
机制
结构一旦进入共享库，改它的成本从「改两页」变成「改所有调用加一条迁移」。这个不对称让错误关节活得比正确关节更久：发现切分错了，也倾向加参数、加特例，而不是拆掉重切，因为拆掉会惊动已经绑上来的调用方。巧合被编码的途径很具体：两个表面都把操作放在右上，就被提成「右上动作栏」；其实第三个表面的操作属于每一行。入库的是位置，不是职责。位置是这一轮布局的事故，职责才可能稳定。过早抽象把事故写成接口，接口再把事故传给所有后来者。后来者为了「用上系统」，会继续往这份错结构里填，错误因此被使用量加固。
边界
平台级原语（按钮、文本输入）的关节早已被操作系统和网页标准钉死，不存在「再等两个产品」的样本问题，早抽象是在跟随已有契约。受法规冻结的流程（某一种披露对话框必须全国一样）在第二处出现时结构已经不可改，等第三次是假等待。反过来，视觉探索周、品牌尚未定稿、信息架构还在改导航模型时，任何入库都偏早——这时的重复往往是探索稿之间的重复，不是生产职责的重复。把「过早」理解成「永远不要抽」也不对；关节稳定后还坚持两份拷贝，付的是另一笔账。判断稳定的信号是：新的调用开始能套进现有切分，而不再要求新的主轴。
怎么落地
- 升格前把候选组件的接缝写出来：哪一段是职责、哪一段只是前两处碰巧一样。碰巧的部分不准进入公共属性或插槽。
- 对只服务一到两处、且信息架构仍在变的件，保持产品仓库内的局部实现，禁止以「以后会复用」入库。
- 发现调用方在用条件分支绕过组件的主结构，优先怀疑关节切错，而不是给组件再开一个开关。
- 验证：找一个共享组件，列出它的公共接缝和最近三个调用点各自真正的职责边界。若有一个调用点的主边界落在组件接缝之外、靠属性硬拗进来，就是错误结构已被固化。问作者「去掉前两处的边距和字段名，这个组件还剩什么」——若剩下的说不清，抽象发生得太早，该降回局部件或按新的职责重切，而不是继续加参数续命。