Nous avons vu précédemment les défauts bloquants ou ‘Blockers’, ainsi nommés car aucune violation de ce type ne peut se tolérer, et les défauts critiques ou ‘Critical’, suffisamment graves pour nécessiter une correction immédiate, mais pour lesquels une exception peut – et doit absolument – se justifier.

Dans notre Quality Profile SONAR, les ‘Blockers’ portent sur tout ce qui peut interrompre une transaction ou un programme et les ‘Critical’  sur des pratiques de programmation qui présentent un risque pour la performance.

Nous allons terminer cette série sur les bonnes pratiques de programmation ABAP avec les règles restantes, qui vont concerner principalement la maintenabilité du code.

Notre application ABAP n’est pas de taille très importante : un peu moins de 700 fichiers pour environ 26 000 lignes, soit en moyenne 40 lignes de code par programme.

Le taux de commentaires est correct, au-dessus de 22%. Nous pouvons constater également un pourcentage important de code dupliqué.

 

Mais il s’agit là d’une moyenne qui peut donc refléter une variance et donc des réalités très différentes. Pour vérifier cela, allons voir ce que nous avons dans les défauts ‘Major’.

Niveau de commentaires

Les principales violations de ce type concernent des méthodes, classes, forms, functions, etc. sans aucun commentaires, ainsi qu’un certain nombre d’objets avec un niveau de commentaires insuffisant.

A noter qu’il existe un ABAP orienté Objet, avec des classes et des méthodes. Ce type de code n’est pas vraiment très répandu, mais l’on peut voir que SONAR sait analyser celui-ci.
SONAR liste également :

• Les fichiers avec une densité de commentaires inférieure à 20%.
• Les objets (définis dans ces fichiers) tels que les includes ou les programmes avec une densité de commentaires inférieure à 15%.

Un code est maintenable s’il est compréhensible. Plus un programme est long et compliqué, plus l’effort sera important pour introduire un changement dans celui-ci, et plus le risque sera élevé de créer un défaut par la même occasion. La présence de commentaires dans le code doit permettre au développeur de comprendre plus facilement la logique du programme, les évolutions antérieures et minimise donc les coûts de maintenance et les risques pour la stabilité de l’application.

Code dupliqué

Nous avons également 58 programmes, soit un peu plus de 8% du total de ceux-ci avec du code dupliqué.

Le code dupliqué est tout simplement du code ‘Copier-Collé’. Un développeur doit implémenter une fonctionnalité, un traitement déjà codé par ailleurs (généralement par lui-même), donc quoi de plus simple que de reproduire celui-ci autant de fois que nécessaire.

Cette ‘bad practice’ est certainement plus dangereuse qu’un niveau de commentaires insuffisant, car toute modification d’un de ces blocs de code devra être reporté sur l’ensemble de ses copies, sauf à ce que l’un d’entre eux cesse de fonctionner correctement. Cela multiplie donc d’autant le nombre de modifications à faire, sachant bien sûr qu’il est impossible de se rappeler de toutes ses duplications. L’effort de maintenance est considérablement accru, et surtout, le risque d’introduire un défaut devient très élevé.

Il est recommandé de corriger ces violations le plus tôt possible, en localisant celui-ci – avec SONAR par exemple – et en remplaçant les blocs dupliqués par des fonctions réutilisables.

Structure du code

Un code incorrectement structuré est difficile à lire.

Ici, nous avons des traitements de type CASE (pour plus de précision concernant cette instruction, voir le post sur les défauts critiques ou ‘Critical’) dont un ou plusieurs branchements (WHEN) comportent plusieurs lignes de code, ce qui veut dire que le développeur a programmé un traitement logique au sein d’une structure conditionnelle. Si ce traitement comporte plusieurs lignes (plus de 4 par défaut pour cette règle), il est recommandé d’encapsuler celui-ci dans une fonction qui sera appelée par le WHEN.

SONAR identifie les traitements conditionnels imbriqués, tels que les IF sur 3 niveaux ou plus. Introduire un changement dans une telle structure demande un effort important pour en comprendre la logique, donc plus de charges de maintenance et encore une fois un risque d’erreur plus élevé.

Idem pour les expressions conditionnelles trop complexes, avec plus de 4 AND ou OR. Ci-dessous, l’exemple de code incorrect fourni par SONAR pour illustrer cette règle.

Taille et complexité

D’autres défauts majeurs que l’on peut rencontrer dans une application ABAP, quoiqu’en nombre restreint dans celle que nous avons analysée : des programmes de taille importante ou comportant trop d’objets.

La complexité présente également un risque pour la maintenabilité d’une application,

En fait, on ne trouve quasiment aucun objet avec un niveau de complexité important dans cette application.

Conclusion

Rappelez-vous qu’il ne s’agit là que de quelques règles de type ‘Major’ pour lesquelles nous avons rencontré des violations dans le code analysé. Il en existe bien d’autres, que vous pouvez découvrir dans le Quality Profile ABAP de Sonar. Nous aurons problablement l’occasion de les examiner dans le futur, à l’occasion d’autres articles sur le monde ABAP.

Les équipes de projet, les responsables d’applications SAP ou les stakeholders pensent souvent que SONAR, parce qu’il est un outil Open Source, ne sait travailler qu’avec les nouvelles technologies ou J2EE uniquement. En fait, nous avons pu voir à travers cette série de posts qu’il est simple et rapide d’analyser du code ABAP avec SONAR, et mettre en place des processus – une Quality Gate par exemple – qui permettent de déceler les risques pour la robustesse et la performance, tout en contrôlant les coûts de maintenance.

 

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.