Uno de nuestros primeros pasos en el onboarding con un nuevo cliente, es el análisis del código de programación existente. En este análisis, verificaremos si el código existente es escalable y se puede mantener en el tiempo para que siga creciendo. De esta forma revisaremos la calidad de código y estableceremos prioridades para la gestión interna de estas soluciones.
Para esto analizaremos estos 7 puntos esenciales que nos permiten saber si un código de programación Flutter es escalable:
Arquitectura de código de programación:
Nos permite separar el código por funcionalidades y responsabilidades, lo cual facilita el mantenimiento, la escalabilidad y la ausencia de bugs en la base de código.
En FlutterLab, aplicamos Flutter Clean Architecture, permitiéndonos dejar el código separado tanto por funcionalidad como responsabilidad, preparándolo para su crecimiento.
Versión de Flutter y paquetes
Puede que sea evidente, pero utilizar la última versión estable de Flutter, nos permite aprovechar las últimas funcionalidades añadidas y los más recientes parches de bugs. A su vez, comprobamos que los paquetes de los que depende el proyecto, estén actualizados a su última versión, y verificar que ninguno está deprecado.
Realizar esto, nos permitirá reducir la deuda técnica en un futuro e invertir ese tiempo en tener nuestro código al día.
Archivos extremadamente largos
Otra bandera roja que es frecuente encontrar, son archivos extremadamente largos. En un caso de un archivo con más de 1.000 líneas, será complicado ejecutar cambios y mejoras en un futuro, por lo que deberíamos modularizar el código y distribuirlo dentro de archivos según guía nuestra arquitectura.
Gestor de Estados
Ocasionalmente, podemos encontrarnos con un código de programación que carece de Gestor de Estados, esta parte es muy crítica dentro del proyecto. El Gestor de Estados nos permitirá controlar el ciclo de vida de nuestros widgets y los diferentes estados por los que pasará nuestro UI.
En código realizado por alguien inexperto, suele ser común integrar la lógica dentro de los archivos encargados de UI, lo que provoca un gran caos en la gestión de estados dentro del proyecto.
En FlutterLab, utilizamos el patrón BLoC para gestionar la lógica de negocio dentro del código.
CI/CD
Hacer compilaciones y/o subidas de un proyecto Flutter a las plataformas de publicación de apps o un servidor web, va a ser algo que vamos a realizar frecuentemente inevitablemente cuando trabajamos con un sistema ágil de desarrollo, por este motivo, si facilitamos esta distribución lo máximo posible, nos ahorraremos tiempo y esfuerzo a lo largo del desarrollo.
Aparte de la distribución, un buen CI/CD nos permitirá hacer tests automáticos y forzar el formateado de código, los cual nos permitirá crear un filtro cada vez que queramos mezclar nuevo código dentro de nuestra app.
Testing
Pese a ser una asignatura pendiente dentro de muchos proyectos, la existencia de tests dentro de nuestro código, debe ser algo obligatorio si queremos mantener nuestro código bajo control, y que al momento de verificar que cuando incluyamos nuevas funcionalidades, no dañemos las anteriores.
Lo mínimo que recomendamos implementar son test unitarios, pero deberíamos implementar también test de widgets y de integración, si queremos asegurarnos que el código que estamos generando es de calidad, y siempre lo será.
Linting – Flutter Analyze
Ejecutar una herramienta de análisis de código estático en una buena forma de ver si se están ejecutando buenas prácticas dentro del código y nos puede dar un camino de problemas que hay que solucionar dentro del formato de código.
Te puede interesar: MVP: Qué es y su importancia en la creación de productos
Conclusión
Mantener un código escalable puede ser la cosa más importante que puedes hacer para tu app. Implementar las características de arriba, permitirá que tu código siempre mantenga una alta calidad, independientemente de su evolución en el futuro.
