Ramp a isolé sa bibliothèque de composants d'interface dans son propre dépôt afin que les modifications de design cessent de fuiter

Dans une startup qui itère rapidement, le moment ne semble jamais propice pour construire une bibliothèque de composants : standardiser les composants entre en conflit avec les changements rapides et constants nécessaires pour trouver l'adéquation produit-marché. L'équipe d'ingénierie de Ramp y a été directement confrontée. Au moment où elle a commencé à en construire une, Ramp avait déjà un produit dont les composants avaient été itérés pendant des années au sein du codebase principal, ajustés de manière ad hoc dans le cadre du travail ordinaire sur les fonctionnalités, sans séparation entre la logique métier et les décisions de design.

Plutôt que de garder les composants dans le dépôt principal et de compter sur la discipline pour éviter les modifications incidentes, l'équipe de Ramp a tracé ce qu'elle a appelé une frontière stricte : un dépôt séparé, publié comme son propre paquet npm, avec un changelog rédigé à la main et un versionnage approprié afin que les équipes consommatrices puissent adopter les changements selon leur propre calendrier. Les valeurs au sein de la bibliothèque ont également reçu des noms sémantiques, une couleur « destructive » plutôt qu'un rouge spécifique, afin que la décision visuelle et le code qui la consommait ne soient plus la même chose.

Pour favoriser l'adoption, l'équipe a traité le paquet interne comme un projet open source, en construisant son propre site de documentation à partir des composants de la bibliothèque elle-même, ce qui a forcé l'équipe à utiliser Ryu comme un véritable second consommateur. Elle a également choisi la profondeur d'adoption plutôt que l'étendue de la couverture : il valait mieux avoir cinq composants pleinement adoptés partout que vingt-cinq composants que personne n'utilisait, de sorte que le nouveau code utilisait par défaut la nouvelle bibliothèque tandis que les anciens composants étaient migrés progressivement plutôt que réécrits d'un coup.

Isoler la bibliothèque dans son propre dépôt et paquet

Un dépôt séparé fait de chaque modification de design une contribution délibérée et revue plutôt qu'un effet secondaire du travail sur les fonctionnalités.

La nomenclature sémantique découple la décision visuelle de l'implémentation, de sorte que les couleurs ou les espacements peuvent changer sans casser les consommateurs.

Construire le site de documentation à partir de la bibliothèque elle-même crée un véritable second consommateur qui fait remonter les bugs d'intégration tôt.

Traiter un paquet interne comme de l'open source, avec un changelog et un versionnage, permet aux équipes d'adopter les changements sans réécriture forcée.

Un système partagé reste cohérent lorsque le modifier exige une démarche délibérée : l'isoler dans son propre dépôt et laisser les consommateurs demander des propriétés abstraites plutôt que des valeurs brutes.

L'équipe d'ingénierie de Ramp a décrit la bibliothèque comme encore en cours de construction active en novembre 2021, la qualifiant de « jour 973 » de la vie de l'entreprise, avec une adoption favorisée progressivement en privilégiant les composants pleinement utilisés plutôt que ceux qui existaient simplement. L'approche d'isolation et de nomenclature sémantique est devenue le modèle que l'équipe a continué d'étendre à l'application principale, aux blogs et aux outils internes de l'entreprise, plutôt qu'une migration ponctuelle.