Dans “Clean Code”, Robert C. Martin nous décrivait les aspects techniques qui caractérisaient selon lui un bon développeur professionnel : un Software Craftsman. Dans “The Clean Coder”, il reprend le même principe mais en l’appliquant aux aspects humains et relationnels pour nous faire partager son guide de conduite d’un développeur professionnel.

J’ai apprécié ce livre car il pousse le concept de développeur professionnel encore plus loin en donnant quelques bonnes pratiques non pas dans les compétences techniques, mais dans son attitude vis-à-vis des autres membres de son environnement de travail (collègue développeur, manager, client, etc); ce qui est tout aussi important !
Ce livre devrait être étudié dans tous cursus de génie logiciel !

Contrairement à “Clean Code“ où d’autres grands noms du développement logiciel avaient prêté leur plume pour écrire quelques chapitres, “The Clean Coder“ est entièrement écrit par Robert C. Martin et ne reflète que son point de vue personnel, ce qu’il répète plusieurs fois tout au long du livre. Il faut donc appréhender cette lecture comme le résumé de son expérience professionnel et l’enseignement qu’il a su en tirer. Au lecteur de piocher ce qui l’intéresse pour s’approcher d’un idéal, en ayant conscience que tout n’est pas toujours atteignable à 100%.

J’ai personnellement repris beaucoup de ses pratiques (“Savoir dire non” notamment) mais j’en ai aussi laissé de côté car trop éloignées de notre philosophie européenne pour être applicables :) Ce livre m’a fait beaucoup évoluer dans mon attitude professionnel et vis-à-vis de mon travail, je le recommande vivement !

Si les premiers chapitres sont plutôt orientés réflexion sur soi, les suivants sont plutôt orientés réflexion vis-à-vis des autres.

Chapitre 1 : Professionnalisme
Être développeur professionnel, c’est être fier du travail que l’on réalise mais c’est aussi en assumer la responsabilité et les imperfections. Il met tout en œuvre pour que son code soit de la meilleure qualité possible et bannit le laisser-aller et les “je corrigerai plus tard”.
Le point le plus important de ce chapitre est certainement celui-ci : le développeur professionnel est maître de sa carrière, c’est à lui de se former et d’apprendre en continu, il ne doit pas attendre que son employeur le lui propose.
Enfin, on peut être fier de son travail (voir un peu arrogant ;) ) mais il faut aussi savoir rester humble quand des bugs sont découverts; le développeur professionnel assume et ne cherche pas des excuses ou boucs émissaires.

Chapitre 2 : Savoir dire non
Le travail en équipe amène naturellement des points durs, des confrontations d’opinions notamment avec la hiérarchie et son responsable. Le développeur professionnel connaît ses capacités et le rythme de travail qu’il peut supporter. Il estime les tâches en fonction de ces critères.
La pression de certains managers qui aiment “challenger” en demandant de revoir à la baisse l’estimation n’est pas un comportement responsable. En faisant cela, le manager estime que le développeur n’a pas été honnête avec lui et qu’il lui a donc caché une “réserve” de temps “au cas où”.
Le développeur professionnel doit savoir dire non à cela et rester ferme sur ses estimations qu’il a fait au plus juste. Il doit notamment bannir le “je vais essayer” qui ne peut rien apporter de bon : soit le développeur va travailler plus que de raison, ce qui peut amener au “burn-out” si cela est répété souvent, soit la qualité du code produit va être sacrifié, ce qui coûtera encore plus cher à l’application plus tard.
Enfin, le développeur professionnel ne doit pas faire d’agression passive. Lorsqu’il sent qu’un problème couve (un bug latent, une mauvaise conception qu’il faudra remettre totalement en cause quand il sera trop tard, etc), il doit faire tout ce qui est possible pour désamorcer la situation au plus vite en communicant et répétant les choses même face à l’incompréhension ou au refus de son responsable. L’attitude d’agression passive consiste à laisser courir lorsqu’un refus nous est opposé et à dire “je vous l’avais bien dit” lorsque le problème arrive, ceci est contraire au bon déroulement du projet.

Chapitre 3 : Savoir dire oui
Pour un développeur professionnel, dire oui c’est s’engager, ce n’est pas essayer !
On reconnaît les défauts d’engagement par des expressions du langage. Par exemple, les “on devrait faire”, “il faudrait faire”, “j’espère que ce sera fait” ne sont pas des marques d’engagement fort.

Chapitre 4 : Coder
Ce chapitre est consacré à l’écriture de code. Robert C. Martin nous donne ses bonnes habitudes et quelques conseils pour être efficace dans les tâches de programmation (éviter de coder à 3h du matin, prendre soin de son code, s’aérer l’esprit devant un blocage, etc).
C’est l’un des chapitres les plus personnels du livre, on est d’accord ou pas. Par exemple, je ne suis pas d’accord quand il dit que la “zone”, cette période d’hyperconcentration que l’on a de de temps en temps, n’est pas efficace et que ce n’est qu’une illusion.
Un point important est d’accorder du temps à l’entraide. Il faut savoir aider et surtout accepter d’être aidé.

Chapitre 5 : Test Driven Development
Robert C. Martin nous fait part de l’échange qu’il a eu avec Kent Beck qui lui a montré la philosophie du Test Driven Development. D’abord réticent, Robert devient un farouche partisan de cette méthode et ne jure plus que par celle-ci.

Chapitre 6 : L’entraînement
Comme tout professionnel (musicien, soldat, médecin), un développeur doit s’entraîner pour maîtriser certaines pratiques qu’il réalise quasiment tous les jours. C’est une bonne méthode pour devenir efficace.
Ici Robert nous parle d’entraînement donc, de Coding Dojo, de Kata, de Randori et de l’open source qui est un monde rigoureux pour prendre de bonnes habitudes.

Chapitre 7 : Tests d’acceptation
Comment favoriser la communication entre équipe de développement et représentant client, tout en mettant par écrit les engagements pris ? Une solution est d’utiliser les tests d’acceptation plutôt que des plans de tests volumineux et forcément imprécis.
Les tests d’acceptation écrits avant de développer (ATDD) permettent de fournir des cas reproductibles donc testables des besoins du client. Ainsi le travail est fini (“done”) quand tous les tests passent. Robert nous donne quelques conseils sur comment les écrire, qui les écrit et comment les dérouler. Il a une bonne expérience sur le sujet car il est le fondateur de Fitnesse, un outil d’ATDD.

Chapitre 8 : Stratégies de test
Petit chapitre consacré aux différents tests utilisés par le développeur professionnel : tests d’acceptation, tests d’intégration, tests de charge et de performance.

Chapitre 9 : Gestion du temps
Comment être le plus efficace possible pour réaliser le maximum de tâches dans une journée ?
Premier item abordé : les réunions. Les réunions sont essentielles mais elles prennent un temps considérable. La “réunionite” est un mal qui peut affecter certains services. Il ne faut pas avoir peur de refuser une réunion si on ne sent pas concerné. De même, il faut savoir quitter, poliment !, une réunion où on n’est pas utile.
Deuxième item, comment gérer sa capacité de concentration. La concentration n’est pas disponible indéfiniment dans une journée, il faut savoir réserver du temps pour l’utiliser efficacement.
Enfin, Robert décrit l’importance du “time boxing”, la nécessité absolue de borner les activités et surtout les réunions.

Chapitre 10 : Estimation
Qu’est qu’une estimation ? Une estimation n’est pas un engagement, ni une promesse. Se tromper dans une estimation n’est pas une faute incorrigible. Robert nous présente quelques astuces pour faire de bonnes estimations et notamment la méthode PERT basée sur des fourchettes et non sur une valeur unique.
Il nous présente aussi quelques techniques pour estimer des tâches comme le planning poker par exemple.

Chapitre 11 : Pression
Un développeur professionnel a plusieurs outils pour résister à la pression et garder son sang-froid en période de “rush”.
Le premier outil est de faire le maximum pour éviter la pression notamment en gardant tout le temps un code propre.
Quand la pression arrive, il faut garder son sang-froid et ne pas paniquer. Il faut garder les pratiques qui font leurs preuves et avec lesquelles on est confortable. Il faut aussi augmenter la communication et ne pas se renfermer dans sa bulle.

Chapitre 12 : Collaboration
Deux parties dans ce chapitre : le développeur face à son employeur et le développeur face aux autres développeurs.

Chapitre 13 : Équipes vs projets
Ce court chapitre est peut-être l’un des plus précieux de ce livre à mes yeux. Il met en lumière l’importance d’une équipe. Une équipe met du temps à se former, à adopter des automatismes, à devenir efficace, comme une équipe sportive !
Traditionnellement, on monte un projet et on choisit une équipe en conséquence. Ceci est nettement moins efficace que de monter une équipe et de lui attribuer des projets au fil du temps.
Lorsque l’on change d’équipe à chaque projet, tout le processus d’amorçage (qui n’est pas négligeable en temps et coût) est à refaire. De plus, toute les équipes ne fonctionnent pas, certains caractères sont incompatibles par exemple.
Lorsqu’une équipe est en route et fonctionne bien, un manager devrait tout faire pour garder cette équipe-là et lui attribuer des projets : tout le monde serait gagnant !

Chapitre 14 : Mentorat, Apprentissage et Artisanat
Dans ce chapitre, Robert met l’accent sur l’importance des mentors. Étant déçu par le niveau de certains jeunes diplômés soi-disant de grandes écoles, Robert décrit un système proche des compagnons chez nous où un mentor, un maître, enseigne ce qu’il sait à des apprentis.
Plus généralement, les développeurs professionnels (les Sotfware Craftsman) devrait se réunir en réseau, échangeant et apprenant les uns avec les autres. Ce réseau n’est pas très étoffé en France mais des association comme le LavaJUG, l’A-Cube et bien d’autres permettent de se retrouver entre confères de temps en temps !