Hemos visto en el post anterior cómo iniciar una reingeniería con SonarQube empezando con una redistribución funcional y un nuevo diseño de nuestra aplicación.
Ahora podemos ir un poco más profundo en el código para identificar a los flujos de tratamientos candidatos para la reestructuración. Sigue leyendo
Hemos definido nuestro proyecto de reingeniería como la reescritura de nuestra aplicación Legacy con un nuevo lenguaje o su migración a una nueva tecnología, a diferencia de una refactorización que implica la reorganización del código y la corrección de ciertos defectos con el fin de hacerlo más mantenible y reducir la deuda técnica.
También vimos, con SonarQube y el plugin SQALE diferentes planes de refactorización más o menos ambiciosos, desde la resolución de los defectos más críticos hasta reducir la deuda técnica para llevarla a un nivel (rating SQALE) ‘A’.
Sin embargo, ¿qué es lo más interesante y productivo entre un proyecto de reingeniería y una refactorización? Sigue leyendo
Una reingeniería no siempre significa la reescritura de nuestra aplicación Legacy en un lenguaje generalmente más reciente, pero, sin embargo, es la opción que hemos elegidos.
Cuando se trata ‘simplemente’ de reorganizar el código para que sea más fácil de mantener, pero sin portarlo en una nueva plataforma de software o de hardware – migración de Mainframe-Cobol a una arquitectura Unix por ejemplo – yo prefiero hablar de refactorización.
Os recuerdo que este blog no tiene pretensiones académicas, así que no voy a preocuparme de definiciones meticulosamente exactas, que conducen con mayor frecuencia en discusiones quadripelotectomias (1) entre especialistas que no tienen nada más que hacer que glosar sobre cada palabra. Sigue leyendo
Cuando se trata de retorno de inversión (ROI), no me complico la vida: mi hipótesis es que los costes de mantenimiento se reducen en una proporción igual a la reducción de la deuda técnica.
Es una hipótesis que puedes encontrar simplista y por lo tanto discutible, pero nuestra ambición no es de conseguir una precisión absoluta – sería pretencioso y poco realista – pero proporcionar los elementos que facilitan la decisión.
Y creo que el management prefiere una hipótesis simple y clara en lugar de una fórmula compleja que no es necesariamente más realista.
Sigue leyendo
Como le hemos visto en el post anterior, no he personalizado el Quality Profile de SonarQube ni el modelo SQALE, para nuestra aplicación Legacy, según nuestro contexto y la orientación que queremos para la evaluación du su deuda técnica.
De hecho, hemos utilizado los resultados ‘out of the box’ para ilustrar un posible enfoque en la valoración del coste de refactorización, y presentar al equipo del proyecto y a los managers algunas ideas y áreas de mejora.
En otras palabras, nos interesa más el proceso que los resultados, por lo menos en el contexto de estos artículos.
Veamos ahora unas propuestas de plan de acción. Sigue leyendo
Para hacer una estimación del coste de refactorización de nuestra aplicación Legacy, voy a utilizar el plugin SQALE de SonarQube, utilizado más a menudo con el fin de medir la deuda técnica.
Ya hemos presentado este plugin con una aplicación Legacy PL/SQL. Así que recordaremos solamente que el plugin SQALE se basa en el modelo de calidad SQALE, y también en un método para adaptar este modelo según diversos objetivos de negocio, la tecnología utilizada o el contexto de la aplicación. Sigue leyendo
Hemos visto en el post anterior cómo usar el dashboard SonarQube para estimar el esfuerzo de pruebas de caracterización, pruebas recomendadas por Michael Feathers en su libro “Working Effectively with Legacy Code”.
Hemos clasificado los componentes de nuestra aplicación Legacy (Microsoft Word 1.1a) en diferentes grupos de funciones: las más simples con Complejidad Ciclomática (CC) de menos de 20 puntos, las complejas y muy complejas hasta 200 puntos de CC, y finalmente 6 componentes ‘monstruosos’.
Hemos definido una fórmula basada en la Complejidad Ciclomática y un factor de legibilidad (Reading Factor%) para evaluar el esfuerzo de pruebas en cada uno de estos grupos. Sigue leyendo
Hemos presentado en los dos articulos anteriores la noción de prueba (unitaria) de caracterización propuesta por Michael Feathers en su libro « Working Effectively with Legacy Code ».
Hemos visto brevemente cómo podemos utilizar este tipo de pruebas con el fin de adquirir los conocimientos del comportamiento de las aplicaciones. Digo brevemente porque, idealmente, tendríamos que desarrollar y presentar algunas pruebas como ejemplo, pero esta serie es ya muy larga. Mejor leer el libro de Michael Feathers.
Estas pruebas facilitarán la transferencia de conocimientos de nuestra aplicación Legacy, y cualquier operación posterior de refactorización o de reingeniería será más rápida y más segura. Sigue leyendo
En nuestro post anterior, hemos hablado de la définición de Michael Feathers (en su libro « Working Effectively with Legacy Code ») explicando que la ausencia de pruebas unitarias es el factor determinante de una aplicación Legacy. El propone el concepto de prueba de caracterización para entender el comportamiento de la aplicación, es decir, lo que realmente hace, sin tratar de descubrir a través del código que se supone que debe hacer.
Pero ¿qué pasa cuando nuestra aplicación Legacy no tiene nada de pruebas unitarias? La respuesta a uno de nuestros tres escenarios – el plan de transferencia de la aplicación a otro equipo – puede hacerse escribiendo estas pruebas? ¿Es posible facilitar la transferencia de conocimientos con pruebas unitarias? Sigue leyendo
La vuelta de las vacaciones del verano nos permite reanudar esta serie de posts sobre el uso de SonarQube con aplicaciones de tipo Legacy, en este caso la primera versión de Word publicado por Microsoft en 1990.
Nos planteamos la siguiente hipótesis: Microsoft acaba de ser comprada y su nuevo propietario le pide, como consultor de calidad, recomendar una estrategia para esta versión de Word.
No creas que esto nunca sucede: empresas de software cambian de manos todos los días, y la I+D y el código del software están en el corazón de esas adquisiciones.