Muy buenas, soy Miguel y para hoy les traigo este nuevo post.
Alebrijes son esculturas de arte popular mexicano de colores brillantes de criaturas fantásticas. Los alebrijes son animales muy extraños y desconocidos.
Una nueva historia de usuario viene para arreglarse, aparentemente un cambio muy pequeño, pero como parte de los requisitos tienes que cambiar la clase heredada, sí, esa clase que nadie quiere tocar y que todos temen, ¿te suena familiar?
Después de leer la historia, todos estuvieron de acuerdo en 3 puntos, crees que puedes hacerlo más rápido, pero quieres ser cauteloso y dices 3.
Cuando comienza el sprint, estás muy emocionado de hacer el cambio, abres el código y boom, encontraste un alebrije. ¿Qué falafal está pasando aquí ?, esta historia requiere más cosas de las que pensaba inicialmente, ¿Cómo voy a poder terminar esto? y ni siquiera puedo entender el código.
Cada situación es diferente, y no hay una fórmula mágica para lidiar con estas bestias míticas, pero comencemos con la premisa de que obtuviste una pieza de código muy antigua con documentación cero, pruebas de unidad cero y sin seguir los patrones de arquitectura, convenciones y mejores prácticas para Android.
Con eso en mente, aquí están algunas de las cosas que puede hacer:
Índice
Mejora de la documentación
¿Cuánta documentación necesitamos? Solo lo que puedas mantener actualizado. Hágalo simple, pero no demasiado simple. Agregue suficientes detalles para comprender cómo funciona la implementación.
Empiece por crear un diagrama sencillo. Puede ser un diagrama simple con cuadros y sus relaciones. Esto ayudará a comprender qué componentes están involucrados. Si los autores del código aún están disponibles, involúcrelos.
Después del diagrama básico, puede crear un flujo de navegación, un diagrama de clases de alto nivel y diagramas de secuencia para comprender el flujo, las dependencias, los comportamientos y las responsabilidades de cada componente.
Cuando la función incluye una lógica empresarial compleja, utilice el depurador y el registrador para comprenderla mejor. Documente todos sus hallazgos.
Empiece a documentar el código:
- Métodos públicos. Comience con métodos públicos. Esos son los que están expuestos a invocadores externos y requieren una buena documentación.
- Excepciones. Documente las posibles excepciones que generarán los métodos.
- Especificaciones ejecutables mediante pruebas unitarias. Esto aumentará continuamente con cada iteración. Intente seguir un patrón en el que especifiquemos claramente los escenarios bajo prueba y el comportamiento esperado. Una convención de nomenclatura popular Should_ExpectedBehavior_When_StateUnderTest.
Haga una lista de tareas pendientes para mejorar el código. Los TODO se pueden incluir en el código o usando alguna página wiki. La próxima vez que alguien tenga algo de tiempo libre, puede ir a la lista y elegir uno de los artículos.
Mejora de la estimación
No te grites en el pie, prepárate antes del aseo. Necesita suficiente tiempo para trabajar en código heredado. Necesitamos ser lo más precisos posible. No queremos introducir más deuda técnica o empeorar el código.
Empiece por leer y comprender la historia del usuario.
Identifique los cambios necesarios para lograr la nueva funcionalidad.
Cuando la historia tenga un gran impacto en el código, divídala en pequeñas tareas pendientes.
Estime las tareas tecnológicas necesarias para completar la historia del usuario. No olvide incluir pruebas de integración o preparación de datos cuando sea necesario.
Mejorando las pruebas
Sin pruebas, no hay forma de saber si estamos rompiendo la funcionalidad existente. No confíe en el código, sin incluir las pruebas.
Pero, ¿por dónde empiezo si la mayor parte del código está en las vistas, en métodos privados, funciones estáticas y clases finales?
Roboeléctrico
Roboeléctrico le permite ejecutar pruebas de visualización sin un emulador o dispositivo físico. Esto le ayudará a escribir pruebas para las vistas sin instalar la aplicación. Puede probar actividades o fragmentos de forma aislada.
Robolectric amplía el marco de Android con un gran conjunto de API de prueba. Robolectric utiliza el concepto de oscuridad para ampliar el comportamiento de un componente del sistema operativo Android. Puede crear sus propias implementaciones de sombras personalizadas.
Kotlin y Mockk
Con la ayuda de Kotlin y Mockk debería poder probar métodos de utilidad estáticos, inicializadores estáticos, clases finales, métodos privados. Powerbock es una muy buena opción si se le permite usar solo java.
Mejorando la calidad del código
Podemos comenzar con pequeños refactores para mejorar la legibilidad y el mantenimiento del código. Podemos comenzar con cambios como cambiar el nombre de clases, variables y métodos.
Esto nos ayudará a comprender mejor la implementación para que podamos proceder con refactores más grandes.
Haga pequeñas relaciones públicas al hacer sus cambios. Si envía un gran PR, es muy probable que los revisores no puedan seguir los cambios. Además, incluya en la descripción del PR el problema que está tratando de resolver y la solución.
Problema / Requisito
Incluya una descripción del problema o requisito a resolver
Solución
Descripción de la solución
Refactorización
Los próximos refactores requerirán una prueba de regresión completa por parte de su QA, tenga mucho cuidado sobre cuándo hacer estos cambios.
- Separe la lógica de la interfaz de usuario de la lógica de la aplicación. Mueva la lógica fuera de las Vistas. Hoy en día tenemos
MVP,MVVM,MVI, pero todos tienen la misma intención Separación de intereses. Intente mantener las clases de vista ajustadas para evitar problemas relacionados con el ciclo de vida. - Componentes de
Life Cycle Aware. Mueva la lógica desencadenada por eventos del ciclo de vida fuera de la actividad / fragmento. Esto le ayudará a mantener su código más organizado y fácil de mantener. - Utilice LiveData y Flow para notificar cambios de datos a la vista.
- Utilizar Coroutines para simplificar el manejo de sus operaciones en segundo plano.
- Mueva la lógica de acceso a los datos a los repositorios.
- Extrae código a nuevas clases usando kotlin. Kotlin ayudará a simplificar y hacer que el código sea más seguro con el soporte de Java.
- Utilice
DI. Encapsular el comportamiento relacionado y exponerlo mediante interfaces. Esto le ayudará con las pruebas.
Componentes de arquitectura y guía para la arquitectura de aplicaciones
Android ya tiene una guía con las mejores prácticas y la arquitectura recomendada para ayudarlo a diseñar aplicaciones sólidas, probables y fáciles de mantener.
No necesitas reinventar la rueda, usa el Guía de Android para la arquitectura de aplicaciones y Componentes de la arquitectura biblioteca de colecciones.
El código funciona de forma coherente en todas las versiones y dispositivos de Android para que podamos centrarnos en lo relacionado con nuestro dominio empresarial.
Siga la regla de los Boy Scouts
Seguimos haciendo pequeños cambios en el código para mejorarlo. El código mejorará gradualmente. Con esta regla, veremos al equipo cuidando el sistema como un todo, en lugar de cuidar individualmente las partes que construyen.
Y eso es todo, espero que poco a poco nos vayamos deshaciendo de esos alebrijes, y no agreguemos más deuda técnica durante el proceso :).
Espero que te haya sido de utilidad. Gracias por leer este post.
Añadir comentario