La refactorización en el frontend es esencial por diversos motivos. En primer lugar, la optimización de la experiencia de usuario, un frontend renovado puede agilizar la interacción del usuario, reducir los tiempos de carga y mejorar la accesibilidad.
La modernización del diseño es otro factor crucial, ya que las tendencias y estándares de diseño evolucionan constantemente y actualizar la apariencia de la interfaz puede mantener la aplicación atractiva para los usuarios. Además la refactorización de la parte más visual, conlleva una mejora del código subyacente, lo que no solo facilita el mantenimiento futuro, sino que también puede optimizar el rendimiento y la escalabilidad del sistema.
En nuestro dashboard un claro ejemplo de mejora de usabilidad lo encontramos en la revisión manual de los usuarios. Actualmente es posible elegir entre diversos estados, así como rechazar o aceptar un usuario añadiendo los motivos de esa aceptación/rechazo.
En este proceso de mejora del diseño del dashboard, nos hemos encontrado con algunos retos, ¿qué hacer con frameworks acoplados a nuestro diseño? ¿qué pasa con elementos custom que se repiten a lo largo del código con pequeñas variaciones?
Bootstrap
Bootstrap es un framework que facilita y agiliza los desarrollos frontend es por esto que al ser un equipo pequeño se decidió usarlo.
Al rediseñar el frontend, nos hemos encontrado con la rigidez de Bootstrap; adaptar un elemento card, por ejemplo, al nuevo diseño implicaba sobreescribir las clases del componente de Bootstrap. Encontrar las clases correctas que se deben modificar, no es trivial, además el código se vuelve menos legible ya Bootstrap utiliza reglas CSS con una especificidad considerable para garantizar los estilos definidos por el framework se apliquen correctamente y no sean fácilmente anulados por estilos personalizados o heredados.
Como solución de compromiso, hemos tratado de deshacernos de la dependencia de Bootstrap en todos nuestros componentes. Aún así se han mantenido ciertos componentes, como las tablas (la navegación en una tabla de datos no es trivial e implementarla con un equipo pequeño sería como reinventar la rueda), intentando adaptarlas lo máximo posible al diseño.
Componentes reutilizables
En el diseño de aplicaciones web modernas, nos encontramos con elementos comunes como los botones que se repiten en múltiples vistas y componentes. Desde un botón básico que puede contener texto, una imagen, o estar deshabilitado, hasta distintas variaciones según las necesidades del diseño y la funcionalidad.
La repetición de código al maquetar el mismo botón varias veces puede generar fragmentación en el proyecto y dificultar la gestión de cambios, como la modificación de colores o espaciados, que requieren buscar y actualizar cada instancia del botón en todo el código.
Para abordar este desafío, resulta fundamental la creación de componentes reutilizables. Al encapsular la lógica y el aspecto de un botón en un componente, reducimos la duplicación de código y aceleramos el desarrollo de la aplicación.
Sin embargo, la creación de componentes reutilizables puede ser una tarea exigente, especialmente para equipos pequeños. El tiempo necesario para diseñar y ajustar un componente reutilizable con todas sus posibles variaciones puede ser significativo. Además, a medida que el componente evoluciona y se adapta a nuevas necesidades, su complejidad puede aumentar, lo que requiere un mantenimiento continuo.
Diseño vivo
El diseño de un componente o vista es un proceso dinámico: a medida que se avanza en la implementación, pueden surgir cambios debido a dificultades técnicas o a la retroalimentación del usuario al interactuar con la experiencia de usuario (UX).
Es fundamental determinar cuándo compartir el diseño con el equipo de desarrollo para su implementación. Si se comparte en una etapa muy temprana, como por la necesidad de entregar la funcionalidad al cliente, los cambios posteriores en el diseño pueden generar impactos significativos en la implementación. Es posible que el código ya no se ajuste a los requisitos de la nueva vista o que los cambios no sean bien recibidos por el equipo de desarrollo, lo que puede generar frustración en todo el equipo.
Por lo tanto, cuanto más maduro esté un diseño antes de llegar al equipo de desarrollo, menos iteraciones de desarrollo/revisión serán necesarias para finalizar una vista.
Red de test
Aunque los cambios pueden ser principalmente visuales, el refactorizado no se limita solo a la parte de estilos (CSS y HTML). A menudo, implica desacoplar código para mantener la cohesión y la responsabilidad de los componentes, lo que resulta en la creación de componentes más simples y fáciles de mantener.
Tener un número limitado de pruebas al realizar un refactor puede ralentizar significativamente el proceso. La práctica de «editar y rezar» (edit and pray) se convierte en una realidad, donde los cambios realizados no garantizan la integridad del código existente. Esto requiere una exhaustiva revisión de calidad (QA) que abarque todos los posibles casos para asegurar que la funcionalidad previa se mantenga intacta.
Para evitar este escenario, una estrategia efectiva es ir desarrollando las pruebas a medida que se realiza el refactorizado. Aunque esta aproximación puede brindar mayor seguridad, se debe tener en cuenta que si el código está altamente acoplado, es extenso o depende de múltiples componentes, el proceso de refactorización puede volverse lento e incluso frustrante. El código altamente acoplado suele ser complejo de probar y puede requerir un enfoque cuidadoso para desentrañar sus dependencias.
Nomenclatura
Al maquetar una página web, el nombre que asignamos a las clases juega un papel crucial. Las clases con nombres poco descriptivos, como «clase1» o «estilo2», carecen de significado y no proporcionan información sobre la función o propósito del código, lo que dificulta su comprensión y mantenimiento a largo plazo.
Es importante encontrar un equilibrio en la especificidad de los nombres de las clases. Nombres excesivamente detallados pueden acoplar la clase de manera estrecha a la estructura del HTML, lo que puede hacer que el código CSS sea frágil y complicado de mantener. Por ejemplo, utilizar clases como «boton-rojo-ancho» puede resultar problemático si se decide cambiar el diseño del botón en el futuro.
Por último, es recomendable evitar definir estilos directamente en el HTML. Esto dificulta el proceso de refactorización del código, ya que los estilos no están asociados a una clase específica y pueden ser difíciles de encontrar en la sección de estilos. Mantener los estilos en archivos CSS separados facilita la organización y el mantenimiento del código, ya que todos los estilos relacionados con un componente o diseño específico se encuentran en un solo lugar.
Conclusión
En conclusión, la refactorización en el frontend es una práctica esencial para mejorar la experiencia del usuario, optimizar el rendimiento del sistema y garantizar la mantenibilidad del código a largo plazo. Desde la modernización del diseño hasta la creación de componentes reutilizables y una sólida red de pruebas, cada paso en el proceso de refactorización contribuye a un frontend más eficiente y adaptable. Reconocer los desafíos, como la rigidez de los frameworks y la necesidad de una nomenclatura clara, nos permite abordar los problemas de manera proactiva y asegurar un desarrollo frontend ágil y sostenible. En última instancia, la refactorización no solo mejora la calidad técnica del código, sino que también eleva la calidad de la experiencia del usuario, lo que la convierte en una práctica fundamental para cualquier proyecto de desarrollo frontend.
Ver todas las entradas 
