Aplicación Legacy – Refactoring con el plugin SQALE (II)

LegacyTechDebtRefactoring3Como 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

Aplicación Legacy – Refactoring con el plugin SQALE (I)

Application Legacy - Refactoring Technical Debt with the plugin SQALE SonarQubePara 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

Aplicación Legacy – ¿Refactorización o reingeniería? (VII)

Qualilogy Legacy Application Refactoring ReengineeringHemos 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

Aplicación Legacy – ¿Refactorización o reingeniería? (VI)

Qualilogy -Application Legacy - Effort de testHemos 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

Aplicación Legacy – ¿Refactorización o reingeniería? (V)

Legacy ou Reengineering - Tests de caracterisationEn 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

Aplicación Legacy – ¿Refactorización o reingeniería? (IV)

Qualilogy-Legacy-Reengineering-RefactoringLa 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.

Sigue leyendo

Aplicación Legacy C – ¿Refactorización o reingeniería? (III)

Word_Refactoring_Reingenierie3Tenemos esta aplicación Legacy C, la primera versión de Word publicada por Microsoft en el año 1990, para la cual se propone cuantificar el coste de diferentes estrategias: refactorización o reingeniería, por el mismo equipo de desarrolladores o por un nuevo equipo y por tanto, con una transferencia de conocimiento. Sigue leyendo

Madrid DevOps – Integración Continua

Madrid_DevOps2Madrid DevOps es un grupo de profesionales interesados en … DevOps, como se puede imaginar. Hay un ‘Meetup Group’ donde encontrar noticias, principalmente de nuevas reuniones cada mes.

El 10 de abril, la charla trataba de ‘Integración Continua’, con Manuel Recena Soto y Antonio Manuel Muñiz de ClinkerHQ. Les hice algunas preguntas acerca de su presentación, que se puede ver en https://speakerdeck.com/clinkerhq/integracion-continua. Sigue leyendo

Aplicación Legacy C – ¿Refactorización o reingeniería? (I)

WordCLegacy_UseCases1Continuamos esta serie sobre el análisis del código fuente de Word 1.1a, publicado por Microsoft en 1990.

En el primer post, hemos visto las métricas cuantitativas de tamaño, de complejidad, el nivel de comentario y de duplicación. El segundo post fue dedicado a los diferentes ‘Issues’ Blocker, Critical, Major et Minor. Sigue leyendo