Les précédents posts sur la préparation et l’analyse de code Cobol avec Sonar et Jenkins ont attiré quelques commentaires impatients au sujet du résultat des analyses et des règles disponibles dans le dashboard Sonar.

Ces résultats permettent-ils une évaluation de la qualité des applications Cobol ? Quelle valeur pouvons-nous délivrer aux équipes, aux partenaires et au management ? Et pour ceux qui ne sont pas familiers du monde Mainframe, quelles sont les ‘best/bad practices’ en matière de code Cobol ?

Beaucoup de questions, et nous n’allons pas pouvoir répondre á toutes en un seul post. Celui-ci sera donc dédié à la présentation de différentes règles et défauts de qualité, fréquemment rencontrés dans les applications Cobol.

L’objectif est le suivant : vous avez effectué une analyse, les résultats apparaissent dans le tableau de bord Sonar. Et maintenant, par où commencer ?

Blockers

La première règle « bloquante » que vous allez rencontrer va probablement vous surprendre : ‘Avoid use of SQL’. Comment ? Il n’est pas possible de programmer des requêtes SQL en Cobol ? En fait, c’est complètement prohibé dans certaines organisations, qui ont mis en place des composants réutilisables en charge de l’accès á la couche de données.

La raison en est simple : si chaque développeur ajoute ses propres requêtes SQL chaque fois qu’il doit accéder à une table, les accès à la base de données se multiplient au fil du temps. Les applications Cobol sont les plus anciennes qui soient, et au cours des années, pour ne pas dire des décennies, les ‘update / insert / delete’ se sont multipliés. Dés lors, toute modification de la structure de données d’une table nécessite de modifier des dizaines de requêtes SQL redondantes dans différents programmes, donc un effort de maintenance très important et un risque élevé d’oublier un programme et donc de créer un bug.

Toutefois, réserver les accès á la couche de données à un ensemble de composants réutilisables nécessite une équipe dédiée à la maintenance de ces programmes, et un processus de demandes justifiées de modifications de la part des autres équipes. Assez lourd, coûteux en temps, donc l’interdiction de programmer en SQL ne se rencontre pas dans toutes les entreprises.

Ce qui explique que cette métrique soit optionnelle, et désactivée par défaut (sur ce sujet, voir notre post précédent Quality Profiles). Donc vérifiez auprès des équipes Cobol si cette ‘bonne pratique’ existe ou non, afin de savoir si vous devez activer ou non cette métrique.

Sinon, vous risquez de rencontrer le cas suivant :

Présenter un dashboard avec 18 000 défauts ‘bloquants’ interdisant les requêtes SQL risque de créer une certaine incompréhension de la part de l’équipe Cobol.

Autres blockers :
Un STOP RUN est tout simplement une interruption du programme. Tout s’arrête, les programmes montés en mémoire sont supprimés de celle-ci, les fichiers fermés, retour direct à l’OS. Cette instruction doit donc être utilisée avec précaution (voire même interdite). Et dans tous les cas, il ne peut pas y avoir de code après un STOP RUN puisque ce code ne sera pas exécuté.

J’ai trouvé ces 4 blockers au sein de cette application :

Vous imaginez cette fois que vos interlocuteurs seront très heureux que vous ayez identifié ces 4 défauts au sein de plus de 2 millions de lignes, dont prés d’1.5 million de lignes de code (le reste est du commentaire). Rien que cela justifie complètement votre travail d’analyse.

J’ai également trouvé dans cette application 10 Performs recursifs.

Le code Cobol est organisé dans un programme en une succession de paragraphes qui sont l’équivalent de procédures ou fonctions (pour faire simple, nous n’allons pas commencer un cours de Cobol dans ces pages). Un Perform recursif est donc l’équivalent d’une procédure s’appelant de manière récursive.

Sonar nous montre la ligne où se rencontre cette ‘bad practice’ :

Comme le montre cet exemple, le Perform récursif se rencontre généralement dans un code compliqué bourré de IFs ímbriqués, et ici dans un ‘Else’. Donc si l’une des conditions précédentes n’est pas vérifié, le risque est important de se retrouver dans une boucle récursive infinie. De plus, cela complique énormément la compréhension du code, donc augmente encore le risque d’introduire une erreur lorsque le développeur effectue une modification. Donc c’est dangereux et tout programmeur Cobol le sait bien (sauf les petits génies qui veulent à tout prix programmer des paragraphes récursifs).

Un dernier blocker que vous rencontrerez probablement peu souvent :

Un Perform Thru est une exécution successive de différents paragraphes. Par exemple, imaginons 3 paragraphes consécutifs A, B, C et une instruction ‘Perform A thru C’, alors les paragraphes A puis B puis C seront exécutés. Problème : si B est défini avant A, alors seuls A et C seront exécutés, ce qui n’est pas l’objectif recherché.
Encore une fois, il est rare de rencontrer ce type de défaut.

Critical

Toujours dans cette même application, voici les violations ‘Critical’.

Un défaut que vous allez rencontrer dans toutes les applications : un IF qui ne se termine pas par un END-IF. Par quoi se termine-t-il alors ? Par un point. Oui, un ‘.’ minuscule et facilement inaperçu. La moindre crotte de mouche à l’écran et c’est l’erreur assurée. Vous n’imaginez pas les milliers d’heures passées à débuguer des programmes Cobol à cause de ce fichu point.

Tous les programmeurs le savent et tout le monde respecte cette ‘best practice’ de nos jours, mais ce ne fut pas toujours le cas. En fait, plus l’application est ancienne, plus vous rencontrerez ce défaut. Cela peut justifier de dégrader la sévérité de cette règle de ‘Critical’ à ‘Major’. Elles sont souvent trop nombreuses pour envisager de les corriger. Et puis, évitez de démoraliser les équipes Cobol en leur présentant un tableau de bord avec des milliers de défauts critiques.

Certaines de ces règles sont facilement compréhensible par des non-cobolistes, comme la nécessité d’initialiser les données passés en paramètres d’un CALL, les requêtes SQL imbriquées ou l’utilisation de SQL dynamique (pratique peu courante toutefois chez les développeurs Cobol). D’autres semblent plus ésotériques, mais sont toutefois assez simples.

La Linkage Section définit les données qui peuvent être partagées entre programmes. Comme pour les requêtes SQL, si chaque développeur commence à modifier cette structure de données en en supprimant certaines par exemples, le risque est de voir les autres programmes appelant ce dernier ne plus fonctionner. Donc il serait souhaitable de définir ces données dans un Copy-Book. Mais comme pour les requêtes SQL, cela suppose une certaine organisation de programmeurs gérant ces données, donc cette règle ne s’applique pas souvent.

Elle est d’ailleurs désactivée dans le Quality Profile par défaut de Sonar, tout comme la règle d’initialisation des paramètres d’un CALL. Ceci explique donc le nombre de violations trouvées dans cette application pour ces deux règles. Donc là encore, vérifiez avec l’équipe Cobol si elles s’appliquent et éventuellement, désactivez-les. Personnellement, je les mettrais en sévérité (pour) ‘Info’.

Un SORT est tout simplement une instruction de tri, malheureusement très coûteuse en performance. La règle qui prohibe son utilisation peut d’ailleurs être considérée comme ‘Critical’, sauf éventuellement lorsqu’il s’agit d’applications Batch. Mais tout le monde sera d’accord si vous préconisez de corriger ces défauts.

Un GOTO est un déplacement de la logique du programme vers un autre paragraphe. Plus connu comme le symbole même du code spaghetti. Par exemple, si lors d’un ‘Perform A Thru C’, le paragraphe B comporte un GOTO Paragraph D, on sort de la séquence initialement pensée puisque le paragraphe C ne sera pas exécuté, avec des conséquences parfois imprévisibles.

Donc un rapide examen de ces règles ‘Blockers’ et ‘Critical’ nous permet déjà une première évaluation de la qualité du code de cette application et une première ébauche de plan d’actions :

• Désactiver la règle prohibant l’usage du SQL : elle ne s’applique manifestement pas ici.
• Corriger au plus tôt les 4 STOP RUN et les 10 Performs récursifs.
• Le IF sans END-IF soulèvera certainement des soupirs de résignation de la part de vos interlocuteurs Cobol, mais sauf refactoring complet de l’application, ils sont certainement là pour longtemps. Néanmoins, vous pouvez leur indiquer de tenter de les corriger lors d’évolutions du code. Sonar vous aide en indiquant la ligne de code où ils sont présents.
• Désactivez également les règles concernant le passage de paramètres ou la Linkage section, manifestement non appliquées par l’équipe Cobol.
• Les autres défauts doivent être corrigés. Vous pourriez passer la règle prohibant l’usage du SORT en ‘Critical’.

Vous avez déjà de quoi faire une Quality Gate et demander à un provider les corrections mentionnées ci-dessus.

Nous continuerons cette évaluation de la qualité du code Cobol dans un prochain post, avec plus de règles encore. D’ici là, bonnes analyses Cobol.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.