Los posts anteriores sobre la preparación y el análisis de código Cobol con Sonar y Jenkins provocaron unos comentarios preocupados por los resultados de análisis y las normas disponibles en el dashboard Sonar.

¿Permiten estos resultados una evaluación de la calidad de las aplicaciones Cobol? ¿Qué valor podemos entregar a los equipos y el management? Y para aquellos que no están familiarizados con el mundo Mainframe, ¿cuáles son las ‘mejores / peores prácticas’ para el código Cobol?

Muchas preguntas, y no vamos a poder responder a todas en un único post. Vamos a dedicar este a la presentación de las diferentes normas y los defectos de calidad que se encuentran frecuentemente en las aplicaciones Cobol.

El objetivo es: has hecho un análisis, los resultados aparecen en el dashboard Sonar. Ahora, ¿por dónde empezar?

Blockers

La primera regla «bloqueante» que vas a encontrar seguramente te sorprenderá: ‘Avoid use of SQL’. ¿Cómo? No es posible programar SQL en Cobol? De hecho, está completamente prohibido en algunas organizaciones que han implementado componentes reutilizables para facilitar el acceso a la capa de datos.

La razón es sencilla: si cada desarrollador agrega su propio SQL cada vez que se necesita acceder a una tabla, los accesos a la base de datos se multiplican a lo largo del tiempo. Las aplicaciones Cobol son las más antiguas que existen, y con los años si no con las décadas, los ‘update / insert / delete’ han crecido de manera imposible. Entonces, cualquier cambio en la estructura de datos de una tabla necesita modificar decenas de consultas SQL redundantes en diferentes programas, lo que resulta un esfuerzo de mantenimiento muy importante y un alto riesgo de olvidarse de un programa, creando así un error.

Sin embargo, reservar el acceso a la capa de datos a un conjunto de componentes reutilizables significa un equipo dedicado a mantener estos programas, y procesar solicitudes de cambios de otros equipos. Muy pesado, consume mucho tiempo, por lo que la prohibición de programar en SQL no ocurre en todas las empresas.

Eso explica por qué esta medida es opcional y desactivada por defecto (en este tema, ver el post Quality Profiles). Así que mejor comprobar con los equipos Cobol si esta ‘best practice’ existe o no, y si necesitas activar o no esta regla.

De lo contrario, puede aparecer el siguiente caso:

Présentar un dashboard con 18 000 defectos ‘bloqueantes’ que prohiben el uso del SQL puede provocar una cierta confusión en el equipo Cobol.

Otros blockers :
Un STOP RUN es una interrupción del programa. Todo se detiene, los programas instalados en memoria se eliminan, los archivos se cerran, regreso directo al sistema operativo. Esta instrucción se debe utilizar con precaución (o incluso prohibirse). Y en todos los casos, no puede haber código después de un STOP RUN ya que este código no se ejecuta.

He encontrado estos cuatro ‘blockers’ en esta aplicación:

Puedes pensar que todos serán contentos que hayas identificado estos cuatro defectos en más de 2 millones de líneas, de los cuales casi 1,5 millones de líneas de código (el resto es comentario). Eso por sí solo justifica completamente tu trabajo de análisis.

También se encuentran en esta aplicación 10 Performs recursivos.

El código Cobol está organizado en un programa con una serie de párrafos que son equivalentes a los procedimientos o funciones (para simplificar, no vamos a empezar un curso de Cobol en estas páginas). Realizar un Perform recursivo es equivalente a llamar a un procedimiento de forma recursiva.

Sonar nos muestra la línea en que se encuentra esta mala práctica:

Como podemos ver en este ejemplo, un Perform recursivo se encuentra muy a menudo en un código complicado lleno de ‘If’ imbricados, y aquí en un ‘Else’. Así que si alguna de las condiciones anteriores no se verifica, el riesgo es importante de encontrar una llamada recursiva infinita. Además, se complica mucho la comprensión del código, por lo que aumenta aún más el riesgo de introducir un error cuando se hace un cambio. Por lo tanto, es peligroso y todos los programadores Cobol lo saben (a excepción de unos muy astutos que quieren demostrar sus talentos con programación recursiva).

Un último blocker que no encontrarás muy a menudo:

Un Perform Thru es cuando el algoritmo pasa a través de una secuencia de diferentes párrafos. Por ejemplo, con tres párrafos consecutivos A, B, C, una instrucción ‘Perform A Thru C’ pasa primero por A, luego B y C. Problema: si B se encuentra antes de A, entonces sólo A y C se ejecutan, que no es lo que se espera.
Una vez más, es raro encontrar este tipo de fallo.

Critical

También en esta misma aplicación, encontramos las siguientes violaciónes ‘Critical’.

Un defecto que se encontrará en todas las aplicaciones: un IF que no se termina con un END-IF. ¿Con que se termina? Por un punto. Sí, un ‘.’ pequeño y fácil de pasar por alto. Cualquier mierda de mosca en la pantalla y el error está asegurada. No te puedes imaginar las miles de horas para depurar los programas Cobol debido a ese maldito punto.

Todos los programadores lo saben y todo el mundo respeta ahora esta ‘best practice’, pero no siempre fue así. De hecho, en las antiguas aplicaciones, se encuentran un montón de IF sin END-IF. Esto puede justificar bajar la gravedad de esa métrica de ‘Critical’ a ‘Major’. A menudo son demasiado numerosos para considerar corregir esos defectos. Y luego, no desmoralizar a los equipos de Cobol mediante la presentación de un cuadro de mando con miles de defectos críticos.

Algunas de estas reglas son fáciles de entender porque se encuentran en otros lenguajes, como la necesidad de inicializar los parámetros de una llamada, consultas SQL imbricadas o el uso de SQL dinámico (sin embargo, no es una práctica común entre los desarrolladores Cobol) . Otras parecen más esotéricas, pero siguen siendo bastante sencillas.

La Linkage Section define en un programa los datos que pueden ser compartidos con otro programa. Si cada desarrollador comienza a cambiar la estructura de datos mediante la eliminación de algunos campos, el riesgo es que otros programas llamando a este último ya no funcionarán. Por lo tanto, sería conveniente centralizar la gestión de estos datos en un Copy-Book. Pero de nuevo, esto requiere una cierta organización de los programadores y esta regla no se aplica a menudo.

Esta desactivada en el Quality Profile de Sonar, al igual que la regla de inicialización de los parámetros de un CALL. Podemos ver un número alto de violaciónes que se encuentran en esta aplicación por estas dos reglas. Así que de nuevo, mejor consultar con el equipo Cobol si se aplican y si hay que desactivarlas. Personalmente, yo las pondría en gravedad (para) ‘Info’.

Un SORT es una instrucción para ordenar datos, pero por desgracia, muy costosa en rendimiento. La regla que prohíbe su uso también puede ser graduada ‘Crítical’, excepto, posiblemente, en el caso de las aplicaciones Batch. Pero todo el mundo estará de acuerdo con una recomendación de correción de estos defectos.

Un GOTO es un cambio en la lógica del programa para ir directamente a otro párrafo. Mejor conocido como el símbolo de código Spaghetti. Por ejemplo, si durante un ‘Perform A Thru C’, el párrafo contiene un GOTO D, el programa sale de la secuencia original y el párrafo C no se ejecutará, a veces con consecuencias impredecibles.

Así que una rápida revisión de estas reglas ‘Blockers’ y ‘Critical’ nos permite ya una primera evaluación de la calidad del código de esta aplicación y un primer borrador de un plan de acción:

• Desactivar la regla que prohíbe el uso de SQL: no se aplica aquí.
• Prioridad: corregir los 4 STOP RUN y los 10 Performs recursivos.
• Los IF sin END-IF, sin duda provocarán suspiros de resignación de la parte de los Cobol-ers, pero sin una refactorización completa poca probable de la aplicación, son aquí para quedarse. Sin embargo, puedes decirles de tratar de corregirlos cuando se hacen cambios en el código. Sonar les ayuda, mostrando la línea de código en el que están presentes.
• También deshabilitar las reglas para los parámetros de una llamada o la Linkage Section. Obviamente, no se aplican estas prácticas por el equipo de Cobol.
• Otros defectos deben ser corregidos. Podrías subir a ‘Critical’ la norma que prohíbe el uso del SORT.

Con esto ya puedes hacer un Quality Gate de esta aplicación y pedir a un proveedor unas correcciones.

Continuaremos con la evaluación de la calidad del código Cobol en un próximo post, con aún más reglas.

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