Salut,
Dans mes deux précédents articles, je t’ai raconté comment j’ai commencé ma carrière sur des chapeaux de roue avant de me rendre malade, asservi par le monstre spaghetti.
Puis je profitais d’un reset de projet pour changer radicalement ma manière de travailler.
Il m’a fallu passer par une phase douloureuse de remise en question.
Mais quelle récompense !
Non seulement cette nouvelle app a été distribuée à des dizaines de millions d’exemplaires mais surtout nous avions un niveau de qualité exemplaire !
L’app recevait très peu de bugs et le support était géré par deux personnes à temps partiel !
Mais le meilleur dans tout ça était l’incroyable plaisir que je retrouvais, démultiplié, à programmer.
J’allais vite.
Je me sentais léger.
J’avais confiance dans mes développement.
La clef pour déverrouiller mon code, je l’avais sous les yeux depuis plusieurs mois. Elle était dans le petit livre vert intitulé ‘eXtreme Programming’ qui trainait sur mon bureau.
Oh bien sûr, je l’avais lu quand il était arrivé. Mais je n’avais retenu que ce qui m’intéressait : c’était notre caution morale pour travailler à l’arrache.
Par contre j’avais mis de côté tout ce qui était contraignant.
Alors quand je décidais de m’y mettre sérieusement, j’ai tout lu et relu.
Des dizaines de fois pour certains passages.
Et j’ai appliqué le contenu du livre à la lettre, de manière très scolaire et disciplinée.
Etudier ce livre à fond m’a demandé de déconstruire des années de pratique et de faire une confiance aveugle à ses auteurs.
C’est ce livre qui m’a fait découvrir le développement piloté par les tests.
A force d’essayer, de lire et relire les pages du livre, d’expérimenter encore et encore, j’ai fini par avoir le déclic TDD.
J’y ai découvert aussi le binômage, l’intégration continue et toute les autres pratiques qui font la puissance de l’eXtreme Programming.
Mais le TDD a une place centrale : c’est le réacteur du processus.
Enlève ça et tout le reste tombe comme un château de cartes.
Je me souviens de mes premiers tests sur des get/set sur des objets de base…
J’avais l’impression que les cheveux me poussaient dans la tête (et oui, à cette époque j’en avais encore pas mal !).
Je luttais chaque jour pour comprendre et faire des progrès si petits qu’ils pouvaient sembler ridicules.
Je me sentais seul, mais je me suis accroché.
J’avais trop souffert pour abandonner.
Je n’avais plus le choix : je devais changer ma manière de travailler, et, même si le chemin était difficile, je n’avais pas vraiment d’alternative.
Alors, j’ai continué.
Cette blague de tests sur des get/set a bien duré 2 semaines…
Alors oui, aujourd’hui, beaucoup te diront que c’est ridicule de tester des get/set.
On pourrait en parler longtemps.
Mais c’est comme rigoler des premiers pas d’un enfant parce qu’il ne sait pas encore courir : c’est pas le sujet.
Le sujet, c’était de mettre les choses en route.
De commencer par un premier pas pour enclencher une démarche nouvelle.
Chaque jour remettre le travail sur l’ouvrage et recommencer pour s’approprier une nouvelle manière de réfléchir.
Quand tu commences à écrire tes premiers tests en TDD, tu as l’impression que tu inverses le flux d’information dans ton cerveau : tu réfléchis à contre-sens et c’est troublant !
Et puis, j’ai commencé à comprendre des choses.
Mes tests sont devenus plus évolués et plus expressifs.
Au fur et à mesure que je déployais les différentes pratiques de l’eXtreme Programming, j’allais de plus en plus vite.
À ce moment de l’histoire, je n’étais encore qu’au début de mon nouveau chemin, mais je pouvais déjà sentir les bénéfices au bout de 3 mois : le code que j’écrivais était beaucoup plus robuste.
Non pas que je faisais moins de régressions, au contraire, c’est juste qu’elles étaient levées en quelques secondes.
Du coup, je pouvais me permettre de coder plus vite, je savais que mes filets de sécurité s’occupaient du reste.
J’ai aussi appris 3 grandes leçons que je partagerai avec toi ces prochains jours.
Alors oui, je faisais un peu marrer mon boss avec mes petites cartes bristol format A6.
De toute façon il n’avait plus rien à perdre…
Et puis au bout de quelques temps il fallait se rendre à l’évidence : les résultats étaient incroyables.
Grâce au TDD et aux designs patterns que je découvrais quelques temps après, je pouvais coder une app de manière fluide.
J’étais en maîtrise de mon code.
Je pouvais faire évoluer les spécifications en restant super confiant sur ce qui avait été produit.
C’était pour moi une libération et une révélation : je découvrais une manière de travailler qui rendait mon travail épanouissant au quotidien.
Le souci avec le TDD, c’est que c’est une compétence qui peut être difficile à acquérir.
Il faut se remettre en question, faire évoluer ses pratiques.
Peut-être que toi aussi tu as essayé de t’y mettre.
Tu a lu ou regardé des gens de parler de la boucle en trois temps du TDD.
Et tu t’es dit que ça avait l’air cool.
Mais quand tu as essayé d’aller au delà du tuto de base, tu t’es retrouvé bien seul face à ton code…
Et là tu en as conclu que ce n’était pas pour toi.
Rassure toi, c’est normal.
Cela fait, maintenant, 10 ans que je le transmets à d’autres développeurs, et j’ai souvent ce type de retour.
J’ai compris que la marche était très haute et qu’il fallait diviser la progression.
J’ai aussi compris qu’il fallait intégrer le code legacy non pas comme un obstacle, mais comme un point de départ : peu de développeurs ont la chance de démarrer un projet de 0.
La plupart travaillent sur des projets existants.
Peut-être es-tu dans cette situation?
En intégrant ces deux éléments dans une pédagogie moderne et actualisée qui mélange cours en ligne, exercices, QCM, groupes de travail et soutien à distance, j’ai mis au point une nouvelle manière encore plus efficace de transmettre les compétences nécessaires pour écrire du code durable : c’est le Cursus Artisan Développeur.
Si tu as envie d’ en savoir plus sur ce cursus, c’est ici !
Et si tu as des questions, je suis à ton écoute.
Benoit Gantaume
Artisan Développeur