Clean Coder, Saint Crafter
Je récuse le terme de code “clean”, “propre”, qui mène insidieusement mais sûrement au développeurs/es “clean”, qui mène doucement à la mystique des vertus morales du Saint Crafter.
Celui qui sait parce qu’il a beaucoup appris, en sacrifiant de son temps libre à étudier et s’entraîner sur les bonnes pratiques.
Celui qui compense par son courage, son esprit toujours positif, son intégrité à toute épreuve, l’inefficacité désespérée de l’organisation dans laquelle il agit (contribuant du même coup à compenser cette inefficacité au lieu de la corriger).
Celui qui sait dicter les patterns et anti-patterns, et peut trancher dans toute situation sans même avoir besoin de
- lire le code
- faire connaissance avec le contexte
- comprendre l’origine et l’histoire du legacy qu’il a sous les yeux
Celui qui est prompt à commencer ses phrases par “Un vrai professionnel…” et à finir ses discours par “Vous n’avez pas d’excuse”.
Bref, j’aime pas le terme “clean code”.
Personne ne parle de “management propre” ou de “product owning propre”, après tout.
— Alors qu’est-ce que tu proposes pour désigner le clean code ?
Je ne propose rien pour désigner le clean code. Je suis conscient du fait qu’il existe un grand nombre de patterns, de pratiques, de procédés heuristiques, qu’on dispose de nombreuses source de documentation à leur propos, et que toutes ces idées circulent à travers ce que nous appelons “l’industrie” (faute d’un meilleur terme) et que la plupart d’entre elles sont éminemment vivantes, ajustables et surtout particulièrement susceptibles au contexte.
Vous est-il venu à l’esprit que “Clean Code” c’est d’abord une bannière sous laquelle un consultant célèbre a voulu rassembler les pratiques et modèles qui lut tenaient à cœur ? Si cet auteur n’avait pas travaillé en indépendant mais chez Assenture ou Bart & Old, tout le monde dirait :
…d’après les principes du Clean Code™
Beaucoup de développeurs/es, dans leur contexte, souhaitent réaliser du code qui serait à la fois correct, fiable, performant et facile à maintenir. Pour autant, il est difficile de trouver un terme générique qui résumerait ces qualités. Personnellement si je devais me fixer sur un terme qui rassemble — sans les trahir — toutes les idées que j’ai puisé dans la littérature, sur internet, dans mon travail, et en expérimentant avec mes pairs, je serais plongé dans le désarroi. Je peux vous lister une vingtaine de livres qui parlent de ce problème : écrire du code facile à maintenir. Aucun de livres ne démérite. Aucun de ces livres ne devrait être en dessous de la pile sous le prétexte qu’un livre appelé “Clean Code” aurait rassemblé, transcendé ou remplacé leur propos. Loin de là.
— Donc, plus de guide, on peut faire n’importe quoi ?
Je sais qu’on est sur un réseau social, et qu’au Royaume des Trolls les Manichéens sont rois, mais non ce n’est pas ce que je veux dire quand je récuse le terme “Clean Code”.
À suivre.
Merci Rudy de m’avoir suggéré l’écriture de ce post.