Suis-je un développeur obsédé par le code ?

Au cours de mes diverses expériences en tant que développeur, j’ai eu l’occasion de rencontrer de nombreuses personnes ayant chacune une approche différente du métier. J’en suis d’ailleurs arrivé à la conclusion suivante : certains développeurs et Craftsman sont focalisés sur leur code, et ce, au détriment du plus important, répondre aux besoins de leurs clients.
Ces “Craftsman” du développement ne se posent pas forcément cette question : « Suis-je un développeur obsédé par le code ?». Mais avant d’aller plus loin, comment définir ce qu’est un Soft Cratfsmanship ?
Qu’est-ce qu’un Software Craftsmanship ?
Si l’on se réfère à une traduction simple, un Craftsman est avant tout un artisan, une personne qui exerce un art. Cela exige de la méthodologie, des qualifications mais aussi de l’expérience. A ceci je rajouterais qu’il faut de l’amour et de la passion pour son métier.
Voici une autre définition qui me tient à cœur :
“L’artisan est plus heureux que le riche désoccupé, parce qu’il est soumis à un travail impérieux.” Chateaubriand, Génie du Christianisme,t. 2,1803, p. 387
Cependant, aucune de ces deux définitions n’ont mis l’accent sur les outils utilisés, et ne mentionnent que les procédés, est-ce un hasard ? Eh bien non, c’est donc la méthode qui doit primer sur les outils pour un bon artisan. Vous voyez sans doute où je veux en venir ?
Certains professionnels du développement ont tendance à se reposer sur leurs panoplies technologiques ou de langages de programmation et ils en oublient les fondements méthodologiques liés au développement informatique.
Les technologies sont éphémères, le code n’est pas éternel. Ce parfait framework que vous avez utilisé hier peut se retrouver dépassé et obsolète aujourd’hui. Comment donc identifier si vous faites partie de ces développeurs obsédés par le code et comment y remédier ?
Un exemple d’obsession pour le code
Quoi de mieux qu’un exemple pour illustrer cette problématique. Tout a commencé avec un débat que j’ai eu avec des collègues. « Dans une grille de données, dois-je charger les détails au démarrage ou au clic » ?
Certains préféreraient récupérer toute la hiérarchie de la donnée au début pour garder un œil sur le modèle chargé, leur petit bébé. Ils ont passé deux jours, voir plus, à le confectionner. Tout était parfait, tout était générique : une vraie boîte noire ! Pourquoi ?
Le code est générique et il n’y a que le développeur qui en est à l’origine qui le connaît et sait comment il a été produit. Quand aux autres développeurs, ils n’ont qu’à faire appel à ces fonctionnalités sans savoir comment cela fonctionne exactement.
Il ne faut pas chercher à comprendre, l’essentiel c’est que cela fonctionne à merveille tant que cela ne nécessite pas d’optimisation pour charger les données plus rapidement. Et c’est là que l’on commence à fouiller dans le code…
Ces personnes changeront complètement d’attitude pour vous convaincre de la perfection de leur code. Plus vous persistez, plus ils résisteront et s’éloigneront de l’évidence. Même si le code produit est “overdesigné“, ils feront tout pour le conserver.
Code First ou Pattern First ?
La question posée ici est simple en apparence mais fondamentalement complexe : Est-ce qu’il faut faire du code first ou du pattern first ?
Est-ce qu’il faut coder de façon générique, penser réutilisable et modulaire de prime abord ? Ou bien coder uniquement en fonction de ce que le système nécessite et en refactorisant ensuite ?
Cette réflexion me rappelle d’ailleurs l’article de mon collègue Walid : « BUILDERS CONTRE CHALLENGERS, UN MATCH DIFFICILE », que je vous invite à lire.
Certains Craftsman ne prendront pas le temps de se poser cette question car pour eux il n’y a pas de problème : tout est générique. Cette réponse directe est l’un des symptômes de cette obsession.
Ces développeurs deviendront alors des compétiteurs : qui sortira le code de référence le premier ? Qui aura son modèle de données CLEAN ? Sur quel code ferions-nous du copier-coller ? Est-ce que c’est le sien ? Qui fera parler de lui dans les Daily meetings ou dans les cercles de discussion ?
C’est à ce moment-là que le fait de coder parfaitement dès le début devient une obsession… voir même une certaine forme d’orgueil !
Ne soyez pas égoïste
Certes, en ayant recours à ces pratiques, certains Artisans du code pourront délivrer de la valeur à l’utilisateur. Mais à quel prix ?
Le code est-il lisible ? Est-il compréhensible ? Est-il maintenable ? Est-ce que tout est implicite dans le code ? Est-ce que leurs collègues ont l’expérience et la patience pour le déchiffrer ?
Ils oublieront tout ça, dès qu’ils auront un clavier sous les mains ! Leurs obsessions pour le code est si importante qu’ils ne se soucient guère de ces interrogations. Il m’arrive de penser qu’ils le font exprès, après tout, on le dit parfois de manière ironique : pourquoi faire simple quand on peut faire compliqué ? 😉
Il n’y a qu’une seule voie pour atteindre cette force, adopter les principes d’un clean code, ici je ne vous apprends rien : YAGNI, KISS, DRY, etc.
Tout dépend du contexte de développement
C’est vrai que le but d’un Craftsman est avant tout d’être en mesure de « Délivrer de la valeur à ses clients ». Et d’ailleurs, c’est la raison pour laquelle nous développons.
Mais quelle est la meilleure approche pour atteindre ce but : Code First ou Pattern First ?
Il n’y a pas de réponse simple, tout dépend de votre contexte. Vous pourrez le définir si vous arriviez à qualifier ces points :
- votre connaissance par rapport au domaine
- votre maîtrise des technologies et votre aptitude technique
- votre maturité et celle de l’équipe.
De manière générale, ce sont vos aptitudes de modélisation et vos expériences qui détermineront vos orientations (Pattern ou code).
L’image ci-dessous vous montre comment votre vision et votre contexte peuvent influencer votre décision, c.q.f.d.
Perpspective taking –
La triforce d’un Craftsman
Quelque soit votre contexte, il vous faudra adopter la triforce d’un Craftsman pour remédier à cette obsession :
- la connaissance
- la conscience
- le cœur
Gardez le focus sur cette triforce, parlez-en à vos collègues, recherchez la simplicité et soyez humble. C’est ainsi que regarderez votre code d’un œil plus critique.
Conclusion
Rappelez-vous d’une chose, même si vous êtes obsédé par le code (ou que vous ne voulez pas l’avouer 😀 ), coder proprement avec le minimum de WTF est possible et surtout, livrez de la valeur pour vos clients.

Clean Code – Martin Fowler
Votre amour pour ce travail : c’est ce qui fait de vous un Craftsman accompli !
Merci pour cet article intéressant, votre avis était très important concernant ce sujet.
Je vous en prie ! Merci pour votre commentaire
Je crois qu’un artisan passionné, jusqu’à l’obsession, par son métier, aurait tout fait pour le rendre parfait en appliquant toutes les normes possible, notamment Cleand code, SOLID et autres principes.
Je confirme qu’un artisan passionné essayera de rendre son code parfait.
Mais c’est quoi la définition d’un code parfait ? Personnellement, je pense que le mot parfait reste subjectif.
Entre autre, un code parfait peut être aussi, selon d’autres artisans, un code maintenable, lisible et testable.
Les normes et les principes sont des moyens mis à disposition pour que chaque développeur puisse atteindre ses objectifs (maintenable, lisible et testable).
Article très intéressant car pas beaucoup de personnes parlent de ce type de problème chez les codeurs. Mais comme toutes les personnes dans toutes les activités, il y en a de toutes les couleurs. Ce n’est pas exact le stéréotype du développeur geek, renfermé et tout. Il y a des codeurs tatoués, qui aiment toutes sortes de musiques, qui fument, qui aiment rigoler, bref des gens normaux.
Certes qu’ils existent des développeurs de toutes les couleurs mais certains n’ont pas un œil critique sur le propre code