Ramp 將其 UI 元件庫隔離到獨立儲存庫，使設計變更不再外洩

在快速迭代的新創公司裡，建立元件庫的時機永遠感覺不對：標準化元件與尋找產品市場契合度所需的快速、持續變動相互衝突。Ramp 的工程團隊直接面對了這個問題。等到他們開始建立元件庫時，Ramp 的產品早已在主程式碼庫中累積了歷經數年迭代的元件，這些元件在一般功能開發過程中遭到臨時調整，業務邏輯與設計決策之間毫無區隔。

Ramp 的團隊沒有把元件留在主儲存庫裡、仰賴紀律來避免順手改動，而是劃出他們所謂的硬邊界：一個獨立儲存庫，發佈為專屬的 npm 套件，附上手寫的變更日誌與完善的版本控制，讓使用方團隊能按自己的時程採用變更。元件庫內的值也改採語意化命名，例如以「destructive」色取代特定的紅色，使視覺決策與使用它的程式碼不再是同一回事。

為了推動採用，團隊把這個內部套件當成開源專案經營，用元件庫自身的元件打造專屬文件網站，這也迫使團隊把 Ryu 當成真正的第二個使用方來實際試用。他們也選擇重採用深度而非覆蓋廣度：讓五個元件在所有地方都被完整採用，勝過二十五個沒人使用的元件，因此新程式碼預設使用新元件庫，舊元件則逐步遷移，而非一次全部重寫。

將元件庫隔離到獨立儲存庫與套件中

獨立儲存庫讓每一項設計變更都成為經過審查的刻意貢獻，而非功能開發的副作用。

語意化命名將視覺決策與實作解耦，因此顏色或間距可以變更而不會破壞使用方。

用元件庫本身打造文件網站，創造出真正的第二個使用方，能及早暴露整合問題。

把內部套件當成開源專案經營，附上變更日誌與版本控制，讓各團隊能採用變更而不必被迫重寫。

共享系統要維持一致，編輯它時就必須採取刻意的步驟：將它隔離在獨立儲存庫中，並讓使用方要求抽象屬性，而非原始值。

Ramp 的工程團隊表示，截至 2021 年 11 月，該元件庫仍在積極建置中，並稱當時是公司成立以來的「第 973 天」，採用情況是逐步推動的，偏好已被完整使用的元件，而非僅是存在而已。這種隔離與語意化命名的做法，成為團隊持續推廣到公司核心應用程式、部落格與內部工具的模式，而非一次性的遷移。