Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Guillaume Vincent, Guillaume Bonjour.
Salut Benoit.
Je te propose qu'on parle de mon sujet préféré, le TDD.
Et tu avais une phrase que j'aimais bien, je pense que ça vaut le coup quand
la partage avec les auditeurs et que tu nous expliques ce que ça veut dire pour toi, tu me disais
est-ce que tu te demandes à ton chirurgien si cela vlait mal avant de t'opérer ?
Comment est-ce que tu fais un parallèle avec le TDD ?
Ben si on demande à un chirurgien si cela vlait mal, ça paraît assez normal que les chirurgiens se
lavent les mains avant d'opérer et du coup pour le développement piloté par les tests,
quand on me demande si j'en fais, je pense à la même chose.
Pour moi le test c'est la même chose que cela avait les mains pour un chirurgien,
le TDD ça devrait être la même chose pour un développeur.
Ça devrait être une pratique que le développeur fait de manière naturelle et à qui on ne
pose pas la question de est-ce qu'on doit le faire ou est-ce qu'on ne doit pas le faire.
Est-ce que tu le mets au niveau de l'hygiène ou est-ce que tu le mets au niveau du professionnalisme ?
Du professionnalisme.
Pour toi un développeur professionnel il fait du TDD et c'est même pas une question.
Oui du moins il fait des tests.
Et là on vient de se fâcher avec tous les développeurs qui se disent professionnels
et qui n'en font pas.
Oui c'est une pratique, je considère qu'on est professionnel quand on a des pratiques
comme le développement piloté par les tests.
Et peut-être que dans 20 ans on ne se posera pas la question et tout le monde fera du
développement piloté par les tests, ça sera rentré dans les meurs des développeurs.
Après il faut savoir que le développement piloté par les tests devient un pré-requis
maintenant dans beaucoup de boîtes et on le voit apparaître dans les offres dans notre
métier.
Petit à petit c'est une pratique qu'on devra maîtriser si on veut trouver du boulot.
Pour l'instant c'est pas le cas.
Ce qui rejoint une question que j'ai eu il y a pas longtemps, même aujourd'hui sur LinkedIn.
Un développeur me demandait d'après toi est-ce qu'on peut faire de l'agilité sans TDD
et moi ma réponse a été non.
Après en deuxième instant je me suis ravisé et à me dire en fait c'est pas une question
d'être possible ou pas.
C'est une question est-ce que c'est efficace ? Est-ce que c'est efficace de travailler
sans TDD ? Ma réponse là pour le coup est clairement moins efficace sans qu'avec.
Et plus d'une manière plus globale je pense et j'en ai acquiert de plus en plus la conviction
que faire de l'agilité c'est de dire passer des approches classiques cyclanvé ou compagnie
qui durent des mois à des sprints de semaine.
Si il n'y a pas une quête d'excellence technique c'est juste une entreprise qui est
vous à l'échec parce que tu vas vite te prendre des murs.
Alors qu'est-ce que tu en penses toi ? Est-ce qu'on peut faire de l'agilité sans TDD ?
Clairement non.
Enfin sans intégration continue, sans tous ces outils là, sans les tests.
Clairement si faire de l'agilité pour certains c'est n'est qu'essayer d'appliquer des
pratiques de gestion de projet sans derrière tout ce qu'il y a en relation avec l'extrême
programming.
Pour moi c'est une hérésie et puis ces gens là je pense qu'ils n'ont pas réussi
beaucoup de projets ou qui se voient de la face.
Il y a des études et des recherches qui montrent que le TDD par exemple amène à du code plus
modulaire qui comportent moins de bugs.
Oh tu as des études carrément là-dessus ?
Ah il y a plein d'études qui sortent, ça il y a des pratiques blancs.
On pourra peut-être les linéer.
Ah ouais si tu as des ressources ça ça m'intéresse non ?
Ouais on les mettra je sais pas comment on pourrait les partager avec la communauté
mais il y a de plus en plus de recherches qui montrent l'université américaine entre
les autres.
Il faudrait que je les ai… Si d'ici la publication on a remis la main dessus on te met les liens
et si c'est pas le cas on te demande de nous aider à le faire et envoie-nous s'il te
plaît si tu cherches et que tu trouves des trucs on les mettra dans la description de
l'épisode.
Yes.
Moi ce que tu me dis ça me paraît évident mais en fait à un moment donné je sais pas
comment le dire.
Cette évidence là elle vient de mon expérience qui est très empirique et qui a pas la prétention
d'être universelle.
Donc si tu veux à un moment donné des choses me deviennent évidentes pour moi et je partage
complètement ton point de vue.
Par contre quand tu es confronté en fait c'est tellement rare ce point de vue qu'à un moment
donné tu dis mais c'est pas possible on est peut-être 1% des développeurs à penser
ça.
Qu'est-ce qu'on ne voit pas que voient les 99 autres ou l'inverse qu'est-ce qu'on
voit que les 99 autres pour ça ne ne voit pas et qui fait qu'on a l'impression de vivre
dans des mondes différents.
Bah moi j'aimerais bien voir tous ceux qui ne pratiquent pas des pratiques dans une
horéologie cielle, l'intégration continue, le développement piloté par les tests.
J'aimerais bien voir la qualité du code en fait et le succès de ces projets là.
Et en fait on les voit pas et on n'a pas ce code là parce que d'une il n'est pas
ouvert et puis derrière c'est des Big Ball of Mud là, c'est du code spaghetti indébugable
sur lequel il faut 400 jours Rome pour avoir une fonctionnalité.
Enfin moi je peux discuter plein de fois avec plein de gens, moi j'aime bien qu'on
me prouve quand on me dit que l'agilité ça marche sans pratique des streams pour
voir. Et je connais pas parce que ça n'existe pas mais jusqu'à preuve du contraire j'ai
pas de gros succès de produits qui ont explosé à grande échelle dans lequel il n'y a pas
des tests, il n'y a pas de l'intégration continue, il n'y a pas du développement
continue, il n'y a pas des tests.
En tout cas moi je fais un constat qui là est un constat qui me paraît assez objectif
c'est que je connais plein d'équipes qui sont en scrums ou dérivés qui n'ont pas
de ces pratiques là qui ne me pratiquent pas, qui ne m'aient pas en œuvre ces pratiques
d'ingénierie et qui ont des gros problèmes. Visiblement il y a des équipes qui font du
scrum qui ne s'intéressent pas trop à ces sujets là et qui disent sans sortir.
Après effectivement si développer une feature focassant au Jorum on peut se poser des questions.
Ce que je veux dire par là c'est qu'il y a plein de contexte où on trouve ça normal.
Ils ne sont même pas conscients qu'on pourrait faire mieux.
Par contre je ne connais aucune équipe dans les développeurs pratiques à fond les pratiques
de l'extrême programming et qui ont des problèmes. Ce que je veux dire c'est qu'ils
ont des problèmes de capacité à faire évoluer leur code. Les problèmes que je vois dans
les équipes scrums sans ça il n'y a pas de problème dans l'adoption de l'agilité chez
les équipes qui adoptent l'extrême programming. Est-ce que ça tient debout ce que je dis ?
Après moi j'aimerais que les gens se posent la question combien de fois dans leur vie
ils ont vu Facebook tomber ou GitHub tomber ou Twitter tomber et qu'ils se posent la question
de comment s'est développée derrière. Est-ce qu'ils savent comment par exemple que GitHub
pousse 400 fois par jour son code et qu'arrière on va dire oui ils sont très gros. Depuis le
début GitHub il n'y a pas eu beaucoup beaucoup de downtime et à chaque fois qu'il y a un
downtime on en entend parler presque dans les journaux donc il faut que les gens se rendent
compte qu'on en revient toujours à ce terme-là le professionnalisme de notre métier. C'est
important et il faut qu'on utilise des pratiques qui sont plus rigoureuses comme le développement
public de par les tests, comme beaucoup de pratiques qui sont issus de l'extrême programming et que
tant que les gens n'auront pas compris ça en fait et bien on aura toujours les mêmes problèmes
ils auront toujours les on se posera toujours la question de savoir d'accepter en fait c'est un autre
souci aussi c'est qu'on accepte trop que le logiciel s'applante. Les bugs c'est normal.
Oui. Voir dans certains cas pour certaines sociétés les bugs si tu les enlèves on gagne
comment notre vie derrière. Ah oui ça c'est encore un autre problème je pense qu'il y a du travail
même s'il y avait moins de bugs. Oui non mais ce que je veux dire c'est que dans certains cas
on parle de très très loin. Mais ça nous porte préjudice. Notre profession on n'est pas considéré
comme des professionnels contrairement à d'autres professions on est encore considéré comme des
amateurs à qui on demande de réaliser des choses. Enfin le un centre informatique c'est souvent
considéré comme un centre de coups et pas du tout comme un centre d'innovation ou quelque chose qui
va apporter de la valeur et on voit vraiment ça c'est normal pour tout un chacun de redémarrer son
ordinateur quand il plante. C'est tout à fait normal pour quelqu'un d'attendre cinq secondes
pour le chargement d'une page web. Alors que ça devrait être inacceptable. Donc du coup tant
qu'on n'aura pas amélioré ça malheureusement on sera pas considéré comme des professionnels.
Donc c'est pour ça que je suis un peu vindicatif ou que du moins j'essaie de pousser les pratiques
d'extame programming comme le TDD qui était le sujet de l'épisode d'aujourd'hui pour que
tout le monde s'y mette ou tout le monde se remette en question en essayant de dire voilà comment
je peux améliorer mes pratiques et comment on peut aider la communauté à devenir plus professionnel.
Bah écoute c'est super je te remercie Guillaume je te propose que ce soit le mot de la fin.
Merci Benoît. Où est-ce qu'on peut venir te suivre si on veut en savoir plus sur ce que tu fais ?
Alors on peut venir voir le code que je publie sur github.com slash guillaume vincent pour
voir tout le code que je fais qui est ouvert et libre. Bah écoute c'est super je te remercie. Si
toi aussi cher auditeur tu as envie d'apprendre les bonnes pratiques dont on parle de plus de
dont on a parlé tout au long de cet épisode je t'invite à rejoindre la maison des compagnons
sur maison.artisandeveloper.fr et je te dis à demain.