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