Je ne vous vendrai pas de formation "Clean Code"

Titre volontiers provocateur, mais on ne peut plus sérieux. Pourquoi ? Parce que se former au Clean Code en 2 ou 3 jours, c'est comme lire un dictionnaire ou l'API de NodeJS de A à Z : personne ne fait ça, parce que ça n'a pas de sens.

Comprenez-moi bien : le Clean Code est une excellente chose. J'aime le clean code, je pense clean code, je vis clean code, j'en suis le fervent défenseur. Et pourtant.

Le Clean Code ? En quelques mots, à titre de rappel, disons que le clean code est un ensemble de bonnes pratiques largement acceptées pour écrire du code de bonne qualité, c'est-à-dire compréhensible par des humains (condition nécessaire pour le faire évoluer). Ce sont des considérations relatives au nommage, à la taille des fonctions et, plus profondément, à la 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 par le menu 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, on se l'approprie 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."

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 ensemble très 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. Pour celles et ceux qui pratiquent plus volontiers la programmation fonctionnelle, c'est important.

Tout cela pour dire que ces sujets, essentiels pour tout développeur digne de ce nom, se prêtent mal au format contraint et obligé des 2 ou 3 jours de formation. Mon offre, structurée en 5 temps, ne compte donc pas de formation "Clean Code". J'aborde plus volontiers ce sujet lorsque j'accompagne des entreprises à moyen ou long terme dans le cadre du coaching technique. 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 ne vous vendrai donc pas de formation au Clean Code, mais nous en parlerons beaucoup si nous travaillons ensemble 😊