Rappel de produit : formation "Clean Code"

Attention : vous risquez l'intoxication 🤮

C'est comme lire le bottin ou l'API de NodeJS de A à Z : personne ne fait ça. Alors pourquoi vous infliger une formation au clean code ?

Comprenez-moi bien : le Clean Code est une excellente chose, j'en suis un fervent avocat. Le Clean Code ? Un ensemble de considérations largement acceptées visant à écrire du code de meilleure qualité, c'est-à-dire compréhensible par des humains et, de ce fait, censément facile à faire évoluer. Ce sont beaucoup des sujets de nommage, de taille des fonctions et, plus profondément, de responsabilité de ces dernières. On en revient encore, toujours, tout le temps, au Single Responsibility Principle, principe structurant s'il en est.

Seulement, de l'aveu-même de Robert C. Martin, Clean Code est un peu un livre de recettes : en faire une lecture linéaire n'aurait aucun sens. On peut feuilleter le livre, admirer les images, se rêver pâtissier, mais on ne va pas essayer toutes les recettes en 2 jours. On en fait une, on ajuste, on ré-ajuste et au bout de 4 ou 5 fois on fait les yeux fermés une recette qui n'est plus exactement celle du livre.

La preuve : "je t'ai déjà fait goûter mon tiramisu ?"

Ça s'appelle l'expérience, et à mon sens, il n'y a que comme ça qu'on apprend. À mon sens et celui d'Albert Einstein, jamais avare d'une citation qui claque et remet tout le monde d'accord :

"La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information."

Bam.

C'est un sujet que j'avais développé dans l'un de mes premiers articles, intitulé Le coaching, SAV de la formation, dans lequel je citais déjà notre physicien bien aimé. Comme quoi, je m'auto-cite et je radote un peu.

Est-ce à dire que la formation n'a pas de sens ?

Bien sûr que non. Simplement, autant la programmation fonctionnelle ou le Domain-driven design se présentent comme un enchaînement logique d'idées formant un tout cohérent, autant le Clean Code reste une juxtaposition d'idées assez disparates : principes SOLID, Object Calisthenics, KISS, YAGNI, design patterns, smells (a)variés et j'en passe.

Notons de surcroît que ce savoir a été formalisé par des développeurs travaillant essentiellement dans un paradigme objet. Certaines considérations sont directement applicables dans le monde fonctionnel (responsabilité unique, ségrégation des interfaces, inversion de dépendance), d'autres demandent adaptation (principe de substitution de Liskov), quand les dernières ne sont tout simplement pas applicables (open/closed principle). Ainsi, le Clean Code tel qu'il est souvent présenté reste fortement coloré de programmation orientée objet.

Tout cela pour dire que j'aborde plus volontiers ces sujets dans le cadre du coaching technique, c'est-à-dire d'un accompagnement de moyen ou long terme. Cela permet d'introduire chaque notion au moment précis où la personne en face de moi est confrontée au problème… et va généralement avoir elle-même l'intuition de la solution.

Je viens de vous faire économiser 2 200 € HT. Ne me remerciez pas.