4 minutes

Tout informaticien a déjà entendu parler au moins une fois des « bonnes pratiques de développement », qui si elles sont suivies, doivent permettre de produire du « clean code ». Ce code source produit est censé être clair, bien organisé et efficace. Ce code propre est plus facile à maintenir et à faire évoluer, même si l’équipe de développement change. Le livre « Clean Code » est en quelques-sortes un manuel expliquant les règles de développement à suivre afin de produire du meilleur code.

A propos de l’auteur

Robert C. Martin, aussi connu comme « Uncle Bob » (« Oncle Bob ») dans le monde du développement logiciel, est l’un des principaux membres du mouvement de conception logicielle nommé « Clean Code ». Il a commencé sa carrière dans l’informatique dès 1970. Internationalement connu et reconnu depuis les années 1990, cet expert du consulting a participé à des centaines de projets durant sa longue carrière.

Il a pris part en 2001 à la mise sur pieds du groupe de travail qui a créé les bases des méthodes de développement agiles et les techniques de l’eXtreme Programming. Il a également été président de l’Alliance Agile.

Robert Martin est l’auteur de nombreux livres et articles sur des sujets aussi divers que la programmation agile, l’eXtreme Programming, UML, la programmation orientée objet, la programmation C++, et bien sûr, le « Clean Code ».

Robert Martin a fondé et dirige plusieurs structures telles que « Uncle Bob Consulting » et participe régulièrement à des conférences et à des salons tout autour du monde.

Quel est l’intérêt du « Clean Code » ?

De nombreux logiciels fonctionnent malgré un code « sale », c’est-à-dire mal écrit et mal organisé. Pourquoi s’en faire alors ? Pourquoi se plier aux contraintes de rédaction d’un code propre, augmentant le temps de développement et donc les coûts de création d’une application ? Pourquoi passer du temps à réécrire un code existant pour le rendre propre si tout fonctionnait avant ?

Une application composée de code sale peut très bien fonctionner. Le problème se posera le jour où elle ne fonctionnera plus, où l’infrastructure l’hébergeant changera, ou bien où elle devra évoluer. Le temps gaspillé et les ressources nécessaires à l’analyse du code, à son nettoyage ou à sa réécriture seront à même de mettre en péril le projet, voire même l’entreprise dans les cas les plus graves.

L’utilisation des bonnes pratiques de programmation a donc pour but d’obtenir un code propre, c’est-à-dire un code organisé, clair et facile à lire, écrit dans le but d’être relu et modifié par d’autres développeurs, et testé. Le code doit être le plus simple possible, éviter les duplications et limiter les dépendances (couplage faible).

Un code propre assurera la qualité et la stabilité de l’application. On mesure la stabilité d’une application ou d’un logiciel au coût de l’ajout d’une fonctionnalité qui reste stable dans le temps. Avec un code mal organisé et mal écrit, la dette technique va s’accumuler et l’application deviendra de plus en plus complexe à faire évoluer. C’est un peu comme si un technicien câblait le tableau électrique d’un immeuble sans mettre de repère, en utilisant des fils d’une seule couleur. Il devient rapidement impossible de s’y retrouver.

Que trouve-t-on dans ce livre ?

Les pratiques décrites dans le livre « Clean Code » s’adressent avant tout aux utilisateurs de langages de programmation évolués, orientés objet.

« Clean Code » se divise en trois grandes parties.

La première partie explique les grands principes et les bonnes pratiques permettant de produire un code propre.

Les principes de base sont simples. Il s’agit globalement d’écrire son code non pas pour soit, mais pour les futurs lecteurs et développeurs qui prendront la suite, de maintenir un code propre et de le corriger en permanence de façon à ce qu’il soit meilleur que lorsqu’on l’a reçu.

Pour cela, il faut respecter plusieurs règles de base, comme utiliser des noms explicites (il doit être possible de comprendre l’objet d’une variable ou d’une fonction par exemple en lisant son nom, sans avoir besoin de commentaires supplémentaires), utiliser les commentaires à bon escient (intentions, avertissements, reste à faire…) et éviter les commentaires inutiles (redondance, notes obsolètes et/ou non publiques…). Les fonctions doivent être simples, ne faire qu’une seule et unique chose et utiliser le moins de paramètres possibles. Les objets doivent masquer les données et rendre leurs méthodes accessibles. Il doit être facile d’ajouter de nouveaux objets, mais en revanche, il doit être complexe d’ajouter de nouveaux comportements. La gestion des erreurs est extrêmement importante. Le code doit être propre et robuste, la gestion des erreurs séparée du reste de la logique de l’application et les exceptions doivent toujours renvoyer un code d’erreur. Les tests unitaires sont créés avant le code (TDD ou Test Driven Development) et chacun ne doit pas demander plus de quelques secondes d’exécution. De la même façon que le code, les tests devront être maintenus et rester propres. L’écriture des tests est aussi importante que l’écriture du code. Ils sont les garants de la non régression des développements.

La deuxième partie regroupe des études de cas, simples au début, puis de plus en plus complexes.

A chaque fois, une application est présentée avec son code source et un problème. L’objectif est d’analyser le code de façon à le nettoyer, à déterminer ce qui ne va pas, ce qui pourrait être optimisé ou corrigé et qui va devoir être transformé. A la fin de chaque étude de cas, on doit obtenir un code propre et sain.

La troisième et dernière partie quant à elle est constituée d’aides mémoires et de conseils glanés parmi les études de cas vues précédemment. Elle constitue à elle seule une base de connaissances utilisable aussi bien pour l’écriture de la première version d’un code source que pour le nettoyage d’un code existant.

Pour conclure sur Clean Code

« Clean Code » fait le point sur les bonnes pratiques de développement permettant d’aboutir à un code source de qualité, clair, bien construit et organisé, testé et par conséquent maintenable et évolutif. Le livre donne au lecteur les clés pour produire du code propre et pour nettoyer du code de moindre qualité.

« Clean Code » s’adresse tout naturellement aux développeurs, mais également aux ingénieurs, analystes et concepteurs logiciels, aux chefs de projet, et à tous les agilistes.