Blockers

La primera regla bloqueante que vas a encontrar seguramente te sorprender: Avoid use of SQL.
Cmo? 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 razn 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 ms antiguas que existen, y con los aos si no con las dcadas, 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 prohibicin de programar en SQL
no ocurre en todas las empresas.

Eso explica por qu esta medida es opcional y desactivada por defecto. 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:

Prsentar un dashboard con 18 000 defectos

bloqueantes que prohiben el uso del SQL puede provocar una cierta confusin en el equipo Cobol.

Otros blockers :

Un STOP RUN es una

interrupcin del programa. Todo se detiene, los programas instalados en memoria se eliminan, los
archivos se cerran, regreso directo al sistema operativo. Esta instruccin se debe utilizar con
precaucin (o incluso prohibirse). Y en todos los casos, no puede haber cdigo despus de un
STOP RUN ya que este cdigo no se ejecuta.

He encontrado estos cuatro blockers en esta aplicacin:

Puedes pensar que todos sern contentos que hayas identificado estos cuatro defectos en ms de 2
millones de lneas, de los cuales casi 1,5 millones de lneas de cdigo (el resto es comentario). Eso
por s solo justifica completamente tu trabajo de anlisis.

Tambin se encuentran en esta aplicacin 10 Performs recursivos.

El cdigo Cobol est organizado en un programa con

una serie de prrafos que son equivalentes a los procedimientos o funciones (para simplificar, no
vamos a empezar un curso de Cobol en estas pginas). Realizar un Perform recursivo es
equivalente a llamar a un procedimiento de forma recursiva.

Sonar nos muestra la lnea en que se encuentra esta mala prctica:

Como podemos ver

en este ejemplo, un Perform recursivo se encuentra muy a menudo en un cdigo 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. Adems, se complica mucho la
comprensin del cdigo, por lo que aumenta an ms el riesgo de introducir un error cuando se
hace un cambio. Por lo tanto, es peligroso y todos los programadores Cobol lo saben (a excepcin
de unos muy astutos que quieren demostrar sus talentos con programacin recursiva).

Un ltimo blocker que no encontrars muy a menudo:

Un Perform Thru es cuando el algoritmo pasa a travs de una secuencia de diferentes prrafos. Por
ejemplo, con tres prrafos consecutivos A, B, C, una instruccin Perform A Thru C pasa primero
por A, luego B y C. Problema: si B se encuentra antes de A, entonces slo A y C se ejecutan, que
no es lo que se espera.
Una vez ms, es raro encontrar este tipo de fallo.

Critical

Tambin en esta misma aplicacin, encontramos las siguientes violacines 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 . pequeo y fcil 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 montn de IF sin END-
IF. Esto puede justificar bajar la gravedad de esa mtrica 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 presentacin de un cuadro de mando con miles de defectos crticos.

Algunas de estas reglas son fciles de entender porque se encuentran en otros lenguajes, como la
necesidad de inicializar los parmetros de una llamada, consultas SQL imbricadas o el uso de SQL
dinmico (sin embargo, no es una prctica comn entre los desarrolladores Cobol) . Otras parecen
ms esotricas, 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 eliminacin
de algunos campos, el riesgo es que otros programas llamando a este ltimo ya no funcionarn.
Por lo tanto, sera conveniente centralizar la gestin de estos datos en un Copy-Book. Pero de
nuevo, esto requiere una cierta organizacin 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 inicializacin de los
parmetros de un CALL. Podemos ver un nmero alto de violacines que se encuentran en esta
aplicacin 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 pondra en gravedad (para) Info.

Un SORT es una instruccin para ordenar datos, pero por desgracia, muy costosa en rendimiento.
La regla que prohbe su uso tambin puede ser graduada Crtical, excepto, posiblemente, en el
caso de las aplicaciones Batch. Pero todo el mundo estar de acuerdo con una recomendacin de
correcin de estos defectos.

Un GOTO es un cambio en la lgica del programa para ir directamente a otro prrafo. Mejor
conocido como el smbolo de cdigo Spaghetti. Por ejemplo, si durante un Perform A Thru C, el
prrafo contiene un GOTO D, el programa sale de la secuencia original y el prrafo C no se
ejecutar, a veces con consecuencias impredecibles.

As que una rpida revisin de estas reglas Blockers y Critical nos permite ya una primera
evaluacin de la calidad del cdigo de esta aplicacin y un primer borrador de un plan de accin:

Desactivar la regla que prohbe 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 provocarn suspiros de resignacin de la parte de los Cobol-
ers, pero sin una refactorizacin completa poca probable de la aplicacin, son aqu para
quedarse. Sin embargo, puedes decirles de tratar de corregirlos cuando se hacen cambios
en el cdigo. Sonar les ayuda, mostrando la lnea de cdigo en el que estn presentes.
Tambin deshabilitar las reglas para los parmetros de una llamada o la Linkage Section.
Obviamente, no se aplican estas prcticas por el equipo de Cobol.
Otros defectos deben ser corregidos. Podras subir a Critical la norma que prohbe el uso
del SORT.
Blockers et Critical

A ver las violaciones ahora. Recuerdate que hemos orientado nuestro modelo Calidad hacia la
identificacin de defectos de robustez y de rendimiento, los que afectan lo ms a los usuarios.

El nmero de defectos bloqueantes es poco elevado. Encontramos el SORT de lo que hablamos

anteriormente, y 5 OPEN de ficheros en un bucle. Este tratamiento costoso para el sistema
operativo por supuesto debe realizarse antes del bucle. Estas violaciones presentan un riesgo
elevado para el rendimiento pero son fciles de corregir.

Los defectos crticos se refieren a la robustez:

Un cdigo de status declarado para la gestin correcta de un archivo no ha sido probado

durante una operacin en este fichero (OPEN, READ, WRITE, ). Un intento de escribir en
un archivo no abierto, de leer en un archivo abierto en escritura (Output file), un tamao
de registro (RECORD) incorrecto son errores que pasarn inadvertidos.
Un GOTO que encamina el tratamiento fuera del mdulo corriente rompe la lgica de
ejecucin de ste.
El EVALUATE sin WHEN OTHER es clsico: si ninguna de las condiciones del EVALUATE es
verificada, la lgica del programa se vuelve imprevisible.
La ltima regla sobre el tamao del fichero slo se aplica a Cobol Microfocus, no z/OS
(mainframe IBM).

Es muy probable que exista un estndar de calidad para la gestin del cdigo status de ficheros,
pero que esta best practice se olvida a veces. No se puede evitar la falta de atencin. Sin prueba
de este cdigo, un tratamiento incorrecto puede llevar a cabo una inconsistencia de los datos sin
que se detecta.. La bsqueda de la causa del error tambin ser ms difcil. Al igual que el
EVALUATE sin WHEN OTHER.

Cualquier violacin de estas reglas para la gestin de errores impacta no slo a los usuarios, sino
tambin a los costes de mantenimiento. En nuestro caso, sus nmeros son suficientemente altos
para pensar que se necesita recordar estas buenas prcticas a los desarrolladores.
Costes de remediacin

Te recuerdas el widget que hemos utilizado en el post anterior, con los defectos ms frecuentes?

Encontramos de nuevo el IF sin END-IF de que ya hemos hablados, los peligrosos GOTOs, ms de
4 500 prrafos sin documentacin y cdigo duplicado. Estas violaciones impactan la mantenibilidad
de la aplicacin, como se puede ver en este diagrama:

No vamos a comentar en detalles estos defectos ya que nuestro objetivo es identificar a los que
impactan a los usuarios. Pues las 45 violacines de tipo Blockers y los 292 Critical representan,
respectivamente, 5.6 das y 50.5 das de correccin.
Aproximadamente dos semanas de trabajo para un equipo de 5 o 6 personas versus ms de 10
aos/hombre para corregir todas las violacines que afectan los costes de mantenimiento.

Plan de accin

Por supuesto, vamos a presentar los resultados al equipo del proyecto y comentar con ellos para
comprobar nuestras hiptesis. Sin embargo, nuestro objetivo no es realizar una auditora
exhaustiva, sino mostrar cmo es posible llegar a algunas conclusiones basadas en estos datos, y
formular un plan de accin preliminar.

Acciones a corto plazo:

Corregir los defectos Blockers que afectan al rendimiento: 5 das.

Corregir los defectos crticos, una fuente potencial de errores: 55 das.
Recordar a los equipos Cobol: nada de GOTO especialmente cuando crean una excepcin
a la lgica del mdulo y recordar tambin las mejores prcticas de gestin de errores,
como la obligacin de comprobar el estado de un archivo despus de cualquier operacin
sobre l y el EVALUATE sin WHEN OTHER.
Realizar anlisis peridicos de esta applicacin y verificar que no vuelven a aparecer
defectos bloqueantes o crticos.

Estas acciones no cuestan mucho y se pueden realizar a corto plazo, para un beneficio optimal.
Ellas conducen a la creacin de un proceso de mejora continua. Los usuarios te lo agradecern.

Esta aplicacin cuenta con altos costes de mantenimiento. Consulte con el management si es el
caso y cual es su opinin al respecto. Es muy posible que esta aplicacin tenga pocas evoluciones o
ninguna, y en tal caso, el mantenimiento no es un problema.

Verifica tambin las hiptesis que hemos formulado en el post anterior (applicacin batch orientada
a la gestin de ficheros de datos, poca critica) y explica bien que ella no puede ser subcontratada
con seguridad.

Propone el plan de accin siguiente:

Identificar y eliminar los 184 archivos duplicados, que pesan sobre el mantenimiento.
Realizar un nuevo anlisis para calcular la deuda tcnica y el coste estimado de
refactorizacin.

Estrategia aplicativa
El refactoring de una aplicacin en Cobol es una operacin que rara vez se considera, porque los
costes son demasiado altos. En general, la aplicacin puede morir de muerte natural, y se busca
otra solucin (por ejemplo, ERP).

Deseamos formular recomendaciones realistas.

Pues esto es lo que hago: buscar los programas que tienen el mayor nmero de lneas y de
defectos.

Aqu tenemos tres programas que representan ms de 27 000 lneas, el 15% del tamao total de la
aplicacin (LOC).
 Tambin estn entre los cinco primeros ms
complejos, con un total de 5 900 puntos de Complejidad Ciclomtica, o el 26% de la complejidad
total de la aplicacin.

Y son los tres programas en los cuales se concentran ms violacines, de tipo mayor, pero pocos
crticos ms.

En total, ms de 6.700 violacines, casi una cuarta parte (24%) del nmero total de defectos
encontrados en esta aplicacin.

Claro, el coste de remediacin de estos tres programas es muy alto: 735 das, alrededor de 3 aos-
hombre.

Qu informacin podemos ofrecer?

Un refactoring parcial en estos tres programas que representan el 15% del tamao de la aplicacin
y el 26% de su complejidad, eliminara una cuarta parte del nmero total de defectos, casi
exclusivamente en Maintainability.
Imaginamos que esta refactorizacin parcial reducira el coste de mantenimiento en la misma
proporcin (25%), lo que representa para un equipo de 6 personas una ganancia de 1.5 persona al
ao. Versus un coste de refactorizacin de 3 aos-hombre, el retorno de la inversin es de 2 aos.

Cierto, esta es una estimacin rpida, si no poca precisa. Pero quiero ilustrar de esta forma que el
valor de una auditoria es proporcionar informacin objetiva que permita tomar decisiones a los
responsables. La deuda tcnica de cualquier aplicacin en general da como resultado una nica
decisin posible: echar esta aplicacin. Una estimacin de las ganancias y los costes y retorno de la
inversin con una refactorizacin parcial puede llegar a imaginar una estrategia. El management
prefiere unos datos para alimentar la reflexin a no tener nada y aunque tus cifras suponen un
cierto margen de error, el es plenamente consciente de lo que es tu intencin y aprecia su valor.