Quand avez-vous pris le temps de vous plonger dans un bon livre sur notre métier pour la dernière fois ?
Même si la lecture d’articles de blogs ou de vidéo permettent de faire de la veille technique rapide et pratique, se plonger dans un livre permet d’avoir une compréhension plus profonde et structurée sur certains sujets.
Bienvenue dans le « Club de Lecture JetDev », une série dans laquelle je vous présente les bouquins qui, selon moi, sont importants pour tout dev qui veut se construire une base solide de connaissances et compétences.
Introduction
Alors, pourquoi ai-je choisi The Clean Coder pour lancer cette série ?
À ne pas confondre avec le célèbre « Clean Code » du même auteur ( pour lequel j’émets parfois quelque réserves), ce livre n’est pas juste un condensé de bonnes pratiques.
Au travers de conseils pratiques, il définit le professionnalisme en tant que développeur. Bien souvent dans notre industrie, le focus est posé presque exclusivement, sur les compétences techniques.
Mais être un bon développeur, c’est aussi savoir apprendre de ses erreurs
C’est aussi apprendre à gérer son temps et la pression.
Ou encore, savoir communiquer efficacement.
Du jeune padawan au maître Jedi, ce livre est un guide à suivre à chaque étape professionnelle. C’est pour ça que j’ai choisi ce livre. Il m’a aidé dans bien des aspects de mon métier. Par exemple, il m’a permis de corriger ma mauvaise habitude de toujours répondre « je vais essayer » quand on me demandait de réaliser une tâche impossible dans les délais impartis.
Robert C. Martin alias Uncle Bob
Robert C. Martin, surnommé Uncle Bob est un auteur américain, véritable légende dans le monde du développement. Il est connu pour avoir été l’un des co-auteurs du (manifeste agile). Il est aussi à l’origine des principes (SOLID), considérés parmi les meilleures pratiques de Programmation orientée objet,
Il est connu, entre autres, pour ses œuvres comptant les célèbres « Clean Code », « Agile Software Development, Principles, Patterns, and Practices », et bien d’autres.
Uncle Bob utilise un langage accessible à tous, il utilise de nombreux exemples concrets au travers de cas réels, en utilisant sa propre experience. J’apprécie énormément sont coté direct et sans détours.
Petit disclaimer tout de même, c’est un auteur qui a des opinions fortes qui font parfois débat dans la communauté.
Le professionnalisme
Dans Clean Coder,Uncle Bob redéfinit ce qu’est un vrai professionnel. Ce n’est pas juste prendre son job au sérieux, c’est avoir une attitude où l’on prend ses responsabilités et où l’on ne fait pas de compromis sur la qualité du travail.
Après une journée de travail, nous sommes fiers de ce que nous avons produit.
Pas de compromis sur la qualité : si ce que l’on a produit n’est pas de qualité, on ne le livre pas, aucune deadline, aucun manager ne peut nous forcer à le faire. Il ne s’agit pas d’être inflexible, mais de trouver le bon équilibre entre la qualité et le maintien des deadlines.
Il faut connaitre le domaine
L’auteur nous dit qu’il est essentiel de connaître le domaine pour lequel on travaille, il ne faut pas être un expert en mode pour travailler dans la vente de prêt-à-porter, mais coder sur une spec sans comprendre ce qu’elle représente pour le business ne permet pas de reconnaitre et challenger d’éventuelles erreurs de spécification.
Vous êtes le seul responsable de votre carrière
Être un professionnel, c’est une attitude qui continue en dehors du travail, notre carrière doit être notre responsabilité et non celle de notre employeur. Il ne tient qu’à nous de continuer à apprendre (Toujours en s’amusant), de pratiquer pour garder nos compétences à jours et pratiquer souvent. La collaboration avec d’autres personnes et le mentorat sont aussi d’excellents outils pour apprendre.
Le travail fourni doit être exemplaire
Le code que nous produisons doit être irréprochable, les experts QA ne doivent rien trouver, les utilisateurs encore moins ! Est-ce vraiment possible ? Oui et non, il est de notre responsabilité de savoir que notre code fonctionne, et pour se faire rien de mieux que les tests.
D’après l’auteur, il faut TOUT tester (Objectif 100% coverage, même si l’on sait qu’en réalité, c’est inatteignable) et le plus possible de manière automatisée.
Il va d’ailleurs nous proposer 3 chapitres sur le sujet.
Test Driven Development
L’art de piloter les développements par les tests, régis par 3 lois :
- Tu dois écrire un test qui échoue avant d’écrire tout code de production
- Tu ne dois pas écrire plus d’un test qui échoue, ou qui échouera à la compilation
- Tu ne dois pas écrire plus de code que nécessaire pour faire passer le test en cours
L’on profite également d’avoir directement les tests sur ce que l’on code pour refactorer celui-ci en toute sérénité. Le TDD mériterait un article à lui tout seul (peut être bientôt sur le blog JetDev !)
Acceptance Testing
Avoir des tests d’acceptation automatisés écris entre les parties prenantes et les développeurs, c’est l’objectif. Du fait qu’ils sont automatisés, on peut les jouer souvent et à moindre coût.
Et le fait qu’ils sont écrit avec les parties prenantes, permet de lever les dernières ambiguïtés d’une fonctionnalité.
Testing Strategies
On prend ici un peu de recul sur les deux premiers points et en se basant sur la pyramide des tests automatisés. L’auteur nous présente les différents types de tests pour attendre le fameux objectif : « L’équipe QA ne doit rien trouver ».
Le code doit rester propre
En plus de ne pas dégrader la fonctionnalité, Uncle Bob met un point d’honneur à ne pas impacter négativement la structure du code « Faire un compromis sur la structure, c’est faire un compromis sur le futur », il faut tout faire pour que notre code reste flexible, constamment le retravailler (et comme tout est testé, on est « sûr » de ne rien casser !).
La règle du boy scout : Laissez le code dans un meilleur état que celui dans lequel vous l’avez trouvé.
Savoir dire non
Il est courant de nos jours d’employer les méthodologies agiles, l’exercice d’estimation des tâches et la négociation avec les parties prenantes est fréquente. Il arrive que ces dernières exercent une pression pour inclure un maximum de tâches dans un sprint, une pratique qui peut mener à des dérives.
L’auteur nous encourage à toujours être honnête et prendre des engagements réalistes, au lieu de juste dire oui à tout, il faut entrer dans une négociation.
Savoir quand et comment dire non, de manière appropriée et respectueuse, reflète un niveau de maturité professionnelle et personnelle, cela montre que nous sommes capable de comprendre les limites de notre travail.
Ça nous permet de créer un environnement où la confiance et la transparence sont valorisées, et où la qualité et le bien-être sont prioritaires.
Conclusion
L’ouvrage contient bien d’autres chapitres tous aussi intéressants les uns que les autres : Gestion de la pression, du temps, comment estimer ou encore bien collaborer.
Je vous invite très fortement à lire ce livre (qui de plus ne fait que 200 pages) au moins une fois, et d’en appliquer sérieusement les pratiques qui y sont enseignées.
Il n’y a pas de meilleur point de départ pour prendre en main sa carrière professionnelle, devenir non seulement de meilleurs développeurs, mais aussi de meilleurs collègues, mentors, et leaders dans notre domaine.
Alors que je ferme ce livre, je constate avec fierté, à quel point les valeurs qu’il prône se retrouvent dans mes valeurs personnelles, mais aussi dans celles de JetDev. J’espère continuer tout au long de ma carrière à encourager tout développeur à adopter l’attitude professionnelle telle que décrite dans ce livre.
Et pour vous, quels sont les points importants que tout développeur professionnel devrait suivre ?
Dans le prochain numéro du « Club de Lecture JetDev » , nous explorerons un autre ouvrage essentiel sur le développement logiciel moderne.
Restez à l’écoute !
