Ouarzy's Blog

Je ne pouvais évidemment pas parler de livre technique sans parler de Clean Code que j’ai déjà eu l’occasion de citer dans plusieurs de mes articles. C'est écrit par le mythique Bob Martin qu'on ne présente plus. Il m’a été conseillé par Fabien Maury lors d’un des nombreux échanges techniques que nous avons. Et je dois dire que je n’ai pas été déçu.

Pour l’heure, c’est tout simplement le meilleur livre technique que j’ai eu l’occasion de lire. C’est un ouvrage qui vous donne le bilan de dizaine d’années d’expérience, en éliminant le superflu. Et en informatique, rien ne remplace l’expérience.

Ça part de grande phrase très généraliste et qui font tout à fait consensus comme:
“L’attention portée aux détails est aujourd’hui une preuve de professionnalisme plus que n’importe quelle autre grande vision. Premièrement, c’est par leur participation aux petits projets que les professionnels acquièrent la compétence et la confiance nécessaires aux grands projets. Deuxièmement, les petits riens d’une construction négligée, comme une porte qui ferme mal ou un carreau légèrement ébréché, voire le bureau désordonné, annulent totalement le charme de l’ensemble. C’est toute l’idée du code propre.”

Mais tout l’intérêt du livre est justement qu’il va ensuite plonger pour mieux expliquer ce qu’il considère être “un détail important”, et comment le traiter pour qu’il ne soit plus négligé.

On retiendra notamment l’importance du nommage dans le code, ce qui permet d’utiliser un minimum de commentaires (les meilleur commentaires, c’est le code). L’oncle Bob décrit très bien les quelques cas où un commentaire est pertinent, mais surtout les nombreux cas où ça ne l’est pas. Tout se résume dans cet extrait: “Ne pas compenser le mauvais code par des commentaires”. J’en ai d'ailleurs déjà parlé dans mon dernier article.

Bob consacre également un chapitre complet aux tests unitaires, où il commence par citer les 3 lois du TDD:
“Première loi. Vous ne devez pas écrire un code de production tant que vous n’avez pas écrit un test unitaire d’échec.
Deuxième loi. Vous devez uniquement écrire le test unitaire suffisant pour échouer ; l’impossibilité de compiler est un échec.
Troisième loi. Vous devez uniquement écrire le code de production suffisant pour réussir le test d’échec courant.”

Cela est très important de mon point de vue, car ça montre que, contrairement à ce que certains développeurs croient, on ne peut pas parler de code de qualité et de bonne pratiques sans parler de TU. J’irai même plus loin: on ne peut pas considérer qu’un logiciel soit professionnel si il est développé sans aucun test unitaire (mais je là m’égare, revenons à nos moutons).

Le livre traite également entre autre de la mise en forme, de la POO, de la gestion des erreurs, des limites et de la gestion de la concurrence...Bref, c’est un livre extrêmement complet sur les bonnes pratiques de développement en général. Il y’a un appendice sur les “indicateurs et heuristiques” très bien fait qui permet très concrètement de détecter du mauvais code.

Franchement, c’est un livre dont la lecture devrait être obligatoire après un an de pratique. Oui je dis bien après un an, car je pense que les notions abordées sont presque trop concrètes pour qu’elles puissent vraiment parler à un étudiant.

Ca rejoint d’ailleurs l’idée selon laquelle rien ne remplace l’expérience en informatique.
Avec un peu de recul et de pratique, on va s'exclamer tous les 3 paragraphes “ah mais oui! C’était exactement ça mon problème!”, et on sera capable de rajouter une couche de bonnes pratiques sur les habitudes qu’on commençait à prendre.

L’oncle Bob insiste également sur le côté artistique du développement (recherche de la perfection). Et c’est quelque chose avec lequel je suis tout à fait d’accord: je pense que les capacités d’abstraction, d’adaptation et de compréhension nécessaire à l’écriture d’un code de qualité sont aussi utile dans le milieu artistique que dans le développement.

En bref, un must read.