Écrire son code de manière lisible et compréhensible ? Un principe de bon sens pour de nombreux développeurs. Mais, dans la pratique, les fondamentaux du Clean Code ne sont pas toujours adoptés.
1. Clean Code : de quoi parle-t-on ?
Sous ses airs de buzzword à la mode, le Clean Code, en réalité, n’a rien d’une idée neuve. Son origine ? On en retrouve la trace dans le livre de Robert C. Martin, Clean Code : A Handbook of Agile Software Craftsmanship. Ce titre date de 2008, autant dire pas de la dernière pluie ! Pourtant, il continue de faire référence. Ne serait-ce que parce qu’il représente une somme de bon sens pour les développeurs et toutes celles et ceux qui s’intéressent, de près ou de loin, au développement logiciel.
Mais, si toutes et tous peuvent s’accorder sur l’intérêt d’une démarche prônant la qualité et la lisibilité du code écrit, sa mise en œuvre au quotidien n’est pas toujours aussi évidente. D’où, toute l’importance de revenir dans cet article sur les fondamentaux et les bénéfices principaux du Clean Code. Et de livrer, au passage, quelques conseils pratiques !
Une tentative de définition
Néanmoins, avant d’entrer dans le vif du sujet, un petit rappel semble de rigueur : pourquoi code-t-on ? Certainement pas pour “la beauté du geste”, comme le souligne avec malice Aurélien Castellarnau, Tech Lead chez Wemanity. “Derrière chaque démarche de développement, il y a toujours la volonté d’automatiser des actions métiers”. En d’autres termes, on code toujours pour un métier. Le code écrit par les développeurs ne saurait donc avoir du sens uniquement pour la machine. “Il doit aussi, et surtout, être compréhensible et intuitif pour tous les êtres humains qui auront à le lire”.
Cette première brique posée, une définition basique peut être esquissée : “un code estampillé Clean Code est un code qui se comprend et se lit facilement”. Mais la pratique Clean Code vise à aller un cran plus loin puisqu’il s’agit également d’écrire du code facile à entretenir. Pour Robert C. Martin, plus connu sous le nom d’Uncle Bob, 50 % du job des développeurs consiste, en effet, à faire en sorte que le code fonctionne. Quant aux 50 % restants ? Les développeurs les passent, explique notre expert, “à reprendre ce code qui fonctionne mais en cherchant à le retravailler afin qu’il devienne expressif pour un être humain”. Invisible, presque ingrate, cette seconde facette du métier de développeur n’en est pas moins essentielle. C’est elle qui permet au code de vivre dans le temps.
Exergue : Un code “clean” doit “être compréhensible et intuitif pour tous les êtres humains qui auront à le lire”.
Des principes en guise d’inspiration
Les principes développés dans son œuvre séminale par Robert C. Martin ne se présentent pas comme des règles à appliquer à la lettre ou, pire, comme un ensemble de dogmes. Il s’agit plutôt de guidances “pour s’assurer d’écrire du code en pensant à toutes les personnes qui vont devoir travailler dessus par la suite”.
Parmi ces principes, on peut citer les plus importants :
- Keep It Simple and Stupid (KISS) (“Gardez ça simple, stupide”) qui vise à éviter au maximum la complexité accidentelle. En opposition à la complexité nécessaire à la résolution d’une problématique, la complexité accidentelle handicapera les développements futurs ;
- You Ain’t Gonna Need It (YAGNI) (“Vous n’en aurez pas besoin) qui invite les programmeurs à ne pas ajouter de fonctionnalité à un logiciel tant que celle-ci n’est pas absolument nécessaire ;
- Don’t Repeat Yourself (DRY) (“Ne vous répétez pas”) qui consiste à éviter la redondance de code au sein d’une même application afin d’en faciliter la maintenance, le test, le débogage ou les mises à jour ;
- les principes SOLID, acronyme représentant 5 principes de conception destinés à produire des architectures avec un bon niveau de découplage des différentes unités logiques.
- Single Level of Abstraction (SLA) (“Un seul niveau d’abstraction”) qui insistent sur la nécessité de placer chaque ligne d’une fonction sur le même principe d’abstraction.
À ces principes fondamentaux s’en s’ajoutent d’autres comme :
- Suivre des conventions reconnues pour obtenir le code le plus universel possible ;
- Laisser le code plus propre qu’on ne l’a trouvé, la fameuse règle du “boy scout” ou du “camping sauvage” ;
- Respecter les règles fondamentales du design et du nommage, ne serait-ce que pour permettre à un développeur nouvellement embarqué dans un projet de comprendre le vocabulaire et le jargon employé et d’avoir une discussion avec un représentant du métier concerné ;
- Mettre en place des fonctions courtes, avec un usage unique, sans effet de bord et avec le moins d’arguments possible ;
- Soigner les commentaires, en étant clair, concis, en évitant les redondances et le bruit inutile ;
- Structurer le code source en soignant particulièrement les indentations, en déclarant les variables et en gardant le code structurellement cohérent.
L’ensemble des conventions du clean code peuvent être retrouvées ici: https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md
Mais parfois, même avec la meilleure volonté du monde, certains bouts de code échappent au grand ménage de printemps. Heureusement, Robert C. Martin nous indique comment repérer les codes insuffisamment propres, qu’il appelle les “code smells”. Les code smells sont :
- Rigides et donc difficiles à faire évoluer ;
- Fragiles et donc présentent de nombreux dysfonctionnements ;
- Immobiles et donc difficiles voire impossibles à réutiliser pour d’autres projets ;
- Inutilement complexes ;
- Répétitifs ;
- Opaques.
Développeur : un métier d’artisan
Notre présentation ne serait pas complète si nous n’inscrivions pas les travaux de Robert C. Martin et le Clean Code dans le mouvement plus large du software craftsmanship. Apparu à la fin des années 2010, ce courant de développement tend à rassembler des bonnes pratiques pour aider les développeurs à écrire du code propre et convenable. Mais au départ, l’artisanat logiciel n’est ni plus ni moins qu’un manifeste articulé autour de quatre principes très simples :
- Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus (Not only working software, but also well-crafted software).
- Pas seulement l’adaptation aux changements, mais aussi l’ajout constant de valeur (Not only responding to change, but also steadily adding value).
- Pas seulement les individus et leurs interactions, mais aussi une communauté professionnelle (Not only individuals and interactions, but also a community of professionals).
- Pas seulement la collaboration avec les clients, mais aussi des partenariats productifs (Not only customer collaboration, but also productive partnerships).
L’enjeu de l’artisanat logiciel ? Défendre l’idée selon laquelle c’est toujours mieux de disposer de logiciels bien conçus que de logiciels qui se contentent de fonctionner !
2. Clean Code : quels sont les fondamentaux ?
La qualité plutôt que la quantité
Une idée pas toujours facile à faire sienne si l’on se place du côté d’un sponsor ou d’un commanditaire. Pour eux, en effet, les contraintes peuvent amener à insister sur la rapidité d’exécution des développements. Ce qui peut entrer en opposition avec une démarche Clean Code pour qui, comme aime à le répéter Uncle Bob, “développer vite, c’est développer bien”. On comprend dès lors pourquoi, aux yeux de certains acteurs, le paradigme de Clean Code peut apparaître comme une contrainte, comme un obstacle à une livraison rapide du logiciel. Mais, prévient Aurélien Castellarnau, “attention, à cette fausse croyance ! La livraison rapide se transformera bientôt, et plus vite qu’on ne le croirait, en dette technique”.
Il s’agit donc de ne pas confondre vitesse et précipitation, de ne pas privilégier la rapidité au détriment de la qualité. Cette dernière doit également toujours primer sur la quantité. “Keep it Simple and Stupid” (KISS), “Don’t repeat yourself” : autant de principes qui nous invitent à éviter la suringénierie (over-engineering) ou à ne pas écrire du code dont on n’a pas besoin immédiatement. Du bon sens ? Pas toujours. En présence de problématiques complexes, comment ne pas être tenté, en effet, de prévoir le futur en écrivant du code qui servira peut-être un jour ou de “sur-ingénierer” une solution ? “Des pièges dont il faut pourtant se prémunir”.
Exergue : “Attention, à cette fausse croyance ! La livraison rapide se transformera bientôt, et plus vite qu’on ne le croirait, en dette technique”.
Tester avant de coder
Comment ? En adoptant, par exemple, une méthode de développement logiciel piloté par les tests. Le Test Driven Development (TDD) pousse les développeurs “à faire émerger le code grâce aux tests, pas après pas, ligne après ligne”. Itérative et incrémentale, cette technique consiste en une série d’allers-retours, du test au code et inversement. Ici, précise Aurélien Castellarnau, “le but n’est pas d’écrire du code propre par essence mais le strict code nécessaire sans rajouter de superflu”. Ce qui permet aussi aux développeurs de se concentrer moins sur le “Comment ?” que sur le “Pourquoi ?”, moins sur l’implémentation de la solution que sur le besoin.
Les tests réalisés doivent être rapides, indépendants, utiles, répétables et faciles à lancer. Ils peuvent être associés à deux autres méthodologies :
- Le Behavior Driven Development (BDD), une approche de découverte par le biais de scénarios qui aspire notamment à éviter tout quiproquo entre les différents acteurs impliqués au sein d’un projet mais aussi de sonder les besoins de ceux-ci en fonction du comportement utilisateur attendu ;
- Le Domain Driven Design (DDD), une approche complète et approfondie qui prend en compte l’ensemble de la chaîne de production logicielle, de l’élaboration du besoin jusqu’à la livraison, sans oublier l’architecture logicielle.
Gérer la dette technique plutôt que l’ignorer
Sans ces méthodologies, il est bien sûr tout à fait possible de s’en sortir… du moins au début ! Car, avertit notre expert, “au bout de 2-3 ans, une équipe de développeurs qui n’appliquerait pas les principes du Clean Code va ressentir les premiers signes de souffrance”. L’absence de Clean Code introduit, en effet, de la pénibilité dans le travail quotidien des équipes. D’où, toute l’importance de “faire comprendre au sponsor que sa hantise, en réalité, ce n’est pas deux jours de plus dans la livraison de tel logiciel ou telle autre fonctionnalité, mais la dette technique. Ce qu’il aura gagné au début, il devra le dépenser à la fin…”
Le Clean Code possède la qualité d’avoir une certaine constance dans la capacité de livraison. Il donne donc de la visibilité au commanditaire. En revanche, il n’empêche pas d’éviter la dette technique. Tout simplement, parce que c’est impossible ! “Dès l’instant où vous écrivez la moindre ligne de code vous remettez une pièce dans la ‘machine dette technique’”. En jeu ? Apprendre à gérer cette dette. Ce qui suppose de “ne pas considérer comme optionnels le testing, la compréhension des métiers par les développeurs, l’interaction entre les équipes ou la séniorité de celles-ci”.
3. Clean Code : comment l’appliquer au quotidien ?
Comprendre ce qui bloque
Cette dernière est souvent en cause quand nos experts sont sollicités par nos partenaires. Mais, la jeunesse des équipes ne saurait à elle seule expliquer l’absence de Clean Code. Elle constitue en quelque sorte une “circonstance aggravante”. Difficile, en effet, pour un jeune développeur de se sentir suffisamment légitime pour démontrer pourquoi sa méthodologie est pertinente par rapport à un besoin business donné et résister à la pression de la vitesse.
Aussi, observe Aurélien Castellarnau, “les développeurs possèdent-ils un réel devoir de pédagogie. Aujourd’hui, plus que jamais, ils doivent être capables d’expliquer ce qu’ils font et pourquoi ils le font comme ils le font”. Mais, pour ce faire, la collaboration entre commanditaire, bénéficiaires et développeurs doit être la plus étroite possible.
Comprendre les métiers et leurs besoins
Ce qui suppose, pour les développeurs, de s’intéresser au métier qu’on leur demande d’automatiser, de comprendre les besoins des professionnels, l’usage qu’ils pourront avoir du logiciel en devenir.
“Le software craftsmanship met à disposition des équipes des outils pour faciliter l’interaction entre métiers et développeurs”. Ces derniers peuvent s’appuyer sur le travail des “fonctionnels” dont la tâche consiste précisément à s’intéresser au fonctionnement du métier. Pourquoi ne pas organiser également des events storming ? Ces ateliers peuvent s’avérer d’une aide précieuse “pour travailler, par exemple, sur la modélisation des actions réalisées au quotidien par tel ou tel autre métier”.
Comprendre les outils à notre portée
Autres outils ? Le pair programming ou le mob programming, à savoir le développement à deux ou en équipe sur un même sujet. Le premier permet de porter des regards multiples sur le code et de repérer les bugs dès leur introduction ; le second sollicite la force de l’intelligence collective en cas d’urgence mais pas seulement.
L’un et l’autre soulignent surtout l’importance de la notion de “communauté de pratique” du manifeste Software Craftmanship. Et notre expert d’ajouter, “je ne peux qu’encourager les entreprises à se demander si leurs équipes communiquent suffisamment entre elles ou à s’interroger sur l’existence ou non d’espaces dédiés à la transmission de connaissances”.
Preuve s’il en fallait encore une qu’un code propre s’écrit à plusieurs mains et non tout seul derrière son écran d’ordinateur !
Un code “propre” est en réalité, ni plus ni moins, un code lisible pour tous les individus qui l’auront, un jour ou l’autre, devant les yeux.
Si votre code se révèle difficile à faire évoluer ou à réutiliser dans le cadre d’un nouveau projet, s’il présente de nombreux dysfonctionnements ou d’inutiles répétitions, s’il se montre en certains endroits répétitif ou opaque, alors il y a fort à parier qu’il ne soit pas si propre que ça !
Issue de l’artisanat logiciel, la démarche du Clean Code s’adosse sur la qualité des codes écrits mais aussi, et surtout, sur l’esprit de communauté entre les développeurs et les interactions continues entre eux, les équipes, les métiers et les commanditaires.