Découvrez la notion du design simple et comment ce dernier est appliqué en informatique avec les 4 règles du design simple selon Kent Beck .
Le design simple est un concept très important dans la programmation.
Il est à l’origine de plusieurs design pattern et pratique dont l’objectif est de simplifier nos codes sources et leurs comprehensions.
Dans cet article nous allons introduire le concept du design simple et entrer dans le contexte de la programmation avec les 4 règles du simple design selon Kent Beck .
Nous allons prendre le temps d’expliquer chaque règle de Kent Beck pour comprendre la bonne façon de programmer.
Sans plus tarder commençons par définir ce que c’est que le design simple.
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 !
C’est quoi le design simple de manière général ?
Le design simple est l’art de concevoir des procédés qui consistent à simplifier les processus de nos activités ou de nos œuvres. Tout ce qui est caractérisé par la plus simple, la plus concise , la plus précise avec le moins d’éléments possible est considéré comme le design simple.
Par exemple quand vous utilisez une télécommande vous n’avez parfois pas besoin de lire la notice avant de comprendre son utilisation.
Des fois vous n’avez même pas besoin de trop observer l’outil avant de le maîtriser .
Cela ne veut pas dire que vous êtes devenu expert en télécommande mais plutôt que ce dernier a été conçu de manière à ce que vous comprenez toute suite comment s’en servir .
Comment celà foctionne ? avec de très petits détails comme la disposition des touches, les petits logo et les couleurs placées aux touches spéciaux.
L’ensemble vous transmet un message claire et concis sur comment s’en servir avec des éléments visuels simples et minimaliste.
Dans le domaine des produits destinés au commerce, un bon designer s’aura concevoir une fiche produit vous permettrons d’apprendre facilement comment utiliser le produit, pourquoi il peut être utilisé de cette façon et, toujours avec le minimum d’éléments possible, vous montrer pourquoi il vaut ce prix.
Souvent dans les dessins des œuvres, les objets qui utilisent le concept de design simple sont très minimaliste.
Ils sont rarement surchargé d’objets superflu , complexes ou de pratique d’utilisation qui donne l’impression qu’il faut être un expert pour s’en servir.
Le concept du design simple ne s’applique pas toujours aux œuvres et aux produits physiques.
Le concept peut aussi s’appliquer aux processus, aux méthodologies de travail et aussi à notre style de vie.
Dans la suite de notre article nous allons vous montrer les questions qu’il faut se poser pour commencer à créer des objets , des processus ou des méthodologies suivant le concept du design simple.
Nous allons ensuite vous parler des conséquences du design simple dans le monde de l’informatique.
Question qu’il faut se poser pour appliquer le concept
Le design simple retient de manière très minimaliste l’essentiel de ce dont on a besoin pour chaque chose.
Pour faire une conception claire , concise , non ambigue et minimaliste suivant le principe du design simple il faut se poser les questions suivantes :
Est-ce nécessaire ?
Est-ce que ça sert à quelque chose ?
Est-ce la manière la plus simple de communiquer cette idée ?
Puis-je le décomposer en éléments plus simples ?
Quels sont ses impacts potentiels sur l’environnement ?
Les conséquences du design simple dans l’ingénieurie logiciel
Dans le domaine de la conception logiciel communément appelé l’ingénierie logiciel , le design simple a permi de générer divers concepts pratique et même des religions autour de la production du code source et de sa maintenance.
Vous avez certainement déjà entendu parler du refactoring, des design pattern, d’architecture logiciel etc. etc… Ces principes répondent aux besoins de toujours simplifier le code source d’un logiciel afin de pouvoir obtenir un logiciel de qualité.
Ce processus de simplification de code source rentre dans l’application du simple design dans la conception de logiciels .
En informatique plus précisement dans le domaine du développement d’application, plus un code source prend de l’âge, plus il devient complexe , souvent à cause des besoins de clients qui sont de plus en plus exigeante.
Plus le code est clair, simple , concis et précis , plus il est de qualité et mieux encore il permet de facilement travailler en équipe dessus pour la maintenir .
Maintenant que vous avez une idée de ce qu’est le design simple dans le contexte du développement d’applications, découvrons les 4 règles du design simple suivant Kent Beck qui constituent même aujourd’hui, le fondement de l’écriture d’un code de qualité.
Dans ce poste je vais introduire des concepts qui englobent selon moi tout le principe de design simple dans le domaine du développement d’applications.
Il s’agit des règles selon Kent Beck pour appliquer le design simple dans la conception de logiciel. ( sources : ).
Ces règles, vous allez voir , sont des règles sur lequel s’est construit de nombreux paradigmes , techniques et savoir-faire permettant de maintenir la qualité du code source sans le rendre incompréhensible ou complexe.
Dans cette section nous allons discuter des quatre règles fondamentales de Kent Beck pour pouvoir écrire du code simple et facile à comprendre.
On rappelle que 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.
Dans le domaine de la programmation , un code simple et facile à comprendre permet de faire un développement de qualité .
Un code confus, difficile à comprendre et trop complexe entraîne très vite la création de logiciels de mauvaise qualité et l’enfer de bugs pour l’équipe de développement .
Dans cette section nous allons parler des quatre règles permettant de concevoir un code simple et rigoureux. Ses règles présentez comme des commandements sont classés par ordre de priorité.
On distingue notamment :
1- Passe le test
2- Révéler l’intention
3- Pas de duplication
4- Le moins d’éléments.
Nous allons prendre le temps de vous expliquez chacune de vos règles dans la partie suivante.
Discutons sur la plus importante et la plus prioritaire des règles : Passe le test .
Cette règle est l’une des plus importante et aussi des plus difficile qu’on peut appliquer dans la programmation. Mais je vous assure qu’elle est efficace lorsque vous l’appliquez très bien.
Le principe signifie qu’avant même d’écrire votre première ligne de code sur les fonctionnalités du logiciel , il faut écrire leurs tests. Dans mon cas je procède souvent par le test unitaire.
Testez le logiciel avant même d’écrire le code qui va fonctionner sur ce test est une pratique contre intuitif mais qui reste efficace dans le développement de logiciel.
L’objectif est de pouvoir installer un cadre rigoureux pour coder sans dépasser les spécifications du produits.
Concrètement voici point par point ce que cette pratique apporte dans notre activité:
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. Vous comprendrez par la suite pourqoi!!
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.
Personnellement les tests unitaires spécifiquement m’ont de nombreuses fois servis d’exemple d’utilisation d’une fonction. Par exemple quand j’ai découvert une fonction dont je ne comprends pas comment m’en servir , je peux voir dans le fichier test comment il est utilisé . Je peux me servir du test unitaire pour expérimenter les portions de code.
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 chez moi jusqu’aujourd’hui ) concevoir une architecture et coder des portions du logiciel en se basant sur une utilisation future du programme.
Au lieu de me concentrer sur l’utilisation actuelle, j’écris du code en me 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.
Passer le test en premier est vraiment la base du tout bon design simple de code source.
Cela permet d’éliminer toute peur 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.
Les trois règles qui vont suivre permettront de valider la qualité de votre code source en se basant sur la première règle qui est le passage du test.
La seconde règle prioritaire est la révélation de l’intention.
2- Révélez l’intention
Maintenant que vous avez écrit le test de votre logiciel, vous devez pendant le codage vous concentrer à révéler l’intention de chaque portion de votre code.
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.
Les exemples qui vont suivre sont bien expliqué dans le livre et la vidéo de Clean code.
Vous pourrez suivre cette série de vidéo long et complète pour en savoir plus sur le Clean code et l’art de révéler votre attention dans le code source.
La programmation n’est pas un concours d’intelligence , c’est pour ça 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 règle suivante de Kent a la même priorité que la section suivante et doit à mon avis s’appliquer parallèlement à ce qu’on vient de voir.
La règle suivante consiste à éviter les 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 connu sous le sigle de DRY qui signifie Don’t repeat yourself.
Quand on dit d’éviter les duplications de code cela ne veut pas dire seulement d’éviter l’écriture des mêmes algorithme. Il faut comprendre qu’il y a deux types de duplication :
Il y a la 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.
Ensuite il y a ce qu’on appelle la 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.
La règle de non duplication s’applique beaucoup sur le dernier car il est plus difficile à trouver et une fois qu’on arrive à l’identifier, on peut simplifier en grande partie la base de notre 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.
Sans cette dernière partie on ne parlera pas du design simple.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 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 le cadre de la spécification de votre programme.
Avec cette règle , 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.
Vous devez supprimer tous les codes que votre programme n’utilise pas ou n’a vraiment pas besoin.
Parfois lors de notre travail de programmation , on a eu besoins d’écrire des parties ou des portions de code parce qu’on pensait qu’on aura besoin de ce dernier plus tard dans un futur proche pour les besoins du projet.
À la fin du produit quand vous réalisez que cette portion ou la fonctionnalité n’a pas été utilisée comme attendu, il est recommandé de le supprimer entièrement.
Maintenant que vous avez fini d’appliquer ces quatre règles de design simple , ce qu’il vous reste à faire c’est de vous entraîner régulièrement à l’appliquer de manière incrémental.
Plus on s’entraîne, et mieux on maîtrise.
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 !
Nous avons définis ce que c’est le design simple et comment il a permis aux concepteurs de créer des produits et des procédés de manière la plus simple et efficiente possible.
On a aussi parlé de l’influence du design simple en conception de logiciel informatique et comment l’appliquer en suivant les 4 règles du design simple selon Kent Beck.
Présentation d’un moteur de jeu 3D créé en java pour développer n’importe quels jeux 3D en java. Découvrez les ressources et les tutoriels pour créer un jeu 3d en java.
Découvrir et comprendre les 4 règles du design simple qui guident les meilleurs programmeurs dans l’art et la discipline de l’écriture du code. Plus vous le pratiquez et meilleurs vous serez dans le codage.
