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.
Aplicaciones SQALE y Legacy
Hoy en día, cualquier aplicación de más de 3 años se considera ‘Legacy’, sobre todo si no tiene una cobertura de pruebas unitarias. En este caso, ‘Edit and Pray’ o ‘Modificar y Rezar’ (para que sigue funcionando), explica Michael Feathers en su libro « Working Effectively with Legacy Code ».
Ahora, no vamos a utilizar el modelo SQALE de la misma forma para una aplicación J2EE con tres años de vida, para nuestra aplicación en C Word 1.1a de 20 años, o para una aplicación Cobol aún más antigua que ha pasado por las manos de varios equipos diferentes, posiblemente en offshore.
También hay que considerar el tipo de aplicación: aquí tenemos un software de una suite de oficina vendido por un editor de software, no es en absoluto lo mismo que una aplicación J2EE desarrollada internamente para satisfacer necesidades empresariales o con un paquete de software como SAP. Por ejemplo, nuestra aplicación está escrita en C y no utiliza base de datos: pues los factores de ‘rendimiento’ y de ‘seguridad’ no tendrán el mismo peso que para una tradicional aplicación de gestión.
SQALE y el seguimiento de la deuda técnica
Otro factor a tener en cuenta: como explica Freddy Mallet de SonarQube en este vidéo (en francés): « La deuda técnica, es evitar despertarse después de 5 años con un código con el que ya no puedes hacer nada sin que te cuesta un brazo y un ojo de la cara ».
Un uso común del plugin SQALE es para monitorear y controlar la deuda técnica en las diferentes versiones, a lo largo del tiempo, con el fin de evitar que llega a un umbral más allá del cual empieza a ser un peso insoportable y demasiado caro. O, como se explica en este articulo : « No sirve empezar a limpiar el suelo si no has reparado primero la fuga de agua ».
En nuestro caso, sólo tenemos una única versión, así que de nuevo voy a indicar que nuestro uso del plugin SQALE es únicamente para evaluar un esfuerzo de refactorización, y sin modelo personalizado pero procediendo directamente los resultados ‘out of the box’.
En el contexto de este artículo, presento estos resultados simplemente para ilustrar el enfoque de evaluación del coste de la refactorización de una aplicación Legacy. Estimación ‘a priori’, incluso antes de consultar al equipo de proyecto o el management.
SQALE en el dashboard SonarQube
Tengo mi propio dashboard en SonarQube, customizado con un widget para mostrar los siguientes datos del plugin SQALE:
Figura 1 – Datos SQALE de la Deuda Técnica en nuestra aplicación Legacy
1 238.7 días para absorber la deuda técnica. Con una tasa 18.5 días de trabajo al mes, esto representa 69.4 meses o, para un equipo de 5 personas, 13.9 meses/hombre.
Así que se necesita casi 14 meses para superar esta deuda técnica. No hace falta imaginar que esto no es aceptable para los managers: significa detener cualquier desarrollo, cualquier nueva versión durante más de un año. Ningún cliente, ningún usuario estaría de acuerdo con tal decisión.
Ahora, nuestro objetivo no es eliminar el 100% de esa deuda, pero hacer un esfuerzo para reducirla de manera que la carga de la deuda sea aceptable, y que la correspondiente reducción en los costes de mantenimiento sea mayor que el coste de refactorización. De hecho, la decisión de hacer una refactorización se basa por lo general en el ROI (retorno de inversión), o la esperanza de ahorrar costes de mantenimiento.
¿Se puede considerar un esfuerzo razonable, con acciones limitadas pero concretas de refactorización, con un retorno de inversión? Esto es lo que voy a mirar con otros datos configurados en mi dashboard.
En primer lugar, veo que el ‘SQALE Rating’ es igual a ‘B’. Esto demuestra el peso de la deuda técnica en relación con toda la aplicación. Otro widget del portal SQALE de SonarQube me da la distribución de la deuda técnica en diferentes archivos.
Figura 2 – Distribución del SQALE Rating por archivo
Tenemos 12 archivos con una deuda técnica muy alta, y si enumero estos archivos, voy a encontrar algunos programas ya identificados previamente como los más complejos, con el mayor número de líneas de código (LOC) y/o con funciones complejas y de gran tamaño.
Figura 3 – Programas con mayor coste de remediación SQALE
Otra forma de comprobar la distribución de la deuda técnica en todos los archivos de la aplicación: el Bubble Chart (me encanta este gráfico). Puedo elegir las métricas que quiero cruzar:
- los días de deuda técnica en el eje Y;
- el número de líneas de código en el eje X;
- la Complejidad Ciclomática como tamaño de la burbuja.
Figura 4 – Technical Debt x Cyclomatic Complexity x Lines of Code
Se puede observar en esta figura, el archivo ‘fltexp.c’ con la deuda técnica máxima para un programa – 23 días de refactorización – dentro de las 2 600 líneas de código y los 740 puntos de Complejidad Ciclomática.
Claro que algunos van a decirme de nuevo que el número de líneas de código (LOC) no es una medida fiable del tamaño de una aplicación, pero después de jugar con diferentes combinaciones de métricas, el número sigue siendo la métrica con más correlacion con la deuda técnica, y por lo tanto, un factor a tener en cuenta.
Por ejemplo, en el Bubble Chart a continuación, elegí la complejidad ciclomática (CC) por función como medida del tamaño de la burbuja.
Figura 5 – Technical Debt x Cyclomatic Complexity/Function x Lines of Code 
El archivo ‘RTFOUT.C’ tiene la función más compleja con 355 puntos de CC, pero también tiene otra función con sólo 2 puntos de CC. La complejidad media de este archivo será de (355 + 2) / 2 = 178.5 puntos CC, como se muestra en el gráfico.
También he puesto en esta figura las medidas para el archivo ‘fltexp.c’ que hemos visto anteriormente (Figura 3 anterior) que tiene la deuda técnica más alta y 740 puntos de CC, pero con un mayor número de funciones, ya que el promedio de CC por función es por cerca de 16 puntos.
Si bien es interesante este gráfico, creo que todavia es menos útil que el anterior, más significativo y relevante para visualizar el esfuerzo de refactorización para cada programa y toda la aplicación. Pero podemos ver que tenemos en SonarQube diferentes herramientas y widgets para imaginar e investigar diferentes cursos de acción.
Con estos widgets del portal SonarQube, ahora conozco:
- Los archivos que tienen la deuda técnica más alta: sin ninguna sorpresa, los archivos más gordos y más complejos de nuestra aplicación, que ya habíamos identificado en los posts anteriores.
- El esfuerzo de refactorización para eliminar la deuda técnica para cada uno de estos archivos.
Pero de nuevo, este esfuerzo es demasiado importante para ser considerado como tal, y no se necesita porque no buscamos la eliminación total de la deuda técnica, si no unas acciones de refactorización con un coste de reducción de la deuda lo más bajo posible con los máximos beneficios.
- Nuestro próximo post será dedicado a la presentación de estas acciones. Hasta pronto.
Esta entrada está disponible también en Lire cet article en français y Read that post in english.