Ramp lagerte seine UI-Komponentenbibliothek in ein eigenes Repository aus, damit Designänderungen nicht mehr durchsickerten

In einem schnell iterierenden Startup fühlt sich der Zeitpunkt nie richtig an, eine Komponentenbibliothek zu bauen: Die Standardisierung von Komponenten steht im Konflikt mit den schnellen, ständigen Änderungen, die nötig sind, um Product-Market-Fit zu finden. Das Engineering-Team von Ramp stand genau davor. Als sie begannen, eine zu bauen, hatte Ramp bereits ein Produkt mit Komponenten, die über Jahre hinweg im Haupt-Codebase iteriert, im Rahmen gewöhnlicher Feature-Arbeit ad hoc angepasst worden waren, ohne Trennung zwischen Geschäftslogik und Designentscheidungen.

Anstatt die Komponenten im Haupt-Repository zu belassen und sich auf Disziplin zu verlassen, um beiläufige Änderungen zu vermeiden, zog das Team von Ramp das, was es eine harte Grenze nannte: ein separates Repository, veröffentlicht als eigenes npm-Paket, mit einem handgepflegten Changelog und ordentlicher Versionierung, damit konsumierende Teams Änderungen nach ihrem eigenen Zeitplan übernehmen konnten. Werten innerhalb der Bibliothek wurden zudem semantische Namen gegeben, eine "destructive"-Farbe statt eines bestimmten Rot, sodass die visuelle Entscheidung und der Code, der sie konsumierte, nicht mehr dasselbe waren.

Um die Adoption voranzutreiben, behandelte das Team das interne Paket wie ein Open-Source-Projekt und baute aus den Komponenten der Bibliothek selbst eine eigene Dokumentationsseite, was das Team dazu zwang, Ryu als echten zweiten Konsumenten zu dogfooden. Sie wählten zudem Tiefe der Adoption über Breite der Abdeckung: Es war besser, fünf Komponenten überall vollständig adoptiert zu haben als fünfundzwanzig Komponenten, die niemand nutzte, sodass neuer Code standardmäßig die neue Bibliothek verwendete, während alte Komponenten schrittweise migriert statt alle auf einmal neu geschrieben wurden.

Die Bibliothek in ein eigenes Repository und Paket isolieren

Ein separates Repository macht jede Designänderung zu einem bewussten, überprüften Beitrag statt zu einem Nebeneffekt von Feature-Arbeit.

Semantische Benennung entkoppelt die visuelle Entscheidung von der Implementierung, sodass sich Farben oder Abstände ändern lassen, ohne Konsumenten zu brechen.

Die Dokumentationsseite aus der Bibliothek selbst zu bauen, schafft einen echten zweiten Konsumenten, der Integrationsfehler früh aufdeckt.

Ein internes Paket wie Open Source zu behandeln, mit Changelog und Versionierung, ermöglicht Teams, Änderungen ohne erzwungene Neuschreibung zu übernehmen.

Ein gemeinsames System bleibt kohärent, wenn das Bearbeiten einen bewussten Schritt erfordert: Isoliere es in einem eigenen Repository und lass Konsumenten abstrakte Eigenschaften statt Rohwerte anfordern.

Das Engineering-Team von Ramp beschrieb die Bibliothek mit Stand November 2021 als noch aktiv im Aufbau befindlich und nannte es "Tag 973" im Leben des Unternehmens, wobei die Adoption schrittweise vorangetrieben wurde, indem Komponenten bevorzugt wurden, die vollständig genutzt wurden, gegenüber solchen, die bloß existierten. Der Ansatz der Isolation und semantischen Benennung wurde zum Muster, das das Team weiter über die Kern-App, Blogs und internen Tools des Unternehmens ausdehnte, statt eine einmalige Migration zu bleiben.