组件库从 40 个砍到 12 个,我们丢了什么
去年我们把内部组件库从 40 个收敛到 12 个。半年后回头看,这是一次成功的重构,也是一次有代价的重构。
合并的收益
- 代码量掉 62%
- 视觉走查的争议从每周 5~8 次降到 1 次以内
- 新页面搭起来从平均 4 天到 1.5 天
丢掉的三种东西
一、场景专属的默认值
原来有个 AmountInput,默认千分位、默认右对齐、默认带币种前缀。合并进 Input 之后,每个金额输入框都要重新声明这三个属性。
组件是少了,代码里的重复变多了。
二、约束
TimeRangePicker 原本只能选最近 90 天,因为它服务于对账场景,再往前的数据在仓里根本没有。合并成通用组件后,这个约束得靠调用方自觉。三个月内,有 4 个页面出现了「选了半年,查出来是空的」。
三、命名的约定
40 个组件时,名字本身就是文档:RefundAmountInput 一眼知道它只在退款流程用。12 个通用组件之后,名字只剩类型信息,业务语义全靠读代码。
我们后来补的
给每个通用组件加了「推荐用法」段落,不是 API 文档,是什么时候不该用。
收敛组件库真正的工作量不在删,在把被删掉的那些约束重新找地方安置。
结论
砍组件是对的,但我现在会先问一句:这个组件里的默认值、约束和命名,分别去哪儿?想不清楚就别动。