Una regla se conoce o no. Una ‘best practice’ se aplica o no. Pero si no se aplica, ¿es porque no es aplicable o porque no es conocida?

Debes presentar los resultados de tus primeros análisis Cobol y, por supuesto, quieres demostrar el valor de estos análisis a los equipos de proyectos, proveedores, stakeholders, etc.

Esto requiere la definición de un modelo de medición de la calidad – un conjunto de reglas y niveles de criticidad – que permite la rápida identificación de las malas prácticas más costosas y peligrosas. Obviamente sería un fracaso denunciar una violación a una ‘mejor práctica’ que no está aplicable – por ejemplo, el uso de SQL (ver. nuestro último post).

¿Cuáles son las reglas aplicables? ¿Cuál de los umbrales de severidad elegir? Cómo ajustar el modelo de Calidad en un Quality profile Sonar para las aplicaciones Cobol ?

Entregar el valor

El análisis de código Cobol en nuestro último post nos enseño dos tipos diferentes de valores cuando se mide el número de violaciónes de una regla:

• Un número muy elevado, hasta varios miles o decenas de miles: la regla probablemente no es aplicable y probablemente se debería excluir de nuestro modelo de Calidad.
• Un número muy bajo: la regla es conocida y aplicada, pero nunca se puede evitar la falta de atención por parte de los desarrolladores, y algunos defectos con consecuencias que pueden ser muy graves para los usuarios finales.

Sin embargo, hay excepciones específicas al modelo de Calidad Cobol, como el IF sin END-IF, mala práctica tan antigua que no se puede culpar a los actuales desarrolladores. Hemos visto que en este caso, se puede reducir la gravedad de esta regla.

También podemos proponer de ​​subir la criticidad de unas reglas: por ejemplo, para la norma que prohíbe la instrucción SORT de ‘Critical’ à ‘Blocker’. Aquí es donde una herramienta de análisis de código muestra todas sus ventajas: en la detección automática de un número limitado de defectos graves o criticos que pueden corregirse fácilmente. Esta es una de las maneras más seguras para transformar los resultados de tus análisis en valor para tu audiencia.

Para construir un modelo de Calidad que maximice este valor, debes tomar las decisiones correctas sin conocer las ‘best practices’ aplicables. Para descubrirlas, puedes:

• Pedir los estándares de programación Cobol. Muy a menudo no existe tal documento, y cuando existe, es muy a menudo obsoleto.
• Realizar una lista de todas las reglas Cobol y organizar una reunión con los equipos Cobol para definir cuales son aplicables. Se puede pasar mucho tiempo explicando reglas que no se aplican y que no dominas bien si tu conocimiento del mundo Mainframe es limitado.
• Revisar los resultados de tus análisis para identificar las reglas aplicables, y definir un modelo de calidad que presentar.

Plugin Views

Vamos a crear una vista (View) que incluye todos nuestros análisis Cobol, con el plugin Views. Conectarse comó ‘Admin’, e ir al menú ‘Configuration’ y ‘Views’.

He creado una ‘View Cobol’ que agrupa los proyectos ya analizados. Tengo que analizar de nuevo al menos uno de estos proyectos para que aparezca la vista Cobol en el dashboard Sonar. Aquí están los resultados:

Como puedes ver, tenemos aquí una buena muestra: aplicaciones de diferentes tamaños, más de 5 millones de líneas Cobol con más de 3,3 millones de líneas de código en 6.714 archivos. Sólo una aplicación no está en rojo, las otras tienen un grado de cumplimiento de la reglas Cobol cerca del cero absoluto.

Widget ‘Most violated rules’

Estamos ya conectados como ‘Administrador’ lo que nos permiter añadir un widget que nos será muy útil.

Seleccione ‘Configurar Widgets’ en el menú, y a continuación en la lista de widgets, añade el widget ‘Most violated rules’ en el cuadro de mando Sonar: la lista de las reglas con la mayoría de violaciónes.

El menú ‘Edit’ del widget nos permite cambiar la configuración, por ejemplo para mostrar las 15 reglas con defectos más frecuentes:

‘Save’ para guardar este parametro, y ‘Back to dashboard’ para conocer las 15 reglas con el mayor número de violaciónes.

Entiendes ahora por qué casi todas las aplicaciones se encuentran en rojo. Si enseñas este dashboard a los equipos de proyecto y a tus contactos, ellos te dirán que tus análisis no tienen valor, ya que toman en cuenta reglas que no se aplican. Los defectos más graves y que son los que tienes que enseñar están perdidos dentro de reglas que no se aplican.

Selección de reglas

Este widget va a ser muy útil para identificar las reglas que de inmediato se pueden excluir de nuestro modelo de Calidad:

• COMP (COMPUTATIONAL) es un tipo de datos que permite que el compilador elige la asignación en memoria de estos datos. Como los compiladores son diferentes entre plataformas, esta cláusula puede causar problemas de portabilidad. Sin embargo, la migración de sistemas de aplicaciones entre los diferentes mainframes se produce muy raramente, así que esta regla no suele ser motivo de preocupación. Además, este formato es preferible porque más eficiente a nivel de rendimiento, por el compilador.
• ‘Magic Literal’ / ‘Magic Number’ son ‘best practices’ que recomendan el uso de constantes. Estas no son reglas específicas al Cobol, se encuentran en muchos lenguajes pero no tanto en el mundo Mainframe.
• ‘Using paragraphs’, ‘Perform Paragraph / Section’. Son reglas de estructuración de código Cobol, y con más de 100.000 violaciónes, claro que no se aplican aquí. También se excluyen mutuamente entre sí.

Una vez más, no vamos a empezar un curso Cobol y aclarar estas normas. El objetivo es demostrar que con nuestra ‘View Cobol’ y este widget, podemos rápidamente definir nuestro propio modelo de Calidad. Las primeras 5 reglas mencionadas anteriormente se pueden desactivar sin ningún problema.

Otras ventajas del widget ‘Most violated rules’:

• Seleccionar un nivel de severidad con el fin de notar las reglas que excluir o para las cuales pensamos cambiar el umbral de criticidad.

Aquí encontramos las tres primeras reglas ‘Critical’ que habíamos deseado quitar del modelo de Calidad en nuestro último post. Hemos tomado nota también de pasar la regla ‘Avoid using SORT statement’ a ‘Blocker’.

Voy a pasar ‘Limit the number of lines in a WHERE clause’ e ‘Avoid nested SQL SELECT statements’ a una criticidad ‘Major’: estas ‘best practices’ sin duda criticas para la lejibilidad y la mantenabilidad del código no impactan a los usuarios. Ahora quiero centrar el valor de mi modelo de Calidad en los defectos que presentan el mayor riesgo para los usuarios y en mejores prácticas de robustez y rendimiento. Por ejemplo, probablemente voy a subir unas cuantas reglas SQL a mayor gravedad.

• Seleccionar una regla para comprobar qué aplicaciones de la View Cobol la aplican o no.

Aquí podemos ver que la norma que prohíbe el uso de consultas SQL se refiere sólo a cuatro de las siete aplicaciones Cobol. Tenemos aquí un ejemplo de una regla que se aplicará de manera diferente entre diferentes equipos.

Tu proprio modelo de Calidad

Con una View Sonar y el widget ‘Most violated rules’, puedes definir fácilmente la calidad de tu propio modelo en menos de una hora, aun sin ser un experto en el mundo Mainframe.

Puedes identificar claramente las reglas que no se aplican, basandote en el número de defectos encontrados. Puedes centrarte en las reglas con pocas violaciónes que son probablemente conocidas y aplicadas por los equipos Cobol.

Se necesita una muestra lo suficientemente grande para que el número de defectos adquiere sentido. Analizar múltiples aplicaciones y agregarlas en una vista de Sónar.

Elige un eje de valores para tu público:

• Reducir el riesgo de errores para los usuarios: elegir las normas que afectan a la fiabilidad de las aplicaciones y el rendimiento.
• Reducir los costes de mantenimiento: favorecer reglas que afectan la mantenibilidad y la legibilidad del código.

2 posts para mejor entender este punto: ¿Cuál es la primera pregunta? et Best of both worlds. Para destacar unas reglas, pasarlas a ‘Critical’ o ‘Blockers’.

Definir un Quality profile Sonar para tu propio modelo de Calidad. Volver a analizar las aplicaciones y comprobar los resultados en el dashboard Sonar.

Podrás ver inmediatamente que ahora se puede ir directamente al grano en la identificación de las principales causas de los riesgos y de los costos. Más valor para tu presentación del dashboard Sonar.