Introducción del sistema de diseño en una base de código madura

Hola a todos. Permítanme guiarlos a través de la introducción del sistema de diseño en una base de código madura basada libremente en Clio. Pero antes de entrar en más detalles, permítanme presentarme adecuadamente. Soy Kasia Strzymska, líder de tecnología de diseño en Clio. Estoy basada en Polonia, Gdańsk, pero Clio está principalmente en Londres. Así que soy una empleada de Clio completamente remota.

Entonces, base de código madura, ¿qué es exactamente en Clio? Entonces, si pensamos en un proyecto, cuando estamos comenzando un proyecto, estamos pensando en algo que cumpla con los requisitos, cumpla con las expectativas. Estamos recopilando estos requisitos y luego construiremos algo que sea lo suficientemente bueno para cumplir con todos los requisitos, entregar todas las características. Así que en una analogía de una casa, tiene ventanas, tiene puertas, paredes, un techo, con suerte algunas habitaciones dentro, una cama. Y este es como un producto final.

Pero a lo largo de los años, durante muchos años, por ejemplo, ocho años, esta casa comienza a crecer y a veces comienza a crecer en una dirección muy extraña. Así que esto es lo que puede convertirse una base de código madura si se desarrolla a un ritmo muy, muy rápido, como fue el ejemplo de Clio, donde somos una startup, nos consideramos una startup que se mueve muy rápido y hemos estado probando múltiples características diferentes con nuestros usuarios. Y debido a eso, nuestra base de código creció mucho a lo largo de estos años. Y debido a eso, hemos encontrado muchos desafíos en el camino, uno de ellos siendo el hecho de que introdujimos muchos componentes, muchos de los cuales se veían diferentes, se comportaban de manera diferente. Aunque se suponía que debían tener la misma función o una función similar, todos se veían diferentes. Y lo mismo con el estilo. Así que a lo largo de estos años, introdujimos muchos estilos diferentes. Hubo un cambio de marca en el camino. Así que teníamos un par de paletas de colores diferentes viviendo en la base de código, conjuntos de tokens, algunos colores o espacios utilizados como valores mágicos. Y a lo largo de los años, también introdujimos muchos patrones de diseño inconsistentes. Principalmente, pero probablemente no solo por eso, hemos estado trabajando en escuadrones aislados, todavía trabajamos en escuadrones, escuadrones de producto, que están muy enfocados en las características y en entregar características en el ámbito de su dominio.

Priorizan mucho la entrega rápida de una característica sobre la consistencia. Y debido a eso, hemos tenido que enfrentar más que estos, pero también estos desafíos de mantenimiento difícil, incorporación lenta y experiencia de usuario desarticulada, lo cual es, ya saben, para una empresa como Clio, muy enfocada en el usuario, orientada al usuario, una experiencia de usuario desarticulada es muy dolorosa de ver. Nos dimos cuenta como equipo del sistema de diseño que hay una cosa que necesitamos. Así que volviendo a nuestra analogía de la casa, necesitamos un plan. Necesitamos un plan arquitectónico de esta gran casa. Necesitamos entender dónde estamos, cuántas ventanas tenemos, cuántas puertas, qué formas, toda esta información. Básicamente necesitábamos datos para guiarnos, lo cual también está muy conectado con Clio porque usamos datos todo el tiempo. Así que el sistema de diseño no fue diferente.

Básicamente necesitamos tener datos para guiarnos. Y para recopilar algunos datos, obviamente, necesitamos investigar cuáles son nuestras opciones. Podríamos escribir toda la solución por nosotros mismos. Pero afortunadamente, había un React scanner, que es una biblioteca muy buena que permite a los ingenieros de React rastrear la base de código para entender qué componentes se están utilizando. Les mostraré un poco de código más adelante. Además de eso, he utilizado tecnologías de nuestro portafolio, como el portafolio de Clio, junto con GitHub Actions, Redshift, para almacenar datos y la plataforma Count para consultar los datos.

Así que si les gusta ver la visualización de esto, fue un GitHub Actions que activaba el script, el script de node que vivía en el repositorio junto al repositorio. Luego, el script estaba usando Webhook proporcionado a través de Fivetran y el Webhook simplemente obtenía los datos y los enviaba a Redshift. Y desde Redshift, los datos estaban disponibles en Count. Así que nuestros analistas y nuestros ingenieros podían consultar los datos para entender dónde estamos. Así que un poco sobre el código en sí, el script. Así que es bastante sencillo. Había un scanner. Tuvimos que ejecutarlo y esperar los resultados. La configuración se la mostraré más adelante. Luego la conversión a cadena de los datos. Hay un poco de mapeo en marcha y el mapeo es muy simple. Es solo mover de HashMap hacia Array y luego el Webhook que mencioné antes. Así que enviar todos estos datos a través de Fivetran en nuestro caso a Redshift.

Así que la configuración, también bastante sencilla. Hay un crawl from. Así que básicamente queremos informar a ReaRscanner dónde se supone que debe comenzar el rastreo. El método. Así que qué debería hacer ReaRscanner con los datos? ¿Debería devolver el script directamente o tal vez debería guardarlo en algún lugar del archivo? También hay una opción para devolver. Nos da una opción para simplemente obtener los datos y tal vez hacer algún mapeo con los datos y luego hacer algo más al respecto. También es posible simplemente guardar los datos directamente en un archivo JSON y tal vez hacer algo con este archivo también. La siguiente opción procesadores es básicamente todas las funciones de mapeo proporcionadas por ReaRscanner por defecto, pero también la posibilidad de crear algunas personalizadas como las que he creado. Así que el conteo, componentes y props es básicamente un procesador de ReaRscanner para recorrer todos estos componentes e instancias de estos componentes y contar las instancias y props utilizadas y devolver esta información en forma de un mapa. Y luego el segundo, el personalizado, se los mostraré. Así que el procesador de información de importación de instancias es uno muy simple.

Debe seguir el patrón que ReaRscanner está proporcionando. Así que hay algunos argumentos que ReaRscanner ya está pasando al procesador, como pre-resultados, así que como resultados del procesador anterior para cada componente, que es un iterador sobre el componente y luego una función de ordenamiento muy simple. Así que dentro del iterador, básicamente verifiqué si hay alguna instancia y si hay al menos una instancia, quería entender de dónde se importó el componente porque el procesador predeterminado de ReaRscanner no estaba recopilando estos datos. Y realmente necesitaba eso para entender si el componente fue importado de nuestra biblioteca de componentes, biblioteca compartida de componentes o no. Y luego el pre-resultado, solo necesitaba ordenar los datos nuevamente después de esta iteración y devolver y devolver. Así que los datos que hemos recopilado y logrado tener un resultado realmente bueno.

Vale la pena mencionar, teníamos una biblioteca de componentes compartidos cuando comenzamos a trabajar en el sistema de diseño. Y simplemente no se usaba en todos los casos. Así que aquí hay un ejemplo de lo que estamos rastreando ahora mismo. Estamos rastreando como el uso principal de componentes compartidos y no compartidos para entender cuáles son las tendencias, qué componentes se usan más o cuáles están disminuyendo. Así que necesitamos encontrar los puntos de dolor. Y luego lo que hicimos con estos datos. Así que obviamente necesitamos pensar en los desafíos que enfrentábamos. Así que la colaboración fue uno de ellos. Somos un sistema de diseño, un equipo de dos ingenieros. Así que como pueden imaginar, realmente no podíamos hacer todo eso por nosotros mismos. Tuvimos que colaborar. Tuvimos que averiguar cómo involucrar a todos. Así que comenzamos a realizar encuestas de participación con nuestros equipos de ingeniería y diseño. Comenzamos a realizar horas de oficina cada segundo viernes. Tenemos 30 minutos para que todos hagan cualquier tipo de preguntas para ayudar a todos, para permitir que las personas estén allí para ellos. Y un montón de documentación. Realmente nos enfocamos los primeros meses de nuestro trabajo en preparar documentación, mantener documentación, preparar alguna documentación de cómo hacer sobre cómo colaborar, cómo actualizar, cómo deprecar. Porque realmente queremos permitir que todos no sean cuellos de botella o guardianes del sistema de diseño. Y establecimos el objetivo. Así que, sí, somos ambiciosos. Queremos llegar a más del 60 por ciento de adopción de nuestro sistema de diseño. Pero comenzamos en algún lugar. Así que basado en datos y cómo está creciendo la adopción, queríamos establecer un objetivo un poco más ambicioso. Y también, como mencioné antes, realmente nos enfocamos en la documentación.

Y junto con la documentación de cómo hacer, también trabajamos mucho en mantener la única fuente de verdad. Que para nuestro Leonardo, que es nuestro sistema de diseño, se basa en Zero Height. Zero Height es una plataforma increíble que nos ofrece un espacio donde podemos almacenar toda la documentación de componentes, donde puedes integrar Storybook, puedes integrar Figma, y puedes mantener documentación de componentes, pero también contenido, guía de estilo, patrones, documentación, fundamentos, tokens de diseño, información de marca, cualquier cosa que desees. Y esta es nuestra fuente de verdad. Así que si algo está desconectado, desarticulado en Figma o código, esto es a lo que debemos acudir. Y eso es muy importante.

También tomamos muchas iniciativas como un equipo de sistema de diseño. Pero realmente quería enfatizar el hecho de que realmente intentamos hacer pequeñas iniciativas, paso a paso, pequeños logros, un enfoque muy iterativo. Realmente intentamos no hacer cambios muy grandes, porque todavía nos movemos muy rápido. Tenemos muchas personas trabajando en esta base de código. Así que realmente no queríamos interrumpir a nadie.

Y sí, para concluir, quería decir que el sistema de diseño no se trata solo de componentes y tokens. Obviamente, necesitamos comenzar en algún lugar. Pero lo que nos dimos cuenta con el tiempo es que el sistema de diseño es un lenguaje compartido, es la creación de un lenguaje y proceso compartidos que acelera el trabajo en equipo y mantiene a todos alineados. Muchas gracias.