Bonjour à tous,

Je poursuis la série sur les bonnes pratiques de développement ABAP , avec quelques mots sur le principe KISS, bien connu (en théorie…) des développeurs de tout langage. D’ailleurs, cet article ne parle pas de l’ABAP, mais énonce des généralités sur l’application de ce principe de sim-pli-ci-té.

Le principe KISS…
Le principe KISS énonce qu’il faut toujours choisir la solution la plus simple. Il s’agit d’un acronyme qui peut prendre plusieurs significations plus ou moins proches les unes des autres :

• Keep it simple, stupid
• Keep it small and simple
• Keep it sweet and simple
• Keep it simple and straightforward
• Keep it short and simple
• Keep it simple and smart
• Keep it strictly simple
• …

On l’aura compris, le maître mot est simplicité.
Le principe KISS est similaire au Rasoir d’Ockham qui dit que, en science, la théorie à privilégier parmi plusieurs est celle qui fait le moins de suppositions pour expliquer les observations.

Règle de base…
La bonne pratique SAP (mais pas que) suggère d’utiliser ce principe KISS systématiquement, de façon à limiter au maximum la complexité des programmes.

Détaillons un peu…
La meilleure solution à un problème est généralement la solution la plus simple, minimaliste et facile à comprendre, tout en assurant stabilité, compréhensibilité et maintenabilité en plus de la correctitude fonctionnelle.
D’une façon générale, il y a pléthore d’exemples de non mise en œuvre du principe KISS. Historiquement, les raisons peuvent être les suivantes :

• Des programmes qui dès le départ sont trop complexes. Ceci peut être dû à une mauvaise conception ou à une programmation non rigoureuse ;
• Des programmes qui évoluent sur une durée conséquente. Au lieu de créer de nouvelles implémentations pour les anciennes et les nouvelles fonctionnalités, ces dernières sont simplement ajoutées (souvent via des structures de contrôles IF) aux anciennes. Les programmes qui étaient initialement simples deviennent ainsi complexes, alors que le traitement requis ne l’est pas forcément.

Le principe KISS ne s’applique pas uniquement au moment du codage, mais aussi (et surtout) lors de la phase de conception technique.
Pour développer en respectant le principe KISS, il faut s’assurer dès le début que la complexité du programme reste gérable. Nous aborderons les règles qui suivent ce principe lorsque nous traiterons de la structure et du style des programmes, en particulier les commentaires et la complexité.

Note…
Si les programmes existants n’adhèrent pas au principe KISS et que ceux-ci nécessitent une évolution (ou une correction), il est recommandé de les refactoriser afin d’intégrer ce principe. Pour information, refactoriser signifie retravailler un code source de façon à l’améliorer en conservant les mêmes fonctionnalités. Les améliorations ont donc pour but d’accroître la lisibilité, la compréhensibilité, la maintenabilité et l’extensibilité, tout en réduisant considérablement l’effort requis pour cibler les anomalies et améliorer les fonctionnalités.
La refactorisation (incrémentale) n’est pas seulement utile pour le principe KISS, mais pour tous les autres principes et règles que je vous présente dans cette série d’articles sur les bonnes pratiques de développement (ABAP ou non).

Ceci clôt cet article d’introduction au principe KISS.
Le prochain article de cette série présentera les termes de correctitude et de qualité logicielle. En les définissant ainsi qu’en abordant le thème des normes et des standards métiers, ainsi qu’en listant quelques outils SAP pour développer en respectant ces principes.