A Ramp isolou sua biblioteca de componentes de UI em um repositório próprio para que as mudanças de design parassem de vazar

Em uma startup que itera rapidamente, o momento nunca parece certo para construir uma biblioteca de componentes: padronizar componentes entra em conflito com as mudanças rápidas e constantes necessárias para encontrar o product-market fit. A equipe de engenharia da Ramp enfrentou isso diretamente. Quando começaram a construir uma, a Ramp já tinha um produto com componentes que vinham sendo iterados por anos dentro do código principal, ajustados de forma ad hoc como parte do trabalho comum de features, sem separação entre lógica de negócio e decisões de design.

Em vez de manter os componentes dentro do repositório principal e confiar na disciplina para evitar edições casuais, a equipe da Ramp traçou o que chamou de fronteira rígida: um repositório separado, publicado como seu próprio pacote npm, com um changelog feito à mão e versionamento adequado para que as equipes consumidoras pudessem adotar mudanças no próprio ritmo. Os valores dentro da biblioteca também receberam nomes semânticos, uma cor "destructive" em vez de um vermelho específico, para que a decisão visual e o código que a consumia não fossem mais a mesma coisa.

Para impulsionar a adoção, a equipe tratou o pacote interno como um projeto de código aberto, construindo seu próprio site de documentação a partir dos próprios componentes da biblioteca, o que forçou a equipe a usar o Ryu como um segundo consumidor real. Também escolheram profundidade de adoção em vez de amplitude de cobertura: era melhor ter cinco componentes totalmente adotados em todos os lugares do que vinte e cinco componentes que ninguém usava, então o código novo passou a usar a nova biblioteca por padrão, enquanto os componentes antigos eram migrados de forma incremental em vez de reescritos de uma vez.

Isolar a biblioteca em seu próprio repositório e pacote

Um repositório separado transforma cada mudança de design em uma contribuição deliberada e revisada, em vez de um efeito colateral do trabalho de features.

A nomenclatura semântica desacopla a decisão visual da implementação, para que cores ou espaçamentos possam mudar sem quebrar os consumidores.

Construir o site de documentação a partir da própria biblioteca cria um segundo consumidor real que revela bugs de integração cedo.

Tratar um pacote interno como código aberto, com changelog e versionamento, permite que as equipes adotem mudanças sem uma reescrita forçada.

Um sistema compartilhado permanece coerente quando editá-lo exige um passo deliberado: isolá-lo em seu próprio repositório e deixar os consumidores pedirem propriedades abstratas em vez de valores brutos.

A equipe de engenharia da Ramp descreveu a biblioteca como ainda em construção ativa em novembro de 2021, chamando aquilo de "dia 973" da vida da empresa, com a adoção impulsionada de forma incremental ao favorecer componentes que eram totalmente usados em vez daqueles que apenas existiam. A abordagem de isolamento e nomenclatura semântica tornou-se o padrão que a equipe continuou a estender pelo aplicativo principal, blogs e ferramentas internas da empresa, em vez de uma migração única.