En una startup que itera rápidamente, el momento nunca parece el adecuado para construir una biblioteca de componentes: estandarizar componentes entra en conflicto con los cambios rápidos y constantes necesarios para encontrar el encaje producto-mercado. El equipo de ingeniería de Ramp se enfrentó directamente a esto. Para cuando empezaron a construir una, Ramp ya tenía un producto con componentes que se habían iterado durante años dentro del código base principal, ajustados de forma ad hoc como parte del trabajo ordinario de funcionalidades, sin separación entre la lógica de negocio y las decisiones de diseño.
En lugar de mantener los componentes dentro del repositorio principal y confiar en la disciplina para evitar ediciones incidentales, el equipo de Ramp trazó lo que llamó un límite duro: un repositorio separado, publicado como su propio paquete npm, con un registro de cambios elaborado a mano y un versionado adecuado para que los equipos consumidores pudieran adoptar los cambios según su propio calendario. También se dieron nombres semánticos a los valores dentro de la biblioteca, un color "destructive" en lugar de un rojo específico, de modo que la decisión visual y el código que la consumía ya no fueran lo mismo.
Para impulsar la adopción, el equipo trató el paquete interno como un proyecto de código abierto, construyendo su propio sitio de documentación a partir de los propios componentes de la biblioteca, lo que obligó al equipo a usar Ryu como un segundo consumidor real. También eligieron la profundidad de adopción por encima de la amplitud de cobertura: era mejor tener cinco componentes plenamente adoptados en todas partes que veinticinco componentes que nadie usara, así que el código nuevo se apoyaba por defecto en la nueva biblioteca mientras los componentes antiguos se migraban de forma incremental en lugar de reescribirse todos a la vez.
Aislar la biblioteca en su propio repositorio y paquete
Un repositorio separado convierte cada cambio de diseño en una contribución deliberada y revisada en lugar de un efecto secundario del trabajo de funcionalidades.
Los nombres semánticos desacoplan la decisión visual de la implementación, de modo que los colores o el espaciado pueden cambiar sin romper a los consumidores.
Construir el sitio de documentación a partir de la propia biblioteca crea un segundo consumidor real que saca a la luz los errores de integración de forma temprana.
Tratar un paquete interno como código abierto, con un registro de cambios y versionado, permite a los equipos adoptar los cambios sin una reescritura forzada.
Un sistema compartido se mantiene coherente cuando editarlo requiere un paso deliberado: aislarlo en su propio repositorio y dejar que los consumidores pidan propiedades abstractas en lugar de valores en bruto.
El equipo de ingeniería de Ramp describió la biblioteca como todavía en construcción activa en noviembre de 2021, llamándolo el "día 973" de la vida de la empresa, con una adopción impulsada de forma incremental al favorecer los componentes que se usaban plenamente sobre los que simplemente existían. El enfoque de aislamiento y nombres semánticos se convirtió en el patrón que el equipo siguió extendiendo por la aplicación principal, los blogs y las herramientas internas de la empresa, en lugar de una migración puntual.
CONSULTA LAS PRUEBAS
Las fuentes
- Bootstrapping a UI component library Ramp Engineering · builders.ramp.com ·