Último post de nuestra serie sobre el análisis de la calidad de código PL/SQL con SonarQube.
La evaluación de la calidad de una aplicación no es sólo el análisis de código: eso, cualquiera puede hacerlo. El trabajo del consultor se basa en las siguientes preguntas: qué, por qué, cómo, cuánto.
- Qué: analizar los resultados. El tamaño, la complejidad y la duplicación de código, esto es lo que hemos visto en los articulos anteriores. Se examinan las cifras globales, el promedio, así como las tendencias en el tiempo, si hay varias versiones. Luego nos fijamos en las principales violaciónes de buenas prácticas, principalmente los Blockers y Criticals.
- ¿Por qué estos resultados?: investigamos las causas de los datos en el cuadro de mando SonarQube, el origen de los resultados encontrados.
- ¿Cómo remediar?: proponer un plan de acción. De hecho, varias propuestas de acción. Más adelante veremos que pensamos en diferentes planes en el corto, mediano y largo plazo.
- ¿Cuánto cuesta?: evaluar el coste de cada plan.
Por ejemplo:
- Qué: encontramos un defecto crítico para la seguridad.
- Por qué: es probable que al menos una persona en el equipo de proyecto no conoce esta regla. O esta buena práctica se conoce, pero siempre es posible un error por falta de atención.
- Cómo: la remediación puede consistir en una simple corrección del defecto en el código o una capacitación en estas buenas prácticas.
- Cómo : aquí es donde el plugin SQALE será útil.
No voy a explicar en detalle el método SQUALE y el plugin SQALE de SonarQube. Tal vez tendremos la oportunidad de hacerlo en un futuro post, pero ya hay suficiente información sobre el tema. Le aconsejo ver estos enlaces:
Para nuestros cálculos, consideramos que el equipo del proyecto para mantener este código SQL se compone de 3 personas. En general , una aplicación de tipo Legacy no cambia con mucha frecuencia, por lo que consideramos que el equipo produce cuatro versiones por año.
Recordemos que un año-hombre es igual a 52 semanas, menos las vacaciones y otras fiestas (u otro tipo de ausencias. por enfermedad por exjempo), o 45 semanas o 225 días (en Francia). Esta cifra puede variar entre país, pero no tanto.
La deuda técnica en PL/SQL
Plan de corto plazo – Quitar las amenazas
El más importante y prioritario es eliminar todo lo que constituye una amenaza para el usuario final, lo más rápido y lo más ante posible. Este es el nivel mínimo, esencial, en corto plazo entonces.
Hemos centrado nuestro Perfil de Calidad en violaciónes de seguridad, robustez y rendimiento, que tienen impacto con el usuario. Obviamente los bloqueadores y defectos criticos son las amenazas más graves.
El plugin SQALE nos permite comprobar el coste de remediación para ellos: unos 113 días.
El plan a corto plazo será un proyecto de refactorización de 6 meses/hombre, o sea dos meses para las 3 personas de nuestro equipo de proyecto.
Cuándo: tan pronto como sea posible, para la próxima versión dentro de 3 meses. Es perfectamente aceptable presentar a los stakeholders el plan de posponer las evoluciones no esenciales en la versión siguiente, para que el equipo de proyecto pueda realizar los dos meses de refactorización primero, y luego trabajar el último mes en las mayores funcionalidades. Si son demasiadas, es posible jugar con el tiempo, desplazando la próxima versión en 4 meses. O hacer una versión ‘refactorizada’ en 2 meses, y la siguiente en 4 meses.
Beneficios: una aplicación más segura, más robusta y eficiente, gracias a la eliminación de las amenazas más urgentes y más graves.
Plan de mediano plazo – Alinear TI con los objetivos de deuda técnicas
Nunca debemos olvidar que la estrategia de TI, y entonces la gestión del portafolio de aplicaciones, siempre se alinea con la estrategia de negocio. Un mercado puede ser:
- Maduro, con una estrategia de preservación de la cuota de mercado y de los márgenes financieros, por lo que el cumplimiento de los presupuestos y los costes serán un objetivo esencial de la estrategia de TI. Para el equipo del proyecto, esto significa centrarse en la mantenibilidad y la capacidad de evolución de la aplicación. No deje que se deriva la deuda técnica para estos dos factores.
- Nuevo, con una estrategia de ganancias de cuotas de mercado, time-to-market de las aplicaciones, robustez y rendimiemto: esta es la orientación que hemos dado a nuestro perfil de calidad y el análisis de la calidad de la aplicación.
Por consiguiente, nuestro plan de mediano plazo tendrá como objetivo corregir todos los defectos que afectan a la seguridad, el rendimiento y la fiabilidad, y no sólo a los Blockers y Criticals. La pirámide SQALE nos permite calcular el coste de este plan de mediano plazo:
Un total de 395,6 días. Con 3 personas, esto es un trabajo de 7 meses completos. Difícil de parar el proyecto durante más de la mitad del año.
Sin embargo , estos 395 días incluyen los 113 del plan a corto plazo, por lo que es en realidad un periodo adicional de 282 días, o 15 meses de una persona o cinco meses para cada una de las tres personas del equipo de el proyecto. Podemos pensar en varias sugerencias:
- Limitar el número de nuevas funcionalidades en las próximas cinco versiones para liberar un mes en cada versión para cada miembro del equipo y que se concentren en estas remediaciones. Es posible si esta aplicación ya no evoluciona demasiado y si los usuarios requieren mejoras en la fiabilidad y el rendimiento.
- Si muchas nuevas características son críticas y que la carga de cambio no se puede reducir, entonces los stakeholders deben estar dispuestos a pagar para agregar una cuarta persona en el equipo del proyecto, que se centrará exclusivamente en la corrección de estos defectos en las 5 próximas entregas.
Como se puede ver, este plan es en el horizonte de los próximos 18 meses, incluyendo el plan a corto plazo, pero es posible presentar diferentes hipótesis, más aceptables para las partes interesadas y para un Director de TI preocupado con su presupuesto. Una vez más, el plugin SQALE permite que vayamos a lo esencial.
En el siguiente SQALE Sunburst, podemos ver que, en términos de rendimiento (eficiencia ), se necesitan 104 días para corregir violaciónes de una regla relativa a los tipos de datos.
Creo que es en la versión Oracle 11g que un nuevo tipo de datos ha mejorado hasta en un 50% el rendimiento de algunos procedimientos almacenados. Si el tiempo de respuesta de la aplicación no es un problema importante para los usuarios, entonces podemos retrasar la remediación de esta regla Major a más largo plazo y ganar 104 días o 21 semanas, alrededor de 7 semanas por cada miembro del equipo de proyecto. Por supuesto, la idea no es de reducir el plan de mediano plazo a corto plazo, sino concentrarse en lo esencial, con la ayuda de este gráfico donde se muestra la distribución de la deuda técnica sobre diferentes tipos de riesgos para la aplicación.
Plan a largo plazo – Alinear la deuda técnica con la estrategia de aplicación
El plan a largo plazo debe tratar de una pregunta obvia : ¿qué hacer con este componente monstruoso que integra toda la lógica de negocio de la aplicación? El plugin SQALE calcula que la deuda técnica para este componente es 1 431,9 días, el 75 % de la deuda técnica total para la aplicación (más de 6 años).
De hecho , la pregunta es ¿qué hacer con esta aplicación? Todo depende del nivel de criticidad.
Si una aplicación con una deuda técnica muy alta no es crítica, la solución es simple: abandonala. Sigue a costar más mantenerla que sustituirla, ya sea por un software o por una aplicación desarrollada en una nueva tecnología más reciente. Debido a que la aplicación no es crítica, no es esencial mantener el control o el conocimiento, por lo que podemos, o bien externalizar este desarrollo a una empresa de outsourcing, o realizar un RPF para poner en competición editores de software e integradores. En todos los casos, el partner seleccionado mantendrá la solución, normalmente con menor coste, pero con la complejidad añadida de gestionar un proveedor externo.
Si la aplicación es crítica, entonces necesitarás manejar el problema por tí mismo, ya que no quieres dejar a un tercero la gestión del riesgo de negocio que esta aplicación puede representar para la empresa. Hay entonces dos posibilidades: una refactorización de la aplicación o una reescritura completa.
En este caso, corregir todos los defectos encontrados en este componente monstruoso y dejarlo tal como es, eso no tiene mucho sentido. La refactorización debe centrarse con prioridad en un nuevo diseño de la aplicación, que en realidad promueve la solución de reescribirla con una nueva tecnología.
Hemos visto que esta base de datos contiene 687 tablas, sin contar las vistas, pero con una importante duplicación de estructuras de datos. Mi recomendación para un plan a largo plazo será la siguiente:
- Llevar a cabo una retro-documentación para enumerar los diferentes componentes presentes en esta aplicación y los enlaces entre ellos.
- Para llevar a cabo un rediseño conceptual y una mapa de los objetos funcionales, inicialmente en el mismo perímetro, luego tomando en cuenta los cambios funcionales deseados por los usuarios.
Es posible subcontratar este trabajo a un proveedor de servicios, sobre todo si el equipo de proyecto actual ha experimentado un turnover importante durante la vida de esta aplicación y ha perdido un poco el conocimiento de ella.
Sin embargo, este proveedor debe estar equipado con herramienta para automatizar esta retro-documentación: 150.000 líneas de código y de comentarios no es enorme, pero este trabajo no puede ser manual. Se necesita una herramienta que permite rastrear todos componentes y sus relaciones en una cartografía de la aplicación.
Pues esto es estupendo: SonarSource tiene previsto un proyecto para una herramienta de este tipo. Nuestra aplicación PL/SQL será entonces un buen candidato para una prueba de esta futura producción de SonarSource.
Esta entrada está disponible también en Lire cet article en français y Read that post in english.