Comprendre les 4 règles du design simple

Les 4 règles du design simple sont inventés par l’un des développeurs les plus importants, Kent Beck . Ces règles constituent encore aujourd’hui les bases de l’écriture de codes de qualité.

Kent est le père de l’ XP Programming et de la TDD (Test-driven développement ) , un processus de développement où le test est au centre de tous le processus de validation. 

Son livre a eu du succès en mettant le test de code en première position avant tout écriture de code .

Ce qui a l’époque n’était pas une pratique commune de programmation et toujours aujourd’hui, reste une pratique contre-intuitive. 

Pour mieux comprendre le principe de ces règles, il faut savoir qu’en programmation , un code simple et facile à comprendre est perçu comme un code de qualité.

Plus le code paraît complexe et difficile à comprendre et plus, il est vu comme ” à refaire” et moins performants.

La raison est qu’un code difficile à comprendre amène très vite l’équipe chargé de le maintenir ( et même l’auteur du code ) à commettre des erreurs et très vite de créer un programmes de mauvaise qualité et plein de bugs .

Pour éviter celà et s’assurer que le code écrit est la plus simple possible, certaines règles doivent être respecté pour tester et valider au minimum la qualité de chaque portion de code .

Ses règles connues sous le nom des 4 règles du design simple de Kent Beck est présenté comme les 4 commandements du codage. Elles sont :

1- Passe le test

2- Révéler l’intention

3- Pas de duplication

4- Le moins d’éléments.

En premiez, passe le test !

1- Passe le test

Cette règle est l’une des plus importante et aussi des plus difficile à pratiquer. C’est le fondement de tout ce qui viendra par la suite.

Le principe consiste à écrire le test de votre fonctionnalité avant même de le produire .

C’est difficile à pratiquer parce qu’en débutant, on ne connaît pas forcément les arguments de notre futur fonction. On ne sait peut être pas que si ce qu’on écrit va résoudre notre problème.

Et pourtant il faut écrire le test avant même de produire le code. D’expérience dans cette pratique, le secret c’est de comprendre l’état d’esprit derrière.

Si vous ne savez pas comment tester la portion de code que vous voulez écrire , c’est que vous ne comprenez pas très bien sa place dans votre système.

Il faut (re)passer au stylot et au papier pour concevoir proprement votre programme. A ce stade, il faut penser comme un architecte logiciel si vous voulez allez plus loin.

Normalement, avant de prendre le clavier pour écrire du code, il faut comprendre le projet en l’analysant avec divers types de diagramme de conception.

Vous réglerez d’avance plus de problèmes sur papier qu’en écrivant le code.

Par la suite, il vous sera beaucoup plus simple d’écrire le test de chaque portion de code avant d’écrire la version en production.

 L’objectif de ce principe est de pouvoir installer un cadre rigoureux pour coder sans dépasser les spécifications du produits.

D’où l’importance de la phase de conception qui met les fondements et les limites.

Voici point par point les avantages de cette pratique :

• Le test permet de communiquer la conception du programme aux autres collaborateurs ou à soi-même.

• Grâce au test on peut dire spécifiquement quand on a fini de développer une fonctionnalité ou un système.

• Le test prévient la destruction du code lors des modifications, des mises à jour, des ajouts de fonctionnalités et aussi lors de la transmission du code aux autres développeurs.

• On peut s’en servir pour expérimenter un cas d’utilisation d’une fonction avant même de l’implémenter dans le code en production

Vous aurez compris écrire le test en premier est très requis pour poser les bases d’un code bien conçu et de qualité.

D’après l’auteur de ses règles, il n’est pas recommandé d’écrire du code en anticipation de ce qui va être fait plus tard.

Par exemple j’ai déjà rencontré des collègues (  même moi ça m’arrive quelques fois de ) concevoir une architecture et coder des portions du logiciel en se basant sur une utilisation future du programme.

Au lieu de se concentrer sur l’utilisation actuelle,  on écrit du code en se disant qu’on va le réutiliser plus tard d’une autre manière.

En fin de compte on finit avec du code complexe , avec des conceptions complexes , super trop flexible qui ne seront pas utilisé avant des années.

On y reviendra !!

Passer le test en premier pour tout portion de code

Cela permet d’éliminer toute peur et toute crainte de détruire le logiciel lors de la modification.

Cela permet aussi de valider le plan qu’on avait fait pour le logiciel.

La validation pour la suite est un ensemble de processus qui prendra 75% de vos efforts quotidien en programmation.

Les trois règles qui vont suivre consisteront uniquement à valider le code que vous avez fait passer en test.

Pour valider votre code, il faut révéler son intention .

2- Révélez l’intention

 Maintenant que vous avez écrit le test , il est temps d’écrire le code qui va valider ce test. La meilleur façon de s’y prendre est de vous concentrer à révéler l’intention.

Concrètement, cela veut dire qu’en pratique le nom de classe ,des variables, des fonctions et même des méthodes doivent exprimer ce que vous voulez en faire. Un code claire et concis doit réflèter le raisonnement qui va vous permettre de valider le test.

Les principes selon moi pour mieux révéler son intention dans le code est l’application du concept de Clean code.

Je dirai même que si vous maîtrisez le concept du clean code, vous n’aurez plus à lire les autres règles du design simple de Kent. Bon je continuerai de m’inspirer de ce concept pour expliquer les autres parties.

Vous pourrez suivre cette série de vidéo long et complète pour en savoir plus sur le Clean code.

La programmation n’est pas un concours d’intelligence , c’est pour ça qu’un code complexe difficile à comprendre n’est pas le code à garder pour son logiciel.

Par exemple lorsque vous écrivez une fonction , le nom de cette fonction doit dire ce qu’il fait concrètement.

Chaque fonction ou chaque méthode doit avoir qu’une seule responsabilité.

Cela veut dire qu’ils doivent traiter un problème précis à la fois. Chaque problème constitue une fonctionnalité ou une classe.

Une partie importante est aussi l’utilisation des commentaires.

Un code dont on a besoins de lire les commentaires pour le comprendre est complexe et mauvais.

Les commentaires n’ont pas pour but d’expliquer le code qu’on écrit.

Les commentaires doivent dire le pourquoi on fait cette fonctionnalité ou on écrit le code de cette manière au lieu d’expliquer ce qu’est le code.

Vous aurez compris ce qu’on veut dire par la révélation de l’intention dans son code.

La prochaine règle doit s’appliquer en parallèle avec la révélation de l’intention. Il s’agit d’éviter toute duplication de code.

3- Pas de duplication

Cela veut dire que le code que vous écrivez doit être unique dans tout votre base. Un morceau de code ou contenu de fonction doit être écrite qu’une seule fois.

Cette règle d’élimination de duplication est très connue sous le sigle de DRY( Don’t repeat yourself ).

Pour éviter les duplications de code , il ne faut pas seulement éviter l’écriture des mêmes algorithmes.

Il faut comprendre qu’il y a au moins deux types de duplication :

• Duplication de code : qui est vraiment la plus facile à identifier . C’est pratiquement le copié-collé exacte de ce qu’on a écrit dans une partie de code.

• Duplication de connaissances : ce type de duplication est très subtile à déceler mais une fois extrait elle permet de simplifier en grande partie le code source.

Maintenant que on a passé le test et on a écrit un code très simplifié sans duplication et facile à comprendre il ne reste qu’à vérifier qu’on l’a écrit de la manière la plus simple et la plus concise possible.

Cette dernière partie du design simple est une cerise sur le gâteau. Découvrez la règle du plus petit élément.

4 – Le plus petit élément

Après avoir révélé l’intention de votre fonction et appliqué toutes les règles de réduction de code en éliminant les duplications , il ne reste plus qu’ à conserver le plus petit élément de votre code.

Cette dernière règle vous permettra à la fois de valider tout ce que vous avez fait et de supprimer ce qui ne rentre pas dans la spécification de votre programme.

Nous sommes dans l’une des parties les plus difficile de l’écriture de code qui concerne la suppression de codes.

Kent va beaucoup plus loin en disant que toutes portions de code qui n’ont pas été spécifiquement mentionnées dans la conception doivent être supprimées.

Ce qui veut dire qu’il faut éviter la mise en commentaire d’un code en espérant l’utiliser plutard. Au pire, si vous êtes très attaché à ce code, enregistrez le dans votre logiciel de code-snippet.

Maintenant qu’on a fini avec les 4 règles de conception simple de Kent , tout ce qui vous reste à faire est de pratiquer au maximum.

C’est avec la pratique qu’on s’améliore !

Si vous avez aimé ce post , n’hésitez pas à vous abonner à notre Newsletter pour avoir plus de contenus exclusifs et surtout profiter des bons plans.

Restons en contact !