En 2001, je faisais parti des premiers contributeurs à déclarer leurs impôts via Internet. A l’époque il y avait une prime de 20€ si tu utilisais ce moyen. Aujourd’hui c’est en train de devenir obligatoire un peu partout. Et ce sera bientôt sanctionné de ne pas le faire…
J’ai pensé à ça en améliorant le projet de bac à sable de refactoring. Par définition, c’est un projet ‘boule de boue’. Donc il n’y a pas de test, ni d’intégration continue. Normal pour une app legacy… Et quand je dis améliorer, je veux dire empirer les choses ! 😈
Du coup à la première pull-request, je vois un joli message de github me suggérant fortement d’intégrer un service d’intégration continue. 😍🤩
Là une petite larme me vient aux yeux et je constate alors avec satisfaction que ça y est ! L’intégration continue est entrée dans les mœurs. Ce n’est plus une pratique d’extra-terrestre, ni même une technique avancée. C’est devenu normal. C’est le fait de ne pas en avoir qui est devenu anormal.
Combien de temps faudra-t-il pour arriver à la même considération pour les autres pratiques comme le TDD (Test Driven Development) ?
J’étais hier à Agile Grenoble et lors de la session de Xavier Nopre sur le TDD, je constate avec plaisir que les gens convaincus par la nécessité d’écrire des tests automatiques sont maintenant majoritaires. Mais quand il s’agit de mettre en oeuvre, il n’y plus grand monde.
Cela donne une idée du curseur d’avancement dans les consciences et le chemin qui reste à parcourir pour diffuser les bonnes pratiques.
Car je peux maintenant l’affirmer sereinement : sans TDD, point d’agilité. Et c’est d’ailleurs tout le point de Xavier dans sa conf.
Sans TDD, je n’ai pas de tests efficaces.
Sans tests efficaces, je ne refactore pas mon code car il me fait peur.
Si j’ai peur de mon code, j’en perds la maîtrise.
Et sans maîtrise je ne peux pas accélérer.
Faire de l’agilité avec des cycles courts sans TDD, c’est comme rouler sur un circuit de formule 1 avec des pneus lisses. Ca finit forcément mal.
Le simple fait que tu sois en train de lire ce message est déjà encourageant. Nous ne sommes plus une secte bizarre de développeurs extrémistes. Notre art devient la norme. Et je ne peux que m’en réjouir car il est synonyme d’épanouïssement pour ses adeptes et de compétitivité pour leurs employeurs.
L’eXtreme Programming est de moins en moins eXtreme et devient le State-Of-Art Programming.
Encore faut-il savoir le faire. La bonne nouvelle c’est que ce ne sont pas les ressources qui manquent !
Rien que sur le podcast, tu trouveras ces épisodes qui parlent de comment l’adopter :
C’est aussi tout l’objet du cursus Artisan Développeur de la maison des compagnons : passer d’un code legacy à un code de compétition pour passer d’un quotidien ennuyeux et stressant à un quotidien épanouïssant. 😃
Heu, Benoît, en fait en F1 ils ont des pneus lisses « slick » (sauf le pneu pluie ^^)
https://www.pirelli.com/tyres/fr-fr/motorsport/homepage-f1
(pour ta défense, t’as parlé du circuit mais pas du véhicule …)
Hé ! hé ! Bien vu Nicolas. Justement…
C’est quand tu te prends pour une formule 1 que ça peut poser des soucis ! 😈
Hello,
J’ai compris et perçu l’intérêt des TDD lors d’une formation. En plus d’être un aspect déterminant pour l’agilité, c’est aussi un prérequis pour le Déploiement continu.