Témoignage : ma découverte du Craft

Le Craft (Software Craftsmanship) est relativement connu au sein des développeurs et pourtant assez peu pratiqué. Ainsi, la communauté Craft de SOAT ne représente qu’un petit pourcentage des Soatiens.

Loin de moi l’idée de vouloir convaincre tout le monde de l’intérêt du Craft. Cela ne convient pas à tous les développeurs. Probablement une question de personnalité. Par contre, je pense aussi qu’il faut avoir le déclic. Par ce témoignage sur ma découverte du Craft, j’espère toucher quelques personnes et leur donner envie de rejoindre la communauté Craft, d’autant que cela n’engage à rien.

Un meilleur professionnel

Ma découverte du Craft est plutôt récente relativement à ma « carrière » : 5 ans versus 20 ans. Ceux qui me connaissaient avant auraient pu penser que j’étais Craft dans le sens de « l’amour du travail bien fait ».

En effet, j’ai toujours aimé réaliser des interfaces graphiques soignées et user-friendly, écrire un code « propre, beau, élégant ». D’anciens collègues me l’ont confirmé en m’indiquant qu’ils appréciaient le code et les IHM que j’avais faits sur lesquels ils repassaient. Bref, un bon professionnel 😎 !

Sauf que, à l’époque, je faisais peu de veille technique. Dans les équipes où j’étais, nous ne faisions pas de revue de code et nous n’échangions pas sur des sujets tels que la qualité. Ainsi, je ne me rendais pas compte des inconvénients de certaines des pratiques que je considérais comme bonnes :

1. J’aimais écrire du code comme on écrit une librairie partagée, en pensant à plein de cas de figure, même non utilisés dans le reste de la codebase.
2. Je m’appliquais à rédiger de longs commentaires dans le code pour l’expliquer en détail, comme s’il s’agissait de la documentation d’une API publique.
3. Je ne connaissais pas les tests automatisés : tests unitaires (TU), tests d’acceptation (TA)… Pourtant, j’aurais pu déjà en écrire, a minima depuis que je suis à SOAT (octobre 2009) où je fais du .NET et pour lequel tous les outils adéquats étaient déjà disponibles (frameworks MsTest/NUnit, runners intégrés à Visual Studio), sans oublier mon initiation au TDD à SOAT.

Voyez-vous les problèmes de maintenance que ces pratiques posent ?

1. YAGNI ! Tout ce dont on n’a pas besoin à l’instant t, mieux vaut s’en passer.
   

   💡 À la limite, on peut se laisser des portes ouvertes, des extensions dans le code, dans l’esprit de l’Open-Closed Principle, mais plutôt lorsque cela correspond à des évolutions fonctionnelles qui sont prévues ou prévisibles et que l’agenda le permet. Cela aura tendance à coûter moins cher ainsi.

2. Comme l’indique Oncle Bob dans son livre Clean Code, les commentaires sont un cadeau empoisonné : il faut les maintenir ! Or, de manière générale, rien – ni compilateur, ni autres outils de build – n’oblige à maintenir les commentaires, qui finissent par diverger du code et devenir mensongers.
   

   💡 Pour expliquer du code, rien de tel qu’un bon nommage et des tests automatisés.

3. Les “bons” tests – ceux respectant F.I.R.S.T et qui ne sont pas fragiles (car découplés du code de production) – sont un vrai cadeau pour soi, ses collègues et même ses utilisateurs :
   • Au moment de coder la fonctionnalité, pour garantir le bon fonctionnement, ils permettent de s’épargner de fastidieux et répétitifs tests manuels dont l’intérêt s’évapore à la moindre modification dans le code !
   • Plus tard, pour mieux comprendre le fonctionnement, les tests participent à la documentation, celle-ci étant in situ donc facilement localisable et by design toujours à jour (relativement au code couvert par ces tests).
   • Les tests peuvent prévenir des régressions. C’est un filet de sécurité, autorisant les refactos pour améliorer le code à iso-fonctionnalités, en particulier pour incarner dans la modélisation une meilleure compréhension du problème métier, acquise avec le temps.

Voici un échantillon des principes que l’on apprend quand on commence à s’intéresser au Craft, par sa littérature ou lors de formations ou de simples échanges avec des crafters. Depuis que je les ai intégrés à ma pratique au quotidien, je porte mon attention sur des éléments qui sont généralement plus bénéfiques à la qualité du code. Bref, un meilleur professionnel 😎 !

☝ En même temps, cela n’a rien d’étonnant : le Craft, comme ses confrères de l’agilité et du DevOps, sont les produits de l’expérience de talentueux développeurs, soucieux d’améliorer leur industrie.

Si je souhaitais mettre en avant ces quelques points fondamentaux pour ma pratique, le Craft recèle bien d’autres aspects qui peuvent s’avérer de grande valeur pour améliorer les pratiques de chaque développeur. Ses bénéfices ne se limitent pas à la sphère purement technique et peuvent se manifester à un niveau plus personnel, ce qui a été le cas pour moi. Afin de l’illustrer, voyons les circonstances qui m’ont amené au Craft.

Comment je suis venu au Craft

En mission

Lors de ma mission à la MAF, j’ai eu la chance que notre équipe soit coachée pour améliorer son agilité. Il s’est avéré que notre coach était un crafter accompli : Romeu Moura.

Le coaching s’est très bien passé avec l’équipe : avec l’éclairage de Romeu, nous avons pris conscience de l’origine de certains de nos problèmes. Il nous a aidés à améliorer nos process et notre niveau technique. Sans entrer dans trop de détails, potentiellement non pertinents pour vous, voici cependant quelques éléments qui ont été particulièrement significatifs pour moi.

Tout d’abord à titre personnel, j’ai compris que l’on pouvait choisir sa “Developer Experience” : il y a des façons de travailler qui sont stressantes, d’autres qui sont plus confortables et donc plus productives. Ainsi, j’avais tendance à être dans le premier cas en travaillant sur plusieurs aspects en même temps et en améliorant du code un peu “moche” sur lequel je tombais (parfois des nues 😆). Résultat : une grosse quantité de travail en cours mais aucun travail fini ou a minima testable.

Exposant ce problème dans une session de coaching, Romeu nous a conseillés d’essayer la technique Pomodoro et surtout d’appliquer le Make it work, Make it right, Make it fast.

💡 Détails

Cette expression invite à ne pas tout faire en même temps, mais plutôt de manière séquentielle et ordonnée.

1) Make it work : faire en sorte que le développement en cours fonctionne, si possible avec des incréments les plus petits possibles, en baby steps.
2) Make it right : améliorer le code pour arriver à un niveau de qualité acceptable par l’équipe.
3) Make it fast : adresser les éventuels problèmes de performance réellement constatés.

Le tout est accompagné de commits fréquents dans git pour valider chaque micro-incrément. La pratique du TDD incarne d’ailleurs parfaitement cette philosophie, tout en apportant d’autres avantages sur la testabilité et le design du code.

J’ai mis du temps à appliquer ce Make it work [first]… Il m’arrive même encore de « m’emballer » mais globalement je constate en effet une façon plus confortable de travailler.

Ensuite, au niveau de l’équipe, nous avons trouvé un véritable esprit d’équipe : nous n’étions plus un ensemble d’individualités. Confiance, dialogue, entraide et synergie se sont installés entre nous. Même si cela n’a pas empêché certaines discussions animées mais constructives, c’était beaucoup plus agréable à vivre. Je n’aurais pas imaginé que le coaching serve de Team building 😁

Il est également intéressant de noter que les membres de l’équipe ne sont pour autant pas tous devenus crafters. Chaque membre s’est investi différemment dans le coaching et dans le Craft en général. Certains ont plus creusé les sujets, en participant aux BBL proposés par Romeu ou par d’autres personnes de la DSI, en lisant des ouvrages, ou en pratiquant des katas de code. Pour autant, les résultats ont été au rendez-vous pour nous 🎉

CHEZ SOAT

De manière concomitante, j’ai pu compter sur la mise en place récente de communautés de Soatiens. De manière amusante, c’est par le truchement de Romeu que je m’y suis intéressé : m’indiquant que son meilleur ami, Xavier Detant, également crafter émérite, était en train de monter la communauté Craft chez Soat, Romeu m’a invité à y participer.

À l’époque, par timidité et un peu par paresse, je m’impliquais peu chez SOAT. C’était l’occasion de sortir de ma zone de confort. J’ai donc participé à une soirée Craft lors de laquelle nous avons opté pour la pratique d’un kata en TDD. C’était fun et instructif. Xavier a conclu la soirée par un live coding bluffant : tout en expliquant ce qu’il faisait, Xavier manipulait le code pour faire émerger des similitudes et en déduire l’algorithme général, matérialisant implicitement les Transformation Priority Premise en direct 👍

Par la suite, j’ai rencontré d’autres membres de la communauté, Michelle, Sepehr puis Dorian. Ensemble, nous avons monté les masterclasses Craft : l’occasion pour moi de partager des éléments appris lors du coaching, de les creuser et d’en voir de nouveaux. Progressivement (d’abord en shadow), je me suis retrouvé devant 10-15 Soatiens à parler de Clean Code. La confiance et l’ouverture dans la communauté ainsi que l’émulation collective ont eu raison de mon trac 😅

Dans la communauté Craft

Petit à petit, ma zone de confort s’est agrandie. J’ai également participé à des meetups en dehors de SOAT, en particulier à ceux de Software Crafters Paris où il s’agit de venir écouter et d’échanger sur le Craft. C’est difficile d’expliquer ce qu’apporte ce type d’échanges, sur le plan pratique comme sur le côté humain. Il faut le vivre pour comprendre.

Poussé encore plus loin, cela donne les SoCraTes, plusieurs jours de « non-conférence ». On se retrouve entre crafters de tous niveaux pour échanger sur tout. Chacun peut proposer un sujet, technique ou non, sujet qu’il souhaite présenter ou pour lequel il a besoin d’aide. J’y ai trouvé un climat bienveillant, pas de stars malgré des compétences élevées, à tel point qu’un participant nous a partagé, au bord des larmes (car vivant une période compliquée personnellement), à quel point cela lui a fait du bien de participer.

Conclusion

Le Craft m’a permis d’apprendre des manières efficaces d’être un meilleur professionnel tout en travaillant plus sereinement. C’est un long chemin et comme tout voyage c’est à la fois une expérience personnelle et collective, une succession de belles rencontres, avec Romeu, mon équipe à la MAF, la communauté Craft de SOAT – Michelle, Sepehr, Dorian, Thibaut… – et de tout horizon.

Plusieurs concours de circonstances sont à l’origine de tout cela. Moi qui suis peu aventureux, j’ai réussi à saisir ces occasions et j’en suis heureux aujourd’hui. J’espère que ce témoignage saura apporter un éclairage nouveau sur le Craft, toucher quelques personnes et pourquoi pas produire un déclic ✨