Ramp将其UI组件库隔离在独立仓库中，设计变更不再外溢

在快速迭代的初创公司里，构建组件库的时机似乎永远不对：标准化组件与寻找产品市场契合所需的快速、持续变化相冲突。Ramp的工程团队直接面对了这一问题。等到他们开始构建组件库时，Ramp的产品中已有一些组件在主代码库内迭代了数年，作为日常功能工作的一部分被临时调整，业务逻辑与设计决策之间没有任何分离。

Ramp的团队没有把组件留在主仓库内、依靠纪律来避免顺手改动，而是划定了他们所称的硬边界：一个独立的仓库，作为独立的npm包发布，配有手工编写的变更日志和规范的版本管理，使使用方团队可以按自己的节奏采纳变更。库中的值也被赋予语义化名称，用“destructive”颜色而不是某个具体的红色，因此视觉决策与使用它的代码不再是同一回事。

为推动采用，团队把内部包当作开源项目来对待，用库自身的组件搭建了文档站点，这迫使团队把Ryu当作真正的第二个使用方来内部试用。他们还选择重采用深度而非覆盖广度：五个组件在所有地方被完全采用，胜过二十五个无人使用的组件，因此新代码默认使用新库，而旧组件则逐步迁移，而不是一次性重写。

将库隔离在独立的仓库和包中

独立的仓库使每一次设计变更都成为经过审查的刻意贡献，而不是功能工作的副作用。

语义化命名将视觉决策与实现解耦，因此颜色或间距可以变化而不破坏使用方。

用库本身搭建文档站点，创造了一个真正的第二使用方，能及早暴露集成缺陷。

把内部包当作开源项目对待，配有变更日志和版本管理，让团队无需被迫重写即可采纳变更。

当编辑共享系统需要刻意的一步时，它才能保持一致性：将其隔离在独立仓库中，让使用方请求抽象属性而不是原始值。

Ramp的工程团队表示，截至2021年11月，该库仍在积极构建中，并称当时是公司生命的“第973天”，采用是逐步推进的，倾向于完全被使用的组件，而不是仅仅存在的组件。隔离与语义化命名的方法成为团队持续扩展到公司核心应用、博客和内部工具的模式，而不是一次性的迁移。