Bonnes pratiques de programmation ABAP – Les Blockers

Bonnes pratiques de programmation ABAP - Les blockersAprès une interruption due à la réorganisation du blog – j’espère que vous appréciez la nouvelle interface – nous reprenons la série sur l’analyse de code ABAP.

Nous avions vu la dernière fois comment paramétrer notre première analyse de code ABAP, avec Sonar et Jenkins.

Cette semaine, nous allons examiner les premières règles ABAP, tout au moins les plus critiques en matière de bonnes pratiques de programmation.

Les douleurs dans le monde ABAP

Quels sont les défauts les plus redoutés par la plupart des entreprises ? Quelles sont les mauvaises pratiques de programmation qui présentent le plus de risque pour leur business ? Quelles sont les préoccupations principales des chefs de projet et des stakeholders ? Bref, quelles sont les douleurs dans le monde ABAP ?

  1. Tout ce qui peut interrompre une transaction en cours.
  2. Tout ce qui peut impacter la performance.

N’oublions pas que SAP est un logiciel financier, et qu’une erreur dans le traitement d’une opération signifie au mieux un retard, au pire une perte financière, et dans tous les cas une très mauvaise image. Si vous n’êtes même pas capable de facturer correctement, d’éditer une commande convenablement ou de gérer vos stocks sans erreur, comment voulez-vous qu’on ait confiance en votre entreprise, en vos produits, en votre personnel.

De plus, SAP est le progiciel préféré des grandes entreprises : le nombre de données collectées et manipulées dans le cadre de leur activité est extrêmement élevé, et les programmes ABAP doivent souvent gérer des tables de plusieurs millions d’enregistrement. La performance est donc un véritable souci, et toutes les bonnes pratiques en matière de programmation SQL seront en bonne place dans notre panel de règles ABAP.

Quality Profile

Je vais donc me créer un Quality Profile Sonar un peu différent de celui livré avec le plugin ABAP, afin de mettre en avant les règles les plus critiques en matière de robustesse et de performance.

Pour ce faire, je vais me connecter en ‘Admin’ sous Sonar, et configurer un nouveau Quality Profile. Je passe sur la marche à suivre, vous devez déjà la connaître et sinon, c’est très intuitif. Vous pouvez également voir ce post ‘Quality Profile’, sur la création d’un Quality Profile pour des règles Cobol, mais le principe reste le même.

SONAR ABAP ProfileVoici le résultat :

J’ai créé un ‘ABAP JPF Profile’ qui compte 51 règles. C’est-à-dire que j’ai activées 11 règles ABAP qui étaient simplement facultatives dans le Quality Profile par défaut ‘Sonar way’, parce qu’elles ne sont pas systématiquement utilisées par tous les clients. Mais je les trouve intéressantes, elles sont utiles dans le cadre d’un audit, et si une équipe de projet me dit qu’elles ne font pas partie de leur modèle qualité, alors il sera toujours possible de les désactiver ou de dégrader leur criticité.

Gestion des erreurs

J’ai ensuite lancé une analyse sur du code que j’utilise pour faire des démos. Voici les principales règles bloquantes ou Blockers dans SONAR.

Blockers SONAR ABAP

Deux règles permettent d’identifier une gestion incorrecte des erreurs : ‘Avoid calling a function module without handling exceptions’ et ‘Handle error codes when using CALL-FUNCTION’.

Les erreurs arrivent, personne n’est à l’abri d’un algorithme erroné, d’un cas non prévu, etc. Un traitement sans gestion des exceptions signifie une interruption de ce traitement, et donc de la transaction correspondante. L’utilisateur ne pourra terminer l’opération en cours, avec toutes les conséquences possibles et imaginables : corruption de données, ‘page blanche’, etc. Dans le pire des cas, il ne saura même pas qu’une erreur est intervenue.

La seconde règle identifie les appels à une fonction dont le code-retour n’est pas traité. C’est incorrect dans tous les langages, et significatif d’une ‘bad practice’ malheureusement assez courante. La plupart des applications ABAP sont sous-traitées à des outsourcers, parfois offshore, et vous ne savez pas quel est le niveau de connaissance de leurs équipes. Donc si vous rencontrez des traitements sans gestion du code-retour, vous interdisez la mise en production du programme correspondant et vous demandez à votre provider qu’il corrige immédiatement ce défaut.
Voire qu’il forme ses programmeurs à cette bonne pratique indispensable, si vous en rencontrez un nombre important. Sinon, même lorsque cette règle est connue, le manque d’attention est toujours possible qui sera la cause de quelques violations de ce type.

SONAR ABAP Handle error codePour information, le test du code retour se fait à travers le paramètre ‘SY-SUBRC’, comme nous pouvons le voir en allant regarder la ligne de code fautive.

Comment ? J’ai oublié de vous dire que vous pouviez descendre jusqu’à la ligne de code où se trouve la violation ? Et oui, inutile de chercher l’erreur dans plusieurs centaines de lignes de code, SONAR vous y amène immédiatement. Bien pratique lorsqu’il s’agit de vérifier celle-ci, ou pour le programmeur qui devra effectuer la correction.

Achtung Verboten !

Les deux autres règles concernent des instructions absolument interdites.

‘Forbid use of SYSTEM-CALL’ identifie un appel au noyau SAP. C’est absolument interdit parce que lors d’un upgrade de version SAP (ce qui arrive assez régulièrement), le traitement appelé risque de disparaître et donc le programme correspondant cessera de fonctionner.
Cette règle est bien connue, et je n’ai pas trouvé de violations dans le code ABAP dont je dispose. J’ai donc créé mon propre programme ‘Z_SYSTEM_CALL’ avec 38 exemplaires de cette instruction, tous avec une syntaxe différente.

SONAR ABAP System Call

Et je peux vérifier, dans la liste précédente des ‘Blockers’, que SONAR a bien reconnu ces 38 différentes syntaxes, sans aucun false-positive.

L’instruction ‘BREAK-POINT’ a pour effet d’interrompre immédiatement un programme. Elle est en fait utilisée pour déboguer celui-ci. Sa présence dans le code signifie tout simplement que le programmeur a oublié d’ôter celle-ci une fois son développement terminé. Si vous voulez coller la honte à un outsourcer, montrez lui les ‘BREAK-POINT’ dans la version qu’il vient de vous livrer. J’en rencontre généralement 1 ou 2 (ou plus) dans chaque application.

Tous les Blockers que nous venons de voir correspondent à des défauts à tolérance zéro. Ils doivent être immédiatement corrigés, aucune exception n’est admise et ce code ne sera pas installé en production. Certains peuvent considérer qu’une gestion incorrecte des exceptions est certes grave mais pas bloquante, mais c’est assez peu souvent le cas. La gestion du code-retour est dans le top 5 des Blockers pour la plupart des clients que je connais.

Nous verrons dans le prochain post les règles critiques, portant majoritairement sur la performance.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *