Hoy aprendí #3
En Eryx nos gusta compartir el conocimiento y eso es lo que hacemos en Hoy Aprendí. Descubrí tips e insights claves de nuestro equipo técnico para aplicarlos en tu día a día.
Mejorando la experiencia de desarrollo UI
Por Caro Wright
Contexto
En el desarrollo de un proyecto para uno de nuestros clientes, enfrentamos la necesidad de contar con una herramienta que nos permitiera visualizar y probar nuestros componentes de UI de manera eficaz. Queríamos asegurarnos de que los componentes funcionaran correctamente, se vieran bien y fueran consistentes en todo el proyecto. Para lograrlo, necesitábamos una solución que nos permitiera trabajar de forma más eficiente y colaborativa.
¿Cómo lo solucionamos?
Propusimos la implementación de Storybook, una herramienta que nos ayudó a desarrollar y probar los componentes de forma aislada. La elección de Storybook se basó en las siguientes ventajas que nos ofreció:
- Desarrollo y prueba aislada de componentes: Storybook nos permitió crear y probar cada componente de manera independiente, lo que facilitó la identificación y corrección de errores sin afectar a otras partes del sistema.
- Documentación y visualización clara: La capacidad de documentar y visualizar los componentes de forma intuitiva fue una de las características más útiles de Storybook. Esto mejoró la comprensión y colaboración entre los miembros del equipo de desarrollo.
- Pruebas visuales integradas: Con Storybook, logramos realizar pruebas visuales de nuestros componentes, garantizando una experiencia de usuario coherente y de alta calidad.
- Colaboración: Storybook facilitó la colaboración entre los integrantes del equipo al permitir compartir componentes de manera sencilla, fomentando así la reutilización de código.
En la implementación nos encontramos con algunos desafíos iniciales, como la curva de aprendizaje para aquellos que no estaban familiarizados con la herramienta. Además, puede requerir ajustes adicionales para adaptarse a flujos de trabajo específicos o a ciertas peculiaridades de proyectos particulares.
Más allá de eso, encontramos en Storybook una herramienta valiosa en nuestro proceso de desarrollo. A medida que continuamos familiarizándonos con todas sus funcionalidades, esperamos seguir descubriendo nuevos usos y beneficios para nuestros proyectos futuros.
Profundizando sobre TDD
Por Facu Decroix
A lo largo de mis años trabajando en Eryx, utilicé en distintas ocasiones la técnica de TDD a la hora de programar. Siempre la consideré una buena técnica para ordenar los tests y tener una buena cobertura. Sin embargo, a medida que me fui formando en el tema fui profundizando mi mirada sobre la técnica. Las siguientes son conclusiones sobre TDD que no me parecieron evidentes a primera vista.
Ventajas del uso de TDD
- Fomenta descomponer el problema en pasos chicos que son mucho más fáciles de resolver.
- Es una técnica de aprendizaje basada en feedback inmediato.
- Nos da un orden a la hora de programar. Esto hace que podamos medir cuánto tardamos en hacer cada paso y luego a partir de eso, reflexionar sobre qué tan bien estamos programando.
- Permite tener máxima cobertura de los test y nos da seguridad a la hora de refactorizar nuestro código.
Algunas observaciones sobre la técnica
- TDD nos convierte en los primeros usuarios de nuestro sistema. Toda funcionalidad que alguien pueda usar en nuestra aplicación habrá sido primero usada por alguno de nuestros test.
- Nuestros tests son otro sistema que usa el que estamos construyendo. Esto significa que podríamos necesitar que nuestro sistema tenga alguna funcionalidad que sólo sea usada por nuestros tests, y eso no está mal.
- Utilizar TDD no implica un buen diseño de nuestro sistema. Que esté bien diseñado depende de las aptitudes del programador.
- La técnica en cierta forma favorece sistemas menos acoplados, porque si el nuestro está acoplado es más difícil testear.
¿Cómo hacer mejor TDD?
- El próximo test siempre debe ser el más sencillo posible. A veces sirve empezar por tests de validaciones (test “negativos”) si el problema es muy complejo.
- En el paso 3, a veces conviene esperar un poco para hacer los refactors. Entre más pasos, la visión que tengamos del problema será más amplia y vamos a generar mejores abstracciones.
- Puede ser conveniente utilizar la técnica de mutation testing para detectar casos que nos estamos perdiendo.
Desventajas de dejar el testing para el final (muy habitual para los programadores que no utilizan esta técnica)
- Es más fácil que nos perdamos casos porque no hay tiempo o simplemente porque nos olvidamos de hacerlos.
- Es más difícil tener un orden para programar.
Creando una interfaz de a poco
Por Sergio Fedi
Contexto
¿Cómo puedo construir una GUI o representación gráfica del negocio que estoy programando de forma integral y gradual?
Cuando hacemos sistemas estamos creando entidades que aparecen en el negocio que estamos trabajando (una fintech, una exportadora, un sistema de gestión de historias clínicas, etc). Y a medida que programamos, examinamos esos objetos que creamos para debuggear, para probarlos, etc. ¿No podríamos ir creando de a poco una representación gráfica de esos objetos a medida que los vamos programando, examinando y conociendo cada vez más?
Algunas soluciones
En la Smalltalks 2023 presentaron una extensión, un toolkit a Pharo (un Smalltalk) donde podemos ir definiendo inspectores visuales para objetos arbitrarios. Es decir que a un objeto cualquiera podemos hacerle una interfaz gráfica particular. Después a esa interfaz le podemos agregar acciones propias de ese objeto. Así, podemos ir programando una GUI a medida que desarrollas y la necesitas.
Además lo presentado nos sugiere empezar escribiendo texto, donde “pensamos en voz alta” y vamos convirtiendo tus ideas en código que va funcionando. Como un Jupyter Notebook pero más interactivo y “vivo”.
Esta idea la veo desde hace un tiempo: empezamos con algo muy flexible pero poco formal y lo vamos transformando en algo más formal y funcional.
Esto se vió también en Newspeak, el año anterior.
También lo podemos ver en Notion, en cómo te permite gradualmente convertir un texto en una lista, después en una tabla y luego utilizar esos datos. Desconozco qué nivel de cómputo le podés agregar a Notion.
Hace rato que hay un vacío entre la gente que soluciona sus problemas con un archivo de texto, una lista de ToDo o una planilla y el siguiente salto es un sistema enlatado o hecho a medida.
Estas herramientas, estas prácticas, tratan de tender un puente entre ambas formas de informatizar y automatizar nuestros negocios y actividades.