RampはUIコンポーネントライブラリを専用リポジトリに分離し、デザイン変更の漏れを止めた

急速に反復開発を進めるスタートアップでは、コンポーネントライブラリを作るタイミングはなかなか訪れない。コンポーネントの標準化は、プロダクトマーケットフィットを見つけるために必要な迅速かつ絶え間ない変更と相反する。Rampのエンジニアリングチームはこの課題に直面した。ライブラリの構築を始めた時点で、Rampにはすでに何年もメインコードベース内で反復され、通常の機能開発の一環として場当たり的に調整され、ビジネスロジックとデザイン上の決定の間に分離が存在しないコンポーネントを持つプロダクトがあった。

コンポーネントをメインリポジトリ内に置いたまま、ついでの編集を避けるための規律に頼るのではなく、Rampのチームは「ハードバウンダリ」と呼ぶものを引いた。すなわち、独自のnpmパッケージとして公開される別リポジトリであり、手作りの変更履歴と適切なバージョニングを備えることで、利用するチームが自分たちのスケジュールで変更を採用できるようにした。ライブラリ内の値にもセマンティックな名前が与えられ、特定の赤ではなく「destructive」という色名にすることで、視覚的な決定とそれを消費するコードがもはや同一のものではなくなった。

採用を促進するため、チームは社内パッケージをオープンソースプロジェクトのように扱い、ライブラリ自身のコンポーネントを使って独自のドキュメントサイトを構築した。これによりチームはRyuを実際の第二の利用者としてドッグフーディングせざるを得なくなった。また、カバレッジの広さよりも採用の深さを選んだ。誰も使わない25個のコンポーネントよりも、5個のコンポーネントがどこでも完全に採用されている方が良いため、新しいコードは新しいライブラリをデフォルトとし、古いコンポーネントは一度に書き直すのではなく段階的に移行された。

ライブラリを専用のリポジトリとパッケージに分離した

別リポジトリにすることで、あらゆるデザイン変更が機能開発の副作用ではなく、意図的でレビューされた貢献になる。

セマンティックな命名は視覚的な決定を実装から切り離すため、色や間隔を変更しても利用側が壊れない。

ドキュメントサイトをライブラリ自体から構築することで、実際の第二の利用者が生まれ、統合のバグが早期に表面化する。

社内パッケージを変更履歴とバージョニングを備えたオープンソースのように扱うことで、チームは強制的な書き直しなしに変更を採用できる。

共有システムは、編集に意図的な一歩を要するときに一貫性を保つ。専用リポジトリに分離し、利用側には生の値ではなく抽象的なプロパティを要求させるのだ。

Rampのエンジニアリングチームは、2021年11月時点でライブラリはまだ活発に構築中であると述べ、それを会社の歴史の「973日目」と呼んだ。採用は、単に存在するだけのコンポーネントよりも完全に使われているコンポーネントを優先することで段階的に進められた。分離とセマンティック命名のアプローチは一度きりの移行ではなく、チームが会社の中核アプリ、ブログ、社内ツール全体に広げ続けたパターンとなった。