{"id":323,"date":"2013-01-28T14:51:48","date_gmt":"2013-01-28T13:51:48","guid":{"rendered":"http:\/\/qualilogy.com\/fr\/?p=323"},"modified":"2013-01-28T17:07:57","modified_gmt":"2013-01-28T16:07:57","slug":"bonnes-pratiques-de-programmation-abap-les-defauts-critiques","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/bonnes-pratiques-de-programmation-abap-les-defauts-critiques\/","title":{"rendered":"Bonnes pratiques de programmation ABAP – Les d\u00e9fauts critiques"},"content":{"rendered":"

\"Qualilogy<\/a>Nous avons vu dans le post pr\u00e9c\u00e9dent les violations les plus graves aux bonnes pratiques de programmation ABAP<\/a>.<\/p>\n

Ces d\u00e9fauts sont bloquants : le code correspondant ne peut aller en production tant qu\u2019une correction n\u2019est pas effectu\u00e9e. Aucune exception n\u2019est permise : tol\u00e9rance z\u00e9ro, car le risque est trop \u00e9lev\u00e9 de voir une transaction interrompue et l\u2019utilisateur incapable d\u2019effectuer le traitement souhait\u00e9. <\/p>\n

Nous avons \u00e9galement param\u00e9tr\u00e9 notre Quality Profile ABAP de mani\u00e8re \u00e0 identifier les d\u00e9fauts critiques, ceux-ci portant principalement sur la performance, et que nous allons voir dans cet article.<\/p>\n

\"Mon<\/a> J\u2019ai oubli\u00e9 de le pr\u00e9ciser la derni\u00e8re fois, mais mon analyse ABAP porte sur environ 700 fichiers repr\u00e9sentant plus de 43 000 lignes dont environ 26 000 lignes de code (le reste est du commentaire). Ceci pour vous donner un peu une id\u00e9e du nombre de d\u00e9fauts par rapport \u00e0 la taille de l\u2019application.<\/p>\n

Les probl\u00e8mes de performance rel\u00e8vent principalement de bonnes pratiques non respect\u00e9es en mati\u00e8re de traitements SQL. A ce titre, ils ne sont pas sp\u00e9cifiques au code ABAP. Ci-dessous, les plus nombreux :<\/p>\n

\"SONAR<\/a><\/p>\n

Le SELECT * est une pratique \u00e0 proscrire dans tous les langages, puisque cette requ\u00eate ram\u00e8ne toutes les colonnes de la table. Si le nombre de lignes retourn\u00e9es est \u00e9galement important, alors la taille des donn\u00e9es \u00e0 transporter sur le r\u00e9seau risque d\u2019impacter la performance. De plus, si des colonnes sont ajout\u00e9es ult\u00e9rieurement dans la table, les donn\u00e9es correspondant \u00e0 ces nouvelles colonnes seront dans le SELECT * alors qu\u2019elles ne sont pas utilis\u00e9es.<\/p>\n

Un SELECT DISTINCT permet d\u2019\u00e9viter les lignes dupliqu\u00e9es, lorsque vous avez plus d\u2019une fois un m\u00eame enregistrement. Le probl\u00e8me est que ce traitement est tr\u00e8s lourd en termes de performance, surtout si certains des champs utilis\u00e9s avec la clause DISTINCT ne sont pas index\u00e9s. De plus, il faut s\u2019assurer que ce traitement soit utile car il arrive assez souvent qu\u2019il n\u2019y ait pas de lignes en double. Enfin, il est souvent possible d\u2019\u00e9viter ce traitement en repensant et programmant diff\u00e9remment la clause WHERE.<\/p>\n

D\u2019une mani\u00e8re g\u00e9n\u00e9rale, il n\u2019est pas recommand\u00e9 d\u2019acc\u00e9der \u00e0 une base de donn\u00e9es \u00e0 travers une boucle, surtout pour des traitements de mise \u00e0 jour des donn\u00e9es (INSERT, UPDATE, MODIFY, DELETE). G\u00e9n\u00e9ralement, la boucle indique que l\u2019on parcourt une table ou un ensemble d\u2019enregistrements afin d\u2019effectuer cette mise-\u00e0-jour. Le probl\u00e8me de performance peut s\u2019av\u00e9rer infime pour une nouvelle application avec une table contenant peu d\u2019enregistrements, mais au fil du temps les donn\u00e9es vont s\u2019ajouter dans cette table, sa taille va grandir, la boucle sera de plus en plus longue et les probl\u00e8mes de performance commenceront \u00e0 appara\u00eetre.<\/p>\n

Un SELECT sans condition, c’est-\u00e0-dire sans clause WHERE, ram\u00e8ne tous les enregistrements de la table. Il est souvent l\u2019indication d\u2019une erreur de programmation (oubli) ou d\u2019une programmation incorrecte. L\u00e0 encore, avec l\u2019ajout au fil du temps de donn\u00e9es dans la table, ce SELECT occasionnera un probl\u00e8me de performance.<\/p>\n

Ah, nous avons quand m\u00eame dans ces r\u00e8gles critiques une bonne pratique qui ne touche pas \u00e0 la performance, mais \u00e0 la stabilit\u00e9 de l\u2019application. Une instruction CASE \u2026 ENDCASE permet d\u2019effectuer diff\u00e9rents traitements (branchements) selon les diff\u00e9rentes valeurs d\u2019une variable ou d\u2019un champ. La clause OTHERS permet de pr\u00e9voir tous les autres cas (toutes les autres valeurs) non trait\u00e9s sp\u00e9cifiquement par le CASE. C\u2019est une simple question de gestion des erreurs : si un cas non pr\u00e9vu survient, l\u2019absence de la clause OTHERS signifie qu\u2019aucun traitement particulier ne sera effectu\u00e9. Le programme continuera de s\u2019ex\u00e9cuter, peut-\u00eatre de mani\u00e8re erron\u00e9 ou avec des valeurs incorrectes. Le risque est \u00e9lev\u00e9 que survienne une erreur et qu\u2019elle ne soit pas trait\u00e9e. De plus, cette erreur surviendra g\u00e9n\u00e9ralement bien plus loin dans le code, et donc la d\u00e9tection de son origine sera souvent assez longue et co\u00fbteuse en termes de maintenance.
\nCertains clients consid\u00e8rent que cette \u2018bad practice\u2019 est un Blocker : je suis assez d\u2019accord avec cela.<\/p>\n

\"SONAR<\/a><\/p>\n

Si nous regardons les d\u00e9faut suivants dans le code, on remarque que ceux-ci portent \u00e0 nouveau sur la programmation SQL.<\/p>\n

Un UPDATE ou un DELETE sans clause WHERE signifie une mise-\u00e0-jour ou une suppression de l\u2019ensemble des lignes de la table. Mieux vaut s\u2019assurer que c\u2019est bien le traitement esp\u00e9r\u00e9 et non pas\u00a0 une erreur !<\/p>\n

SAP propose un syst\u00e8me de buffer qui permet de lire une table directement depuis celui-ci et non pas depuis la base de donn\u00e9es, dans un objectif de meilleure performance. Or des traitements tels qu\u2019un JOIN ou des fonctions de calcul impliquant une agr\u00e9gation (COUNT, AVG, MAX, MIN, etc.) on pour effet d\u2019interdire l\u2019utilisation de ce buffer. Et cela, le programmeur ne le sait pas toujours !<\/p>\n

A fortiori, un traitement qui \u2018bypasse\u2019 le buffer \u2013 c\u2019est-\u00e0-dire \u00e9vite volontairement celui-ci \u2013 devra \u00eatre s\u00e9rieusement justifi\u00e9.<\/p>\n

Enfin, l\u2019utilisation d\u2019une clause LIKE ne permet pas, une fois de plus, de pr\u00e9dire le nombre d\u2019enregistrements retourn\u00e9s, notamment lorsque la table cro\u00eet au fil du temps. Et les queries imbriqu\u00e9s (SELECT \u2026 IN \u2026 SELECT) sont \u00e0 \u00e9viter, dans tous les langages.<\/p>\n

Il reste encore d\u2019autres r\u00e8gles critiques que nous n\u2019avons pas vu, tout simplement parce que je n\u2019ai pas rencontr\u00e9 de d\u00e9fauts de ce type dans le code que j\u2019ai analys\u00e9. Par exemple,<\/p>\n