R1.08.3rule of three设计

三次重复后再抽象是常见经验法则

别名: 三次法则 · 重复三次再抽取 · wait for three

概念解释

一处实现没有对照,看不出哪些是职责、哪些是这一页的事故。两处相似,仍可能是两次碰巧。三处开始让「这是一个模式」比「这是巧合」更值得赌。三次法则(rule of three)是这套样本直觉的口头形式:常见、好记、能挡住第一稿就入库的手。它是启发式,不是定律——有时两处就该抽(结构已被外部钉死),有时五处仍不该抽(五处仍是各自页面的巧合)。它回答「什么时候开始抽」,不回答「抽出来的东西会不会参数爆炸」,也不主张拷贝永远更便宜。

把「三」当成KPI,和第一稿就抽象一样机械。

机制

抽象需要比较。一次出现只给出一个形状,切分轴是作者的偏好。两次给出一条可能的轴,但两条点总能连成直线,直线外的点还没来。三次提供一个可以证伪的图案:第三处若套不进前两处的切分,切分就要改,而这时代价还停留在三份局部代码,而不是一份已经对外的接口。法则的力量来自延迟:延迟让切分在重复里显形,而不是在预测里显形。它不是在说第四处必然长得一样;它是在说,样本小于三时,你几乎无法区分模式和巧合,而共享库惩罚的是把巧合写成契约。启发式会失败的方式也清楚:把三次当作许可证,第三次一出现就抽,不再检查三处是否真的同职责——那只是把过早抽象推迟到了第三次。

边界

平台与法律已经规定死的结构,第二次出现即可抽,等第三次是仪式。明确的短命重复(同一战役的三张落地页)即使出现三次也不抽,以免把战役骨架写成长期契约。复制来自同一模板生成器的「三次」,样本不独立,次数无效。团队若从未付过错误抽象的迁移成本,会把法则理解成官僚;刚被一次错误抽象烫伤的团队会把「三」加成「五」或「永远不抽」。两种偏离都要把失败模式说回来:过早固化关节,或该共享的职责继续分叉。三次法则不管「名字是否太泛」或「中间层是否太多」——那些是另一类过度。

怎么落地

  • 在升格清单上问:独立的生产调用是几处?三处以下默认不入库,并写明例外(平台原语、法规冻结)而不是默许「看起来很像」。
  • 数次数时去掉同源拷贝:从同一模板生成、或从同一页面复制出来的,算一处,不算三处。
  • 第三次出现时先试套现有切分。套进去,再抽;套不进去,改切分或继续分开放,而不是把第三处拗进前两处的接口。
  • 验证:抽最近一个季度的升格,标出升格时的独立调用数。多数小于三、又给不出平台或法规例外,法则没有在用。多数等于三、但第三处靠新参数才塞进去,三次被当成了许可证,样本直觉被浪费。再找两处已重复、故意未抽的件:若第三处迟迟不来或来了却套不进,等待是对的。若第三处干净地套进且团队仍在维护三份拷贝,法则被加成了教条,该抽而不抽。对照拷贝本身是否更省——那是另一笔账,不在这条启发式里结算。

延伸

  • 同组R1.08.1 过早抽象会固化错误结构 · R1.08.2 参数过多的组件难以正确使用
  • 相邻R1.17 组件的过度抽象 · R1.02 组件库与变体
  • 站内检索rule of three · wait to abstract · repetition heuristic

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/R1.08.3