Une règle est connue ou elle ne l’est pas. Une ‘best practice’ est appliquée ou ne l’est pas. Mais si elle n’est pas appliquée, serait-ce parce qu’elle n’est pas applicable ?

Vous devez présenter les résultats de vos premières analyses Cobol et bien sûr, vous souhaitez que ceux-ci soient les plus pertinents possible afin de prouver la valeur de ces analyses aux équipes de projet, providers, stakeholders, etc.

Ceci suppose de définir un modèle qualimétrique – un ensemble de règles et de niveaux de criticité de celles-ci – qui permette d’identifier rapidement les ‘bad practices’ les plus coûteuses et les plus dangereuses. Evidemment, vous devez éviter de dénoncer comme défaut grave une violation à une ‘best practice’ qui n’est pas en vigueur– par exemple, l’utilisation de code SQL (cf. notre dernier post).

Quelles sont les règles applicables ou non ? Quels seuils de criticité choisir ? Comment ajuster le modèle qualimétrique en un Quality profile Sonar pour nos applications Cobol ?

Nous allons montrer dans ce post comment définir votre propre modèle Qualité, à l’aide d’une View Sonar et d’un widget bien utile.

Délivrer la valeur

L’analyse de code Cobol réalisée lors de notre dernier post nous a permis de constater deux types de valeurs différentes lorsque l’on regarde le nombre de violations d’une règle :

• Un nombre très élevé, jusqu’à plusieurs milliers ou plusieurs dizaines de milliers : la règle n’est vraisemblablement pas applicable et il faut probablement l’exclure de notre Quality Model.
• Un nombre très faible : la règle est connue et appliquée, mais vous ne pourrez jamais éviter totalement le manque d’attention de la part des développeurs, et quelques rares défauts mais dont les conséquences peuvent s’avérer très graves pour les utilisateurs finals.

Cependant, il existe des exceptions propres au modèle Cobol, comme le IF sans END-IF, ‘bad practice’ très ancienne dont les développeurs actuels ne peuvent être tenus responsables. Nous avons vu que dans ce cas, nous pouvons baisser la sévérité de cette règle.

Nous pouvons ausi proposer de rehausser la criticité de certaines autres : par exemple, passer la règle prohibant l’instruction SORT de ‘Critical’ à ‘Blocker’. C’est là qu’un outil d’analyse de code révèle tous ses bénéfices : dans la détection automatique d’un nombre limité de défauts graves ou critiques que l’on pourra corriger facilement. C’est l’un des moyens les plus sûrs de transformer vos résultats d’analyse en valeur pour vos interlocuteurs.

Afin de construire un modèle qualimétrique qui maximise cette valeur, il vous faut faire les bons choix sans connaître les ‘best practices’ en vigueur. Afin de découvrir celles-ci, vous pouvez :

• Demander le cahier des normes de programmation et autres standards Cobol. Celui-ci est le plus souvent inexistant, et lorsqu’il existe, le plus souvent obsolète et inappliqué.
• Lister l’ensemble des règles Cobol et organisez une réunion avec l’équipe Cobol : vous risquez de passer beaucoup de temps à expliquer des règles qui ne sont pas appliquées et que vous maîtrisez mal si votre connaissance du monde Mainframe est limitée.
• Examiner les résultats de vos analyses afin d’identifier les règles applicables ou non, et proposez un modèle Qualité.

Plugin Views

Pour cela, nous allons commencer par créer une vue qui regroupe toutes nos analyses Cobol, avec le plugin Views. Il suffit de se connecter en Admin, et d’aller dans le menu ‘Configuration’, puis ‘Views’.

J’ai créé une ‘View Cobol’ à laquelle j’ai affecté les projets déjà analysés. Il me faut relancer au moins un de ces projets afin de voir apparaître ma View Cobol dans le dashboard Sonar. Voici le résultat :

Comme vous pouvez le constater, nous disposons ainsi d’un échantillon intéressant : des applications de taille différente, représentant plus de 5 millions de lignes Cobol dont plus de 3.3 millions de lignes de code, dans 6 714 fichiers. Seule 1 application n’est pas en rouge, toutes les autres présentent un degré de respect des règles Cobol proche du zéro absolu.

Widget ‘Most violated rules’

Nous allons profiter que nous sommes connectés comme ‘Admin’ pour ajouter un widget qui nous sera bien utile.

Sélectionnez le menu ‘Configure widgets’, puis dans la liste des widgets, ajouter le suivant dans votre dashboard : la liste des règles avec le plus de violations.

Le menu ‘Edit’ du widget nous permet de modifier ces paramètres, par exemple afin d’afficher les 15 règles les plus souvent en défaut :

Bouton ‘Save’ afin de sauvegarder ces paramètres, puis ‘Back to dashboard’ afin de connaître les 15 règles avec le nombre le plus élevé de violations.

Vous comprenez maintenant pourquoi presque toutes les applications analysées sont en rouge. Si vous montrez ce tableau de bord tel quel aux équipes de projet et à vos interlocuteurs, ils vous diront que ces analyses n’ont aucune valeur puisqu’elles prennent en compte des règles qui ne sont pas applicables.

Sélection des règles

Ce widget va nous être bien utile afin de repérer des règles que nous pouvons immédiatement exclure de notre modèle qualimétrique :

• COMP (COMPUTATIONAL) est un type de données qui laisse au compilateur le choix de définir l’allocation en mémoire de cette donnée. Comme les compilateurs varient selon les plates-formes, cette clause peut poser des problèmes de portabilité. Or la migration de patrimoine Cobol entre différent mainframes survient très rarement, donc cette règle est rarement un souci. D’autre part, ce format est privilégié car plus performant, puisque proche du compilateur.
• ‘Magic Literal’ / ‘Magic Number’ sont des ‘best practices’ qui consistent à utiliser des constantes et non pas des valeurs (numériques ou alphanumériques) ‘en dur’. Ce ne sont pas des règles spécifiques au Cobol, on les rencontre dans tous les langages, mais elles sont peu appliquées dans le monde Mainframe.
• ‘Using paragraphs’, ‘Perform Paragraph / Section’. Ce sont des règles de structuration du code Cobol qui, avec plus de 100 000 violations, ne s’appliquent manifestement pas. Elles sont de plus exclusives l’une de l’autre.

De nouveau, nous n’allons pas faire un cours de Cobol et préciser toutes ces règles. L’objectif est de montrer qu’avec notre View Cobol et ce widget, nous pouvons rapidement affiner notre modèle qualimétrique. Les 5 premières règles listées ci-dessus peuvent être désactivées sans aucun souci.

Autres avantages du widget ‘Most violated rules’ :

• Sélectionner une criticité afin de noter les règles à exclure ou dont changer le seuil de sévérité.

Ici nous retrouvons les 3 (premières) règles Critical que nous avions souhaité écarter dans notre dernier post. Nous avions noté également de passer le ‘Avoid using SORT statement’ à ‘Blocker’.

Je vais également baisser ‘Limit the number of lines in a WHERE clause’ et ‘Avoid nested SQL SELECT statements’ à une criticité ‘Major’ car ces ‘best practices’, certes critiques pour la lisibilité et la maintenabilité du code, n’ont pas d’impact sur les utilisateurs. Or je souhaite axer la valeur de mon modèle qualimétrique sur les défauts qui présentent le plus de risque pour ces derniers, donc les bonnes pratiques en matière de robustesse et de performance. Par exemple, je vais probablement remonter quelques règles SQL vers une sévérité plus élevée.

• Sélectionner une règle afin de vérifier quelles applications de la View Cobol l’appliquent ou non.

Ici, nous pouvons voir que la règle prohibant l’utilisation de requêtes SQL ne concerne que 4 applications sur les 7 que comptent la View Cobol. Nous avons là un exemple de règle qui s’appliquera différemment selon les équipes.

Votre modèle Qualité

Avec une View Sonar et le widget ‘Most violated rules’, vous pouvez facilement définir votre propre modéle Qualité en moins d’une heure, même sans être un expert du monde Mainframe.

Vous pouvez identifier les règles qui manifestement ne s’appliquent pas, vu le grand nombre de défauts rencontrés. Vous pouvez vous concentrer sur celles qui comptent peu de violations car elles sont certainement connues et appliqués par les équipes Cobol.

Il vous faut un échantillon suffisamment important pour que les nombres de défaut prennent tout leur sens. Analysez plusieurs applications et agrégez les dans une View Sonar.

Choisissez un axe de valeurs pour vos interlocuteurs:

• Réduire le risque de bugs pour les utilisateurs : privilégiez les règles affectant la fiabilité des applications et leur performance.
• Réduire les coûts de maintenance : mettez en avant les règles impactant la maintenabilité et la lisibilité du code.

2 posts sur ce sujet : Quelle est la première question ? et Best of both worlds. Afin de privilégier certaines règles, passez les en ‘Critical’ ou ‘Blockers’.

Définissez un Quality profile Sonar pour votre nouveau modèle Qualité. Ré-analysez les applications et regardez les résultats sur votre portefeuille applicatif dans le dashboard Sonar.

Vous constaterez immédiatement que vous pouvez maintenant aller directement à l’essentiel dans l’identification des causes principales de risques et de coûts. Votre présentation du dashboard Sonar n’en aura que plus de valeur.

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.