Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Est-ce que ça t'est déjà arrivé ?
En codant un truc, te casser quelque chose ailleurs ?
Eh ben moi ça m'arrive encore hein !
Tu sais le truc où tu t'es très content de toi et puis d'un coup tu as un truc qui pète ailleurs et tu t'y attendais pas du tout.
Ça peut être franchement terrible parce que si ça arrive trop souvent, ça peut déprimer l'équipe.
Tu imagines ? Tu fais un truc, bam tu caches quelque chose ailleurs.
Et puis tu essayes de le réparer et puis bam tu casses encore quelque chose ailleurs.
Moi j'ai codu des équipes qui arrivaient même à un stade, c'est un peu le stade ultime.
Le projet avance de moins en moins vite jusqu'au jour où en fait l'essentiel de l'énergie est absorbé par la réparation des trucs qui ont été cassés la veille.
Parce qu'on a essayé de réparer autre chose.
Bon là tu sais que ça sent le sapin.
Parce que à un moment donné les donneurs d'ordre, ils se fatiguent un peu, la confiance s'étuole et c'est normal.
Personnellement ces problèmes de régression en cascade dans ma jeunesse, c'était franchement angoissant.
J'avais peur de casser un truc.
Dès lors que tu mets du coeur à l'ouvrage, je sais pas moi, j'ai toujours mis beaucoup de coeur à l'ouvrage quand je travaillais, que je codais.
J'avais envie que ça marche et puis je livrais des choses donc je voulais que mon client soit content.
Encore une fois que le client soit interne ou externe, c'est pareil.
Soit mon boss, mon manager, mon vrai client.
Du coup je t'avoue que même pour moi c'était parfois angoissant.
Le problème, le problème c'est pas d'être bon ou pas bon, le problème c'est qu'un logiciel est quelque chose de vivant et de complexe.
C'est vivant dans le sens où ça évolue en permanence.
Et j'ai envie de te dire, même si lui même, si le logiciel n'évolue plus, même s'il est dans une phase de maintenance très légère,
et de toute façon son environnement, lui, il bouge.
Donc un logiciel n'est jamais issu de nulle part, il est toujours connecté à quelque chose, ne serait-ce qu'un ordinateur, un operating system,
il peut être connecté au réseau dès lors qu'il est dépendant de services externes, je t'en parle même pas.
Alors oui effectivement, si tu es sur une machine que tu maîtrises totalement, qui ne bougera jamais,
sur un Windows ou un système, un Linux qui ne bougera jamais, sur un logiciel qui ne bougera jamais,
bon ok, ça va pas trop évoluer, mais bon, là il va se calcifier le projet, il va se rigidifier et puis en fait, il va mourir.
Comme un organisme vivant, dès qu'il ne bouge plus, dès qu'il ne grandit plus, dès qu'il ne vit plus, il meurt.
Et puis c'est complexe.
Et c'est cette caractéristique qui nous intéresse le plus, mais tu remarqueras que le vivant est complexe.
C'est complexe dans le sens où un changement même minimum quelque part peut avoir un impact important ailleurs.
Et si tu essayes de résoudre un problème complexe avec une approche compliquée, bah tu vas dans le mur.
A un moment donné, le cerveau du développeur ne peut pas tout maîtriser, il ne peut pas avoir en tête conscience de tous les enjeux,
de toutes les interdépendances entre les objets qui manipulent.
Et ça n'a rien à voir avec le fait de savoir coder ou pas coder.
J'en entends des fois qui me disent, ah tu sais, si tu sais coder, t'as pas besoin d'écrire des tests parce que le code que tu crie, il est bon.
Non, ça c'est du bullshit.
Si tu es doué que tu es bon, tu vas avoir une meilleure conscience de ce que tu fais, tu vas être capable de faire quelque chose de plus robuste.
Tu vas peut-être avoir une meilleure vision sur les impacts que tu vas engendrer.
Tu vas pouvoir peut-être mieux anticiper les choses.
Mais à un moment donné tu auras une limite.
Et savoir coder n'a rien à voir avec le fait de douter du code que tu as en train d'écrire.
Tu n'écris pas des tests, enfin moi je n'écris pas des tests auto, je ne fais pas du TDD parce que je doute de ce que j'écris.
Et ce que j'aime avec le TDD, c'est que c'est simple et qu'il me sert de radar.
Je te l'ai dit, si tu essayes d'attaquer un problème complexe avec une approche compliquée, tu vas dans le mur.
Avec le TDD, tu attaques un problème complexe qui est un problème de design avec une approche qui est ultra simple.
Elle n'est pas simple, c'est pas simple.
Le TDD c'est ultra simple, c'est tellement simple.
Tu regardes n'importe quel vidéo sur le TDD, en 10 minutes tu le comprends.
Peut-être même 5.
Bon après je ne te le cache pas, ça va mettre du temps pour que tu le mettes en œuvre.
Il y a une grosse différence entre comprendre le TDD et mettre en œuvre le TDD.
Mais ça c'est autre chose.
Et là oui, ça peut faire partie de ce qu'on appelle un bon développeur ou pas un bon développeur.
Ça fait partie de ta trou, ça utile, ça fait partie de tes compétences.
Le TDD c'est simple et ça me sert de radar.
C'est un peu comme en navigation.
Avec un radar, en nav, quand tu es sur un bateau, tu traverses l'Atlantique, tu peux détecter les autres bateaux.
Tu peux détecter ceux qui sont équipés d'un transpondeur, tu vas pouvoir détecter aussi ceux qui sont assez gros pour que le radar marche.
Tu vas pouvoir aussi peut-être détecter des grosses vagues, des vagues qui pourraient être dangereuses pour le bateau et le faire chavirer.
Bon je te l'accorde, il y a certains obstacles, des objets flottants non identifiés que tu ne vas pas voir.
C'est un peu l'angoisse d'ailleurs du navigateur.
Par exemple les conteneurs qui sont à fleur d'eau.
Par avec le TDD c'est pareil, il y a peut-être des choses qui vont échapper.
Le TDD c'est... il y a des bugs qui arrivent même avec le TDD.
C'est pas magique.
Par contre avec le TDD je détecte énormément de choses.
Avec le TDD dès que j'ai une idée, dès qu'il y a un changement, dès que je fais quelque chose je suis capable d'en mesurer l'impact en quelques secondes.
Allez, parfois sur des très gros projets qui ont des grosses batteries test en quelques minutes.
Et là je reconnais que même si d'avoir la batterie test n'avait pas pour fonction première la non-regression, ça offrant quand même un sacré filet de sécurité.
L'enjeu de l'écrire un test, l'enjeu du TDD c'est pas un décret des tests.
C'est de designer mon code.
C'est de m'aider à designer et à résoudre un problème complexe avec une approche ultra simple.
Je te remercie d'avoir écouté ce podcast jusqu'au bout.
Si tu l'as apprécié tu peux me rendre en service.
Je suis sûr que tu connais au moins une personne que ce podcast pourra intéresser.
Que le message pourra intéresser.
Et si c'est le cas, alors, je t'en prie, partage-le avec lui.
Ça lui donnera peut-être envie de mettre en oeuvre le TDD, qui sait.
Je te souhaite une bonne journée.