{"id":149,"date":"2012-06-23T10:17:35","date_gmt":"2012-06-23T09:17:35","guid":{"rendered":"http:\/\/dev.qualilogy.com\/es\/?p=149"},"modified":"2013-01-05T10:18:38","modified_gmt":"2013-01-05T09:18:38","slug":"sonar-cobol-reglas-cobol","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/sonar-cobol-reglas-cobol\/","title":{"rendered":"Sonar Cobol – Reglas Cobol"},"content":{"rendered":"

\"\"<\/a>Los posts anteriores sobre la preparaci\u00f3n y el an\u00e1lisis de c\u00f3digo Cobol con Sonar y Jenkins provocaron unos comentarios preocupados por los resultados de an\u00e1lisis y las normas disponibles en el dashboard Sonar.<\/p>\n

\u00bfPermiten estos resultados una evaluaci\u00f3n de la calidad de las aplicaciones Cobol? \u00bfQu\u00e9 valor podemos entregar a los equipos y el management? Y para aquellos que no est\u00e1n familiarizados con el mundo Mainframe, \u00bfcu\u00e1les son las ‘mejores \/ peores pr\u00e1cticas’ para el c\u00f3digo Cobol?<\/p>\n

Muchas preguntas, y no vamos a poder responder a todas en un \u00fanico post. Vamos a dedicar este a la presentaci\u00f3n de las diferentes normas y los defectos de calidad que se encuentran frecuentemente en las aplicaciones Cobol.<\/p>\n

El objetivo es: has hecho un an\u00e1lisis, los resultados aparecen en el dashboard Sonar. Ahora, \u00bfpor d\u00f3nde empezar?<\/strong><\/p>\n

Blockers<\/strong><\/h3>\n

La primera regla \u00abbloqueante\u00bb que vas a encontrar seguramente te sorprender\u00e1: \u2018Avoid use of SQL\u2019. \u00bfC\u00f3mo? No es posible programar SQL en Cobol? De hecho, est\u00e1 completamente prohibido en algunas organizaciones que han implementado componentes reutilizables para facilitar el acceso a la capa de datos.<\/p>\n

La raz\u00f3n 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\u00e1s antiguas que existen, y con los a\u00f1os si no con las d\u00e9cadas, 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\u00ed un error.<\/p>\n

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\u00f3n de programar en SQL no ocurre en todas las empresas.<\/p>\n

Eso explica por qu\u00e9 esta medida es opcional y desactivada por defecto (en este tema, ver el post Quality Profiles<\/a>). As\u00ed que mejor comprobar con los equipos Cobol si esta ‘best practice’ existe o no, y si necesitas activar o no esta regla.<\/p>\n

De lo contrario, puede aparecer el siguiente caso:<\/p>\n

\"\"<\/a>Pr\u00e9sentar un dashboard con 18 000 defectos \u2018bloqueantes\u2019 que prohiben el uso del SQL puede provocar una cierta confusi\u00f3n en el equipo Cobol.<\/p>\n

Otros blockers :
\n\"\"<\/a>Un STOP RUN es una interrupci\u00f3n del programa. Todo se detiene, los programas instalados en memoria se eliminan, los archivos se cerran, regreso directo al sistema operativo. Esta instrucci\u00f3n se debe utilizar con precauci\u00f3n (o incluso prohibirse). Y en todos los casos, no puede haber c\u00f3digo despu\u00e9s de un STOP RUN ya que este c\u00f3digo no se ejecuta.<\/p>\n

\"\"<\/a>He encontrado estos cuatro ‘blockers’ en esta aplicaci\u00f3n:<\/p>\n

Puedes pensar que todos ser\u00e1n contentos que hayas identificado estos cuatro defectos en m\u00e1s de 2 millones de l\u00edneas, de los cuales casi 1,5 millones de l\u00edneas de c\u00f3digo (el resto es comentario). Eso por s\u00ed solo justifica completamente tu trabajo de an\u00e1lisis.<\/p>\n

Tambi\u00e9n se encuentran en esta aplicaci\u00f3n 10 Performs recursivos.<\/p>\n

\"\"<\/a>El c\u00f3digo Cobol est\u00e1 organizado en un programa con una serie de p\u00e1rrafos que son equivalentes a los procedimientos o funciones (para simplificar, no vamos a empezar un curso de Cobol en estas p\u00e1ginas). Realizar un Perform recursivo es equivalente a llamar a un procedimiento de forma recursiva.<\/p>\n

Sonar nos muestra la l\u00ednea en que se encuentra esta mala pr\u00e1ctica:<\/p>\n

\"\"<\/a> Como podemos ver en este ejemplo, un Perform recursivo se encuentra muy a menudo en un c\u00f3digo complicado lleno de ‘If’ imbricados, y aqu\u00ed en un ‘Else’. As\u00ed que si alguna de las condiciones anteriores no se verifica, el riesgo es importante de encontrar una llamada recursiva infinita. Adem\u00e1s, se complica mucho la comprensi\u00f3n del c\u00f3digo, por lo que aumenta a\u00fan m\u00e1s 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\u00f3n de unos muy astutos que quieren demostrar sus talentos con programaci\u00f3n recursiva).<\/p>\n

Un \u00faltimo blocker que no encontrar\u00e1s muy a menudo:<\/p>\n

\"\"<\/a><\/p>\n

Un Perform Thru es cuando el algoritmo pasa a trav\u00e9s de una secuencia de diferentes p\u00e1rrafos. Por ejemplo, con tres p\u00e1rrafos consecutivos A, B, C, una instrucci\u00f3n ‘Perform A Thru C’ pasa primero por A, luego B y C. Problema: si B se encuentra antes de A, entonces s\u00f3lo A y C se ejecutan, que no es lo que se espera.
\nUna vez m\u00e1s, es raro encontrar este tipo de fallo.<\/p>\n

Critical<\/strong><\/h3>\n

Tambi\u00e9n en esta misma aplicaci\u00f3n, encontramos las siguientes violaci\u00f3nes \u2018Critical\u2019.<\/p>\n

\"\"<\/a>Un defecto que se encontrar\u00e1 en todas las aplicaciones: un IF que no se termina con un END-IF. \u00bfCon que se termina? Por un punto. S\u00ed, un ‘.’ peque\u00f1o y f\u00e1cil de pasar por alto. Cualquier mierda de mosca en la pantalla y el error est\u00e1 asegurada. No te puedes imaginar las miles de horas para depurar los programas Cobol debido a ese maldito punto.<\/p>\n

Todos los programadores lo saben y todo el mundo respeta ahora esta ‘best practice’, pero no siempre fue as\u00ed. De hecho, en las antiguas aplicaciones, se encuentran un mont\u00f3n de IF sin END-IF. Esto puede justificar bajar la gravedad de esa m\u00e9trica 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\u00f3n de un cuadro de mando con miles de defectos cr\u00edticos.<\/p>\n

Algunas de estas reglas son f\u00e1ciles de entender porque se encuentran en otros lenguajes, como la necesidad de inicializar los par\u00e1metros de una llamada, consultas SQL imbricadas o el uso de SQL din\u00e1mico (sin embargo, no es una pr\u00e1ctica com\u00fan entre los desarrolladores Cobol) . Otras parecen m\u00e1s esot\u00e9ricas, pero siguen siendo bastante sencillas.<\/p>\n

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\u00f3n de algunos campos, el riesgo es que otros programas llamando a este \u00faltimo ya no funcionar\u00e1n. Por lo tanto, ser\u00eda conveniente centralizar la gesti\u00f3n de estos datos en un Copy-Book. Pero de nuevo, esto requiere una cierta organizaci\u00f3n de los programadores y esta regla no se aplica a menudo.<\/p>\n

Esta desactivada en el Quality Profile<\/a> de Sonar, al igual que la regla de inicializaci\u00f3n de los par\u00e1metros de un CALL. Podemos ver un n\u00famero alto de violaci\u00f3nes que se encuentran en esta aplicaci\u00f3n por estas dos reglas. As\u00ed que de nuevo, mejor consultar con el equipo Cobol si se aplican y si hay que desactivarlas. Personalmente, yo las pondr\u00eda en gravedad (para) ‘Info’.<\/p>\n

Un SORT es una instrucci\u00f3n para ordenar datos, pero por desgracia, muy costosa en rendimiento. La regla que proh\u00edbe su uso tambi\u00e9n puede ser graduada ‘Cr\u00edtical’, excepto, posiblemente, en el caso de las aplicaciones Batch. Pero todo el mundo estar\u00e1 de acuerdo con una recomendaci\u00f3n de correci\u00f3n de estos defectos.<\/p>\n

Un GOTO es un cambio en la l\u00f3gica del programa para ir directamente a otro p\u00e1rrafo. Mejor conocido como el s\u00edmbolo de c\u00f3digo Spaghetti. Por ejemplo, si durante un ‘Perform A Thru C’, el p\u00e1rrafo contiene un GOTO D, el programa sale de la secuencia original y el p\u00e1rrafo C no se ejecutar\u00e1, a veces con consecuencias impredecibles.<\/p>\n

As\u00ed que una r\u00e1pida revisi\u00f3n de estas reglas \u2018Blockers\u2019 y \u2018Critical\u2019 nos permite ya una primera evaluaci\u00f3n de la calidad del c\u00f3digo de esta aplicaci\u00f3n y un primer borrador de un plan de acci\u00f3n:<\/p>\n