¿Has oído hablar de Atomic Design? ¿Qué tal Extreme Programming y Test Driven Development? Seguro que has oído hablar de React, algunas cosas, apuesto. En esta charla obtendrás una visión sobre cómo aprovechar el poder de Atomic Design para construir el producto correcto (usando React, obvio) y aprovechar Extreme Programming y Test Driven Development para construirlo correctamente (explorando React Testing Library).
Construyendo el Producto Correcto y Construyéndolo Correctamente: Extreme Programming y Atomic Design
Video Summary and Transcription
Esta charla explora extreme programming (XP) y equipos equilibrados, enfatizando la importancia de la simplicidad y la colaboración en equipo. Se discute la aplicación de prácticas de XP, como la programación en parejas y el desarrollo guiado por pruebas, junto con la organización del código frontend. Se introduce Atomic Design como una metodología para resolver problemas de diseño, y se explica el proceso de creación del recorrido del usuario e identificación de átomos. La charla también profundiza en la prueba de componentes y la finalización del recorrido del usuario utilizando XP y Atomic Design.
1. Introducción a XP y Equipos Equilibrados
Bienvenidos a esta charla sobre programación extrema y diseño atómico. Soy Rita, una desarrolladora de software en Volkswagen. Explicaré cómo construir el producto digital adecuado impulsado por el usuario utilizando interfaces de usuario de calidad y desarrollo guiado por pruebas. También hablaré sobre cómo traducir diseños a React. El Centro de Desarrollo de Software en Lisboa se inauguró en 2018, introduciendo XP y equipos equilibrados. XP, impulsado por la comunicación y la simplicidad, beneficia a los desarrolladores y a todo el equipo.
Bienvenidos a esta charla, donde les contaré un poco sobre programación extrema y diseño atómico. Primero lo primero. Hola, mi nombre es Rita. Soy una apasionada de la tecnología y también me gusta practicar deportes. También soy madre, lo que significa que cuando no estoy con mi familia, probablemente esté trabajando. Trabajo en el Centro de Desarrollo de Software de Volkswagen aquí en Lisboa y estos son mis increíbles colegas y compañeros de equipo.
Así que en esta charla, intentaré contarles un poco sobre cómo construir el producto adecuado. Desde mi punto de vista, creo que un buen producto debe estar impulsado por el usuario y debe ser un producto digital, teniendo esto en cuenta. Y debe hacerse utilizando interfaces de usuario consistentes y de calidad, porque quieres que tus usuarios se involucren con él. ¿Y cómo puedes construirlo correctamente? Bueno, debes tener pruebas para ello. Las pruebas son una parte importante del desarrollo de software. Y de hecho, son tan importantes como la forma en que se realizan. Y para mí, la mejor manera de hacer pruebas es mediante el desarrollo guiado por pruebas. Esto significa escribir tus pruebas antes de comenzar a escribir cualquier tipo de código de producción. Por otro lado, y dado que esto es el React Summit, por supuesto que quieres pasar de los diseños a React. Entonces, quieres tener una forma fácil de traducir lo que tienes desde tus diseños a React. ¿Cómo podemos lograr esto? Esto es lo que me estoy preparando para contarles y hablarles. Así que el Centro de Desarrollo de Software en Lisboa. Se creó en 2018. Fue el primer centro de desarrollo que Volkswagen abrió fuera de Alemania. Y eligieron hacerlo en Lisboa. No lo hubiera pensado. Y les agradezco por eso, así que me uní. Ya conocía y ya había hecho desarrollo guiado por pruebas y solía trabajar en un marco ágil. Digamos que aportaron algo nuevo, algo diferente, que fue XP y equipos equilibrados. XP significa programación extrema y fue creado en 1996 por Kent Beck. Es una forma ágil de desarrollar software. Está dirigido principalmente a los desarrolladores, pero el resto del equipo de desarrollo también puede aprovechar mucho de lo que XP representa y lo que abarca en su núcleo y qué abarca en su núcleo. Está impulsado por cinco valores fundamentales, el valor de la comunicación, mantener el chat y la conversación en marcha dentro de tu equipo, porque con esto, puedes compartir información, puedes transferir conocimientos de una persona a otra,
2. Simplicidad y Colaboración en Equipo
Construye el producto de la manera más sencilla posible para obtener comentarios frecuentes de los usuarios. Ten el coraje de descartar lo que no cumple con las necesidades del usuario. Respeta y valora las opiniones de todo el equipo.
3. Prácticas de XP y Organización del Código Frontend
Para aplicar los valores de la programación extrema (XP), nos enfocamos en la programación en pareja y el desarrollo guiado por pruebas. La programación en pareja nos permite compartir conocimientos y comunicarnos de manera efectiva. El desarrollo guiado por pruebas nos ayuda a construir solo lo necesario. Trabajamos en equipos integrados y equilibrados compuestos por diseñadores, gestores de productos y desarrolladores. Los diseñadores actúan como puente entre el equipo y los usuarios, comprendiendo sus puntos problemáticos y proponiendo soluciones. Los gestores de productos se encargan de los aspectos financieros y desglosan las funcionalidades en historias manejables. Como desarrolladores, evaluamos la viabilidad y actuamos como guardianes de la tecnología. Trabajando juntos, logramos la magia. En el Centro de Desarrollo de Software (SDC), he trabajado en cuatro productos utilizando React como el framework de frontend. Solíamos seguir el desarrollo impulsado por funcionalidades, pero a medida que los productos crecieron, necesitábamos una mejor manera de organizar nuestro código frontend.
4. Diseño Atómico y Solución de Problemas de los Concesionarios
El diseño atómico es una metodología creada por Brad Frost en 2013. Consiste en cinco niveles de elementos: átomos, moléculas, organismos, plantillas y páginas. Estamos aplicando esta metodología para resolver un problema que enfrentan los concesionarios de automóviles. Necesitan realizar un seguimiento del estado de cada pedido y comunicarlo a los clientes. A través de entrevistas con usuarios, identificamos tres suposiciones clave: los concesionarios desean conocer el estado del pedido, estar actualizados al respecto y compartir la información con los clientes. Nosotros, como desarrolladores, hemos confirmado que podemos extraer e integrar la información necesaria en el producto existente de los concesionarios.
Ingresa al diseño atómico. ¿Qué es? Es una metodología de diseño que se utiliza para crear y mantener cualquier cosa en el sistema de diseño. Fue creado por Brad Frost en 2013. Está compuesto por cinco niveles diferentes de elementos.
Ten en cuenta que este es un marco de diseño, por lo que vamos a hacer una adaptación de un marco de diseño a React. ¿Cómo está estructurado? Hay átomos, que son los elementos más básicos de todos. Si combinas átomos, obtendrás moléculas. Si combinas moléculas con otros átomos, o eventualmente moléculas y organismos, obtendrás organismos. Y cuando defines, cuando construyes el diseño y decides dónde va cada cosa, tienes una plantilla. Y cuando seleccionas los organismos y los colocas en tu plantilla, obtienes páginas. Es un flujo lineal para construir tu interfaz de usuario y es bastante fácil. Teniendo esto en mente, te contaré la experiencia que estamos teniendo actualmente en el SDC. Estamos tratando de resolver un problema o lo que percibimos como un problema de los concesionarios que venden automóviles. Imagina que eres un concesionario, vendes un automóvil. Vendes otro automóvil mañana a un cliente diferente y mañana y mañana y mañana. Entonces, vendes muchos automóviles porque eres bueno en ello. En promedio, los concesionarios venden alrededor de 20 automóviles al mes y cada uno de estos automóviles, cada uno de estos pedidos, tarda alrededor de tres meses en completarse. Por lo tanto, dentro de este período de tiempo, el concesionario necesita realizar un seguimiento del estado del pedido. ¿El automóvil está aquí, está a punto de llegar? ¿Está retrasado? Bueno, si no te comunicas con tu cliente, es muy probable que el cliente recoja el teléfono y llame para preguntar: `Oye, ¿dónde está mi automóvil?`. Y eso es un problema porque entonces el concesionario tiene que poder encontrar la información sobre el pedido de ese cliente muy, muy rápido porque no quieres que se sientan frustrados. ¿Cómo puedo contarte todo esto? Porque hicimos muchas entrevistas con los concesionarios para comprender los puntos problemáticos y las necesidades que tienen. Con eso, nuestros diseñadores formularon tres suposiciones. La primera es que los concesionarios desean conocer el estado de sus pedidos. La segunda es que desean estar actualizados sobre ese estado. Y la tercera es que desean poder compartir esa información con los clientes. Dado eso, creemos que podemos idear algo. Nosotros, los desarrolladores, verificamos si sería posible obtener información de los pedidos. Sí, porque podemos integrarnos con sistemas que son realmente antiguos, pero podemos extraer información y proporcionarla a los concesionarios. ¿Podemos integrarlo en un producto que ya utilizan los concesionarios, para que esto no sea solo otra herramienta que tengan que usar? Sí,
5. Creando el Recorrido del Usuario e Identificando Átomos
En este caso, los diseñadores crean el recorrido del usuario, específicamente el recorrido del concesionario. El concesionario abre un navegador y ve un panel de control con información sobre todos sus pedidos. Pueden ver los detalles de cada pedido y verificar su estado. Para lograr esto, utilizamos la biblioteca de pruebas de React para el desarrollo impulsado por pruebas y el Marco Atómico para un diseño de interfaz de usuario coherente.
6. Átomos, Moléculas y Pruebas
Los átomos son componentes indivisibles que forman la base de la interfaz de usuario. Implementa pruebas para verificar elementos específicos y cumplir con la implementación. La programación en pareja permite pruebas más específicas y código objetivo. Utiliza componentes simulados para mayor flexibilidad. Las moléculas son átomos unidos para proporcionar funcionalidad, como la barra de búsqueda y el progreso del pedido.
Subiendo en la escala atómica, tenemos las moléculas. Moléculas. ¿Qué son las moléculas? Las moléculas son átomos unidos. Entonces, hacen algo que aporta funcionalidad.
7. Progreso del Pedido y Organismos
El progreso del pedido tiene dos elementos: el texto en tránsito y el icono de tránsito. Los organismos son una combinación de átomos, moléculas y otros organismos que aportan valor al usuario. La lista de pedidos debe incluir el texto 'todos los pedidos' y componentes para la barra de búsqueda, los filtros y la tabla de pedidos. La simulación puede encapsular todo y proporcionar una vista clara, pero puede alejarse de la experiencia del usuario e introducir un renderizado superficial. Es importante encontrar un equilibrio y considerar la decisión del equipo.
A continuación, en la jerarquía, los organismos. Los organismos son una combinación de átomos, moléculas e incluso otros organismos. Y lo más importante de todo, aportan valor al usuario. Entonces, con el valor del usuario, ¿qué tienes? Tienes estos dos elementos principales. Entonces, la lista de pestañas y la lista de pedidos. Pero luego, construyamos una prueba para ello. Entonces, la lista de pedidos, necesita tener el texto que dice 'todos los pedidos' y necesita tener los componentes para la barra de búsqueda, los filtros y la tabla de pedidos. Suena bien. Pero luego lo estás simulando. Así que en este momento, necesitas poder entender y decidir qué quieres hacer, si simular o no simular. Así que una lista de pros y contras. Cuando estás simulando, es realmente, realmente bueno porque puedes encapsular todo. No necesitas conocer los detalles de los elementos que estás utilizando debajo del árbol y obtienes una vista clara de lo que estás utilizando. No puedes hacer trampa. Entonces, si quieres tener un texto, necesitas tener un texto, no un párrafo que diga texto. Y es realmente, realmente fácil para que los nuevos miembros del equipo se familiaricen con los nuevos conceptos. Sin embargo, nos alejamos un poco de la user experience. Tenemos un poco de renderizado superficial. Y a veces las simulaciones pueden ser complicadas. Especialmente si estás utilizando bibliotecas de terceros. Nuevamente, es una decisión del equipo elegir lo que es mejor. Y lo que puedo recomendarte es que encontrarás tu equilibrio si sigues este camino. Por un lado, tendrás pruebas unitarias.
8. Pruebas de Componentes y Recorrido del Concesionario
Por un lado, para las pruebas unitarias, simula los componentes para asegurarte de que estás utilizando los correctos. Por otro lado, para las pruebas de integración, renderiza los componentes para verificar su uso correcto. Las pruebas que se asemejan a tu software te brindan más confianza. Un ejemplo de prueba para el organismo de la lista de pedidos verifica la presencia del encabezado, el contenido de las filas y un botón clickeable que redirige a una página diferente. Las plantillas y páginas se crean colocando organismos en el diseño definido. La página de detalles consiste en átomos, moléculas y organismos. Una prueba para el recorrido del concesionario verifica la presencia del panel de control.
Por otro lado, tendrás pruebas de integración. Entonces, para las pruebas unitarias, debes simular todos ellos. Esto te permitirá asegurarte de que estás utilizando los componentes correctos para construir tu producto. Pero luego, por otro lado, para las pruebas de integración, debes renderizarlos todos, porque así estarás seguro de que los estás utilizando correctamente. Y esto se asemeja un poco, o esto nos lleva de vuelta a una cita de Ken C. Dodds, el creador de la biblioteca de pruebas de React. Así que cuanto más se asemejen tus pruebas a tu software, más confianza te darán. Y eso es totalmente cierto. ¿Y por qué? Porque ahora podemos crear una prueba para el organismo de la lista de pedidos, en la cual, okay, sabemos que en la ruta tenemos la lista de pedidos. Y sabemos que eventualmente, cuando tengamos el enlace que nos llevará al pedido, estaremos en la página de detalles. Entonces, cuando abrimos la página o cuando renderizamos la página, esperamos que esté el encabezado de todos los pedidos. Luego esperamos que se muestren los contenidos de las filas. Por ejemplo, si estoy comprando un auto, espero que haya un botón de enlace para ver los detalles, y luego hago clic en él. Y cuando hago clic en él, me redirigen a una página diferente. Así que esto es bueno. Esta es una prueba valiosa. Esto se asemeja a cómo el usuario interactúa con tu software. Para completar, y para resumir, las plantillas y páginas. Si defines el diseño, colocas los organismos allí, obtienes una página. No puede ser tan simple como eso. La otra página que tenemos en nuestro design es la página de detalles. Se ve así. Está compuesta también. Tiene átomos, tiene moléculas y tiene organismos. Perfectamente bien. No vamos a profundizar en eso. Volvamos al recorrido del concesionario. Podemos escribir una prueba para el recorrido del concesionario, y se vería algo así. Renderizaste el panel de control, esperas
9. Completando el Recorrido del Usuario
Esperas ver las pestañas, todas las órdenes, la barra de búsqueda y los filtros en el panel de control. Te gustaría ver información de la tabla, obtener la etiqueta DRV para una fila e ir a la página de detalles. Al hacer clic en el botón de retroceso, vuelves a la página de todas las órdenes, completando así el recorrido del usuario. XP con Atomic Design permite entregar software de alta calidad con interfaces de usuario consistentes más rápido que nunca.