Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui, je suis avec Xavier Nobbre. Xavier, bonjour.
Bonjour, Vénor.
J'aimerais te proposer un sujet qui est la barre verte.
Alors, sous quelle angle est-ce qu'on va pouvoir attaquer la barre verte ?
Évidemment, je fais référence à la barre verte du TDD.
Dans le podcast précédent, tu parlais de cette fois où tu t'étais senti totalement en confiance
quand tu avais fixé un problème.
Et pour moi, je trouve que la barre verte apporte ça.
Entre autres, c'est la confiance dans ce que tu as fait.
C'est-à-dire que pour moi, la barre verte, et je pense que c'est important de le dire,
de bien l'exprimer aux auditeurs, c'est que la barre verte,
c'est pas juste une barre verte en fait.
Le secret du TDD, et sur quoi j'insiste le plus quand je le transmets,
c'est vraiment l'alternance de couleur.
Donc la barre verte n'est pas un absolu en soi.
C'est-à-dire qu'il y a des moments où il faut qu'elle soit rouge,
il y a des moments où il faut qu'elle soit verte.
Et c'est cette alternance-là qui garantit que ce que tu es en train de faire sert à quelque chose.
Toi, qu'est-ce que tu ressens ?
Est-ce que tu peux nous parler de ces émotions que tu peux avoir quand tu as ta barre verte ?
C'est vrai que, comme tu le dis, c'est une question d'alternance.
Donc c'est vrai que dans la pratique au quotidien,
lorsqu'on est un peu entraîné au TDD,
c'est vrai que cette barre verte, ce voyant vert qu'on peut avoir dans l'éditeur,
c'est quelque chose effectivement de rassurant et qui permet vraiment de se sentir avancé de façon progressive.
Comme tu le dis également, il faut qu'il y ait cette alternance.
C'est-à-dire qu'il ne faut pas que ce soit tout le temps vert, sinon là ça devient un peu inquiétant.
Il faut qu'il y ait ce rouge de temps en temps, enfin de temps en temps en alternance.
Donc en TDD, on va écrire un test et puis vérifier qu'il ne passe pas
pour de bonnes raisons, donc là ça doit être rouge.
Ensuite le faire passer rapidement, là ça doit être vert,
et ensuite la troisième phase de refactoring.
Et là, on a le vert encore qui est là pour nous aider.
Donc c'est vrai que cette première étape du rouge, comme j'explique souvent,
elle est pour moi en deux étapes, c'est-à-dire écrire le code,
essayer d'écrire un test de poutambou, même si ça compile pas, c'est pas grave,
et ensuite de faire compiler pour que le test puisse être exécuté.
Donc c'est vrai que, déjà lorsque le test arrivait au pout,
cette phase rouge qui peut être en deux temps,
où le code compile s'exécute et comme je dis,
où le test ne passe pas pour de bonnes raisons,
c'est-à-dire que vraiment on a l'erreur qu'on imaginait avoir.
Déjà, c'est finalement déjà là, il y a quelque chose qui me plaît,
c'est-à-dire que j'ai réussi à écrire un test qui passe pas,
ça veut dire qu'il a priori, si je l'ai bien écrit,
il va me pousser à implémenter quelque chose de positif pour l'application,
et si l'erreur que j'ai, et bien l'erreur attendue, je suis sur la bonne voie.
Donc ce rouge, déjà, me permet de sentir que j'ai déjà posé une première pierre,
fait un premier pas.
Ensuite, il y a la deuxième phase qui, dont le but,
c'est vraiment d'implémenter rapidement.
Alors moi, je suis toujours pragmatique, c'est-à-dire que je ne suis pas un extrémiste,
en tout cas dans ma pratique, mais j'implément du code minimaliste
qui va permettre de faire passer au vert.
Et ça, comme j'essaie d'expliquer souvent,
un développeur ne peut pas écrire du code propre et du code qui marche.
Donc pour moi, l'idée, c'est de commencer par écrire du code qui marche,
et c'est ça, le voyant vert, c'est de nous prouver qu'on arrive à le faire.
Et j'essaye souvent d'insister sur le fait que,
il y a des fois, on va écrire un test,
et puis derrière, on va peut-être mettre un peu du temps
à réussir à implémenter un algorithme un peu tordu
ou une architecture ou une API fluente,
un peu novatrice par rapport à nos habitudes.
Et donc de réussir à atteindre le vert, ça veut dire qu'on sait le faire.
On a réussi à le faire.
Je me souviens avoir implémenté des calculs de thermique en bâtiment
qui m'étaient donnés dans plusieurs fichiers Excel par des termiciens.
Et quand le test n'était pas très compliqué,
je mettais les valeurs attendues dans le test du terres,
et ensuite, il fallait implémenter les bons calculs quand t'as le vert qui apparaît et t'es content.
Et après, la phase de refactoring qui est très importante,
et là aussi, c'est en général beaucoup de plaisir ou de satisfaction
d'être vraiment tranquille,
seraient à pouvoir vraiment se concentrer là par contre sur
le fait que le code doit être propre, lisible, bien architicturé,
et toujours avec ce voyant vert.
La nuance que tu as intègre, je la trouve super importante,
j'insiste toujours là-dessus, et j'aimerais rajouter en fond celles clous.
Il serait tentant de s'arrêter à la phase 2.
Dès que le test passe et est ouvert, cool, c'est fini, je passe à la suite.
Mais si tu fais ça, tu n'as pas vraiment fini en fait,
et puis tu crées poliment de la dette pour le dire poliment.
Moi, ça me paraît essentiel de bien comprendre que le cycle ne se termine
que quand tu as fini les enjeux de refactoring,
que tu as fait vraiment ton refacto.
Le problème que j'ai un petit peu à chaque fois,
c'est jusqu'où ça s'arrête, ou où j'arrête,
parce que le refactoring, souvent, c'est comme les chips.
Tu sais quand tu commences, mais tu ne sais pas quand tu finis.
Donc, comment je sais que je m'arrête ?
Moi, j'ai une ligne directrice qui est quand je sens que les concepts
sont en train d'émerger, mais que je les utilise qu'à un endroit,
je ne vais pas forcément chercher à faire émerger le concept.
Je vais attendre qu'il soit utilisé au moins à deux endroits ce concept
pour me dire, tiens, je l'avais déjà vu passer,
et lui, ça fait deux, trois fois que je le vois passer.
Ok, il y a un truc qui est en train d'émerger.
Toi, comment est-ce que tu arrêtes le refacto ?
C'est quoi tes critères pour dire,
ok, là, j'ai assez faite refactorer, j'arrête,
parce que sinon, ça pourrait durer l'infinité de refactorer ce code.
Oui, en finité, je ne sais pas.
Il y a un avantage avec les chips,
c'est que quand le paquet est vide, sauf si tu n'as pas le paquet,
bon, a priori quand le paquet est vide, ta tendance a t'arrêter.
C'est peut-être plus facile.
Effectivement, c'est un peu une difficulté d'ailleurs.
Il y a une autre difficulté, souvent,
moi, je l'ai vécu à mes débuts,
qu'on parlait dans un épisode précédent des déclics,
c'est de trouver l'équilibre, c'est à dire un moment d'être même trop extrémiste,
à passer beaucoup trop de temps dans cette phase de refactorer,
mais peu importe.
Moi, quand j'accompagne des équipes,
alors c'est vrai que c'est la pratique,
qui je pense permet de trouver la bonne limite,
la pratique personnelle, de s'entraîner,
ou la pratique en équipe,
ou la patrique avec quelqu'un qui accompagne.
Déjà, il y a plusieurs niveaux.
Il y a déjà le premier niveau,
c'est de repasser sur le code qu'on vient d'écrire,
de vérifier que tout est bien nommé,
qu'on a des variables qui ont des bons noms,
qui n'ont pas des IJK ou ABC,
qu'on a des méthodes qui sont bien explicites,
qu'on n'a pas de commentaires là où il n'y en a pas besoin,
et en général il n'y en a pas besoin.
Donc voilà, il y a déjà cette phase de refactoring.
Ensuite, tu abordes un point qui fait partie,
effectivement, de cette phase de refactoring.
Alors moi, je n'en parle pas toujours d'emblée,
parce que c'est quand même dans un stade un peu plus avancé,
c'est de profiter de cette phase de refactoring
pour voir émerger des concepts ou des patterns
ou des choses qu'on va pouvoir mettre en place
du coup sur le code qu'on est en train de décrire.
Donc il y a des choses qui ne sont pas très compliquées,
mais c'est par exemple du code dupliqué, des choses comme ça.
Mais même ça, ce n'est pas si simple,
parce que quand on voit quelqu'un qui a assez novice sur le TDD,
il va avoir ce réflexe de ne pas vouloir dupliquer du code,
parce que dupliquer le code, on lui a expliqué que ce n'était pas bien.
Et alors que ce qui est difficile à comprendre peut-être,
c'est de s'autoriser, de s'autoriser, à dupliquer du code,
s'autoriser à écrire quelque chose de pas très propre,
le temps d'écrire et de faire passer plusieurs tests,
peut-être trois, quatre, cinq tests avec des YIF,
et il faut que cette sensation que le code qu'on écrit
n'est pas propre, qu'il est mal foutu,
mais de s'odonner du temps et des tests supplémentaires
pour voir émerger, j'allais dire, la bonne solution,
en tout cas une meilleure solution.
Donc c'est vrai que c'est quelque chose qui vient pour moi
dans un stade déjà un peu plus avancé du TDD
et qui n'est pas si facile.
Avec ou tu t'en m'assois, je te propose que ce soit le mot de la fin.
Merci d'être venu Xavier.
Merci pour l'invitation Benoît.
Je t'en prie.
Quant à toi cher auditeur, j'espère que tu as apprécié ce podcast.
Si c'est le cas, je t'invite à vite nous rejoindre
dans la communauté sur artisandeveloper.fr.
Et tu peux aussi aller voir ce que fait Xavier sur XavierXNopre.blogspot.fr.
Je te mets le lien dans la description.
A demain.