La calidad de código de las aplicaciones es una preocupación constante desde siempre. Las malas prácticas de programación son responsables de defectos que impactan a los usuarios y los costes de mantenimiento. La Deuda Técnica, simple metáfora al principio, se ha convertido en una herramienta para medir la calidad y estos costes.

Unos cuantos años antes, los softwares que permiten la identificación de estos defectos eran raros y costosos. Hoy en día, herramientas Open Source tales como Sonar permiten que todos – equipos de proyectos, proveedores, consultores de Calidad, etc. – puedan detectar de manera sencilla y a buen precio estas malas prácticas.

El mundo Open Source ha sufrido durante mucho tiempo de una imagen de ‘geek’, porque primero fueron los entusiastas del mundo J2EE que utilizaron estas herramientas. Pero los tiempos cambian y ahora es posible analizar código Legacy como Cobol y ABAP con Sonar.

Este es el objetivo de nuestra serie de posts: demostrar que es posible evaluar la calidad de las aplicaciones Cobol sin saber nada del mundo Mainframe.

Hemos visto anteriormente:

• Los pocos conceptos que se necesitan para poder sentarse en una mesa con Cobol-ers y saber cuales preguntas hacer para preparar la entrega de una aplicación Cobol.
• ¿Cómo organizar un análisis Cobol con un Quality profile Sonar.
• ¿Cómo definir su propio Quality model y agregar los resultados de análisis de distintas aplicaciones en una única View Sonar.

Estos pots anteriores han despertado la curiosidad (a juzgar por el número de visitantes en el blog) y levantaron preguntas relativas a los resultados de estos análisis. Esto es lo que vamos a ver ahora: ¿Qué recomendaciones podemos formular basandonos en los resultados de análisis y el dashboard Sonar.

En primer lugar, no voy a realizar una auditoría. Son entre 15 y 20 horas para realizar un trabajo por lo menos un poco serio y necesitaría un post de 30 o 40 páginas. El objetivo es enseñar cómo traducir los resultados en valor, es decir, en información para la decisión.

Tampoco vamos a llevar a cabo un análisis exhaustivo de los resultados, pero trataré de mostrar con algunos ejemplos sencillos cómo utilizar el cuadro de mando de Sonar para evaluar la calidad del código de una aplicación Cobol.

Previamente, recordemosnos que hemos centrado nuestro modelo de calidad en la detección de violaciones de rendimiento y de robustez, para identificar los defectos que puedan afectar a los usuarios. Así que los problemas de legibilidad y de mantenimiento no son nuestra principal preocupación. Podrían ser, pero este no es el caso, o al menos no ahora.

Y no se necesita ser un experto del mundo Mainframe para demostrar a esos expertos cómo nuestros análisis les pueden ayudar. La forma más sencilla de lograrlo es identificar los graves defectos que pueden corregirse con facilidad, no con el cálculo de una deuda técnica de miles y miles de días que nadie puede resolver.

Métricas

En primer lugar, me gustaría saber lo que se me espera: una pequeña y bonita aplicación o un monstruo grande y feo, muy común en el mundo Mainframe. Recuerdate que la deuda técnica en este mundo se mide en décadas.

El cuadro de mando Sonar nos permite descubrir que, entre las aplicaciones analizadas, ‘Cobol – Tax’ es la más voluminosa con la aplicación ‘Cobol – Big Banking app’. Pero es ‘Cobol – Billing’ que tiene la calidad más a riesgo.

Miramos un poco más de cerca esta aplicación:

Más de 180 000 líneas de código en menos de 1 400 archivos: esta es una pequeña aplicación. Puedes ver que más de la mitad de las líneas está en ‘Data Divisions’, la parte de un programa Cobol que define los datos utilizados.

Esto indica una aplicación orientada a ‘datos’, probablemente una aplicación Batch que gestiona ficheros, por ejemplo, libros de contabilidad para registrar los movimientos realizados en cuentas bancarias. Puedes comprobar con el equipo Cobol al hacer tu presentación pero también, lo que hago es echar un ojo en unos programas: los comentarios te dicen de que se trata.

En la mayoría de los casos, el equipo de proyecto sabe decir si la aplicación es pequeña o grande, compleja o no, pero por lo general, no conocen estos números con exactitud y probablemente serán sorprendidos e interesados al descubrir la distribución de líneas de código entre ‘Data Divisions’ dedicadas a datos o ‘Procedure Divisions’ para los tratamientos.

El nivel de comentario es bajo para una aplicación Mainframe: el promedio es usualmente entre 20% (mínimo) y 30% (correcto). Al menos, estos comentarios están en los tratamientos, pero nos damos cuenta de que una gran parte es «en blanco» es decir, vacío. Por otra parte, no vamos a tener documentación para entender las estructuras de datos que, sin embargo, prevalecen en el código.

Como se puede ver, esta aplicación no es muy compleja, con una Complejidad Ciclomática de 17,5 por archivo. Pero el número de líneas de código duplicado es muy alto, por encima del 50%, probablemente por la culpa de los 184 programas duplicados, un 13% de la aplicación. ¿Cuál es el origen de estos archivos duplicados? Simplemente, debido a las copias de seguridad. El mundo Mainframe no es el más avanzado en gestión de versiones. La forma más fácil, cuando uno no está seguro de la funcionalidad que tiene que implementar, es poner el código en comentario o, más rápido, copiar el archivo para realizar la evolución deseada mientras se mantiene una copia de seguridad, lo que permite un retroceso si se necesita. Estas copias se acumulan a lo largo del tiempo si nadie piensa hacer una limpieza de cuando en vez.

Mensaje para el management: puede parecer interesante externalizar esta aplicación debido a que:

• Su pequeño tamaño significa que los costes de subcontratación no serán altos.
• No es una aplicación compleja y por lo tanto, no fácil de entender.
• Una aplicación Batch rara vez es una aplicación crítica, por lo que el riesgo de dependencia con el proveedor externo se reduce.

Sin embargo, un bajo nivel de documentación equivale a una transferencia de conocimiento más difícil y más larga, una perdida de tiempo – y por lo tanto de dinero – para el proveedor que se encarga de la externalización. Por otra parte, el alto porcentaje de código duplicado significa más trabajo para realizar cualquier modificación en todos los bloques de código copiado y pegado.

Un proveedor externo no puede permitirse el lujo de perder dinero, por lo que estas tareas disminuirán aún más el tiempo disponible para realizar el mantenimiento, con el riesgo de hacer un mal trabajo. No es apropiado dar este código a un proveedor sin un trabajo previo de refactorización para eliminar archivos duplicados y redocumenter esta aplicación, especialmente con respecto a los archivos de datos.

Más en nuestro próximo post, que se centrará en violaciónes encontradas y las recomendaciones finales.

 

Esta entrada está disponible también en Lire cet article en français y Read that post in english.