Bienvenue sur le podcast Artisan Developers, l'émission pour les programmeurs qui veulent vivre une carrière épanouissante.
Prêt à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Dimitri Bailey, Dimitri bonjour.
Bonjour.
Pour les auditeurs qui ne te connaîtraient pas, est-ce que tu peux te présenter en une minute ?
Dimitri Bailey, moi j'étais CTO chez les Furais.com et je suis mentor pour des équipes, pour les accompagner à développer,
s'organiser au niveau du développement logiciel et j'organise deux grosses conférences,
l'une sur le Flow qui s'appelle Flowcon, qui est tout le mois de novembre pour des équipes de tech,
produits et les coachs agile aussi.
Et Tech Rocks le 10 décembre pour les Techlead, les CTO.
Et on a un Slack où il y a plus de 900 CTO déjà qui échangent un peu au jour le jour sur leurs problématiques.
Cool, merci.
Et donc pendant la préparation de cet épisode, tu me faisais part de ta sidération pour les équipes qui n'avaient pas de tests.
Est-ce que tu peux m'en dire plus ?
Bah c'est tout, tout est dit.
Je tombe de très très haut quand j'arrive dans des équipes que j'essaye d'accompagner et je découvre qu'il y a zéro test dans la base de code.
Et chez les Furais c'était quoi ? Il y en avait beaucoup, c'était vraiment dans la culture, vous avez quel taux de coverage à peu près ?
Alors taux de coverage c'est pas le plus important mais je crois qu'on devait avoir 70%.
On avait 500 000 lignes de code, 40 000 tests unitaires, dont une bonne partie générée, ce qui en en reparlera plus tard si c'est cette château.
Et 3 minutes d'exécution.
Oui c'est pas mal pour 40 000 tests.
Donc on a eu un petit monsieur David Gajot qui est venu booster aux hormones la vitesse de compilation en Java avec Maven évidemment parce que c'était le challenge.
Mais on a eu des choses très très intéressantes là-dessus.
Donc oui une énorme culture du test mais pas du TDD spécifiquement.
Pour moi le test dans sa philosophie la plus pure qui est je ne peux rien refactorer si je ne sais pas de test et je refactor la plupart du temps quand je travaille sur une fonctionnalité.
Donc je nettoie le code que je regarde pour le laisser plus beau que ce que j'ai trouvé en arrivant et si je refactor j'ai besoin de test.
Donc c'est vraiment cette philosophie là qui avait chez les Furay que je l'apprécie énormément c'est la contribution du développeur sur la base de code annuelle doit être plutôt négative.
C'est à dire que s'il a enlevé des lignes de la base de code quand on parle de 500 000 lignes de code c'est plutôt positif et pas de refactoring sans test.
Et du coup là tu changes un petit peu de métier, tu passes vraiment de l'éditeur à se ligner un petit peu de conseil pendant quelques mois là.
Et du coup tu découvres le monde réel et le monde réel.
Je trouve des voix.
Mais en fait c'est ce qui me sidère.
Alors ok pas de test.
Pourquoi ?
Parce que on n'a pas le budget pour ou on nous laisse pas le temps de le faire.
Et ça ma sidération elle double.
Ok mais ça c'est pas une excuse que c'est pas une discussion.
Il n'y a pas de discussion.
Je ne peux pas livrer du code sans test.
C'est à dire que la future elle existe pas s'il n'y a pas de test de régression.
Ou si comment est-ce possible de ne pas avoir de test.
Et de se dédouaner du fait de ne pas avoir de test.
Donc là-dessus derrière pour moi c'est la sidération sur la posture.
C'est à dire c'est pas de ma faute.
Et pourtant c'est 90% des développeurs qui sont dans cette posture là.
Où est-ce qu'on a raté un truc ?
C'est où ? C'était à l'école, c'était à la maternelle.
Alors là-dessus.
En fait c'est ce qui est intéressant.
On peut, ce que tu disais tout à l'heure dans la préparation,
on peut taper avec un marteau sur le développeur.
Mais je tape avec une masseuse sur le Tech lead.
Et je commence à envoyer du bazooka sur le city-o.
Alors cher auditeur je vais être clair, je faisais une métaphore entre le marteau et le clou
qui fallait parfois taper plusieurs fois sur le clou.
A aucun moment je n'ai parlé de taper des développeurs avec des marteaux.
Je vais être clair je me dédouane totalement des propos de ce type.
Je demande l'autorisation de taper sur les développeurs dans ce cas unique.
C'est à dire s'il écrit pas de test.
La responsabilité c'est le mec qui est responsable de cette base de code.
C'est l'équipe au global.
Comment une équipe dans son organisation globale n'arrive pas à détacher quelqu'un pour écrire des tests.
S'il n'y en a pas.
Donc là la plupart du temps sur les équipes j'arrive et je dis bon,
à partir de maintenant toute nouvelle fonctionnalité sort avec des tests.
Pour info.
Et on fait l'effort qu'il faut pour ça.
Et on me dit ça coûte plus cher, je dis on le mettra dans l'estimation.
Et c'est tout.
Et ça marche ?
Parce que moi je t'avoue que depuis dix ans que je essaye de transmettre le TDD, les tests, la culture du craft,
j'ai essayé plein d'approches et d'ailleurs il y aura bientôt un épisode
où peut-être qu'il est déjà passé, où je discute avec Michael Lazerade
qui me dit mais mec t'es trop gentil, en fait t'es trop bienveillant, il m'accuses d'être bienveillant.
Je vais poser une question.
Qui lit le code et ira te dire supprimer les tests ?
Mais rigole pas moi j'en connais.
J'ai des noms, en fait ça va être trop plus pernitieux que ça.
Ils vont pas te dire, il peut y avoir des cas où ils vont te dire supprimer les tests,
mais je sais, je pense que c'est des cas assez hardcore et c'est peut-être des causes perdues.
Non, ça sera plus pernitieux ça, c'est que tes tests ne vont pas être maintenus.
Le prochain, disons, imagine donc que t'es seul dans une équipe de 7.
Tu as tous les autres copains qui vont péter le build, sauf que il n'y a que toi que ça va faire chier
donc tu vas être le seul à réagir et à un moment donné tu te uses.
Oui mais c'est la culture de code ownership d'équipe, c'est-à-dire que dans la PR, s'il n'y a pas de test, ça passe pas.
Toi c'est dans les standards de l'équipe, tout nouveau code doit être testé.
Oui mais si je mets ça dans un standard d'équipe, je veux dire que moi-même en tant que développeur, je suis obligé de m'y plier et personne le fera ça.
Oui, bien si. Alors je n'ai peut-être pas testé suffisamment d'équipe ou des gens suffisamment bornés pour refuser,
mais jusqu'à maintenant, c'est une discussion qui passe comme une lettre à la poste.
Au fait, c'est comme ça qu'on travaille.
Ok, donc dans les équipes où tu es arrivé, tu as dit maintenant c'est comme ça et...
Bah, allons-y.
Oui.
Le sujet suivant quoi. Et c'est passé.
Oui, c'est une posture. Et je ne le revendique pas, je n'explique pas que c'est du TDD, que c'est du machin, je n'ai pas de discours théorique.
C'est nécessaire. On ne peut pas...
Comme en ce moment avec le Covid, vous mettez un masque.
Voilà, c'est ça. Très bonne, très bien ça là.
Elle est très très bonne. Non mais c'est parfait.
Oui, c'est ça. C'est une question de posture. C'est-à-dire que non, mon métier de développeur nécessite que ce que je sors soit testé.
Parce que c'est pas douter que ce que je fais a un problème.
C'est quand quelqu'un le modifiera, je veux lui parler en lui disant attention, le comportement que j'ai codé ne marche plus.
Moi, j'ai aucun problème à dire que testé c'est douté.
Ah, même au pareil. Tu me dis, mais testé c'est douté, je dis oui, je doute.
Ben oui, je suis un être humain. Et les gens qui ne doutent pas, c'est eux qui m'inquiètent enfin.
Mais tu vois, en fait c'est une question de posture. Donc les tests, après, si on passe un cran plus loin,
parce que c'est sympathique de dire qu'ils n'avaient juste pas le courage de le faire, mais derrière ils ne savent pas forcément le faire.
Ils n'aulons jamais fait, donc c'est un peu la plus...
C'est essentiellement la raison. C'est essentiellement la raison d'ailleurs.
Mais il y a bien quelqu'un dans l'équipe qui en a déjà fait.
Pas toujours, hein.
Mais allez, sur 20, tu vas en trouver un ou deux. Je suis d'accord, je te les conseille.
Oui, mais même sur cinq. Mais sur cinq.
Moi, tu es vraiment une équipe de très jeunes où il y a zéro TechLead et là, c'est d'autres problèmes qui vont t'arriver.
Ah ben je connais même des équipes où c'est le TechLead qui est contre.
Oui, mais c'est avec lui que tu as plus envie d'avoir la discussion et si l'équipe ne le fait pas,
on a cette question de savoir faire.
C'est-à-dire que s'il est contre, c'est qu'il n'a pas ce savoir-faire et quelque part,
est-ce qu'on a envie d'aller jusqu'à la discussion de savoir la différence entre des amateurs et des professionnels ?
Pour moi, c'est très clair. Si tu le fais pas, tu es pas un professionnel aujourd'hui.
C'est pas moi qui voulait le dire.
Mais c'est ce que tu pensais à vous.
Oui, évidemment. Mais je peux pas.
Là, je viens de me mettre à dos 50% des auditeurs.
J'ai envie de provoquer là-dessus. En disant, ça fait partie du métier.
C'est votre métier de défendre cette approche-là.
Oui, tu me parlais des développeurs qui demandaient la permission.
Les gars te disent, ah oui, mais on a demandé, on nous a dit non.
Il fallait pas demander.
Oui, c'est ça.
Just do it.
Je vous dis, demandez.
Oui, c'est ça. C'est-à-dire qu'il faut pas en faire une revendication pour moi.
Il faut juste le faire.
Ça fait partie du travail.
J'ai envie que plus on monte dans les échelons, que ce soit un standard de per-review dans la PR.
Mais dans les specs, il y a bien des tests d'acceptance.
Pourquoi cela sont-ils pas codés ?
Si il y a des specs sans tests d'acceptance, là, ça commence à devenir très difficile de savoir qu'est-ce qu'on est en train de faire professionnellement.
Mais le producteur de sa profession, elle est aussi de lister les tests qui sont à faire.
Et ce n'est pas manuellement.
Donc, ça veut dire qu'on n'a pas implémenté l'aspect.
Tiens, ça, c'est un autre argument.
C'est que dans l'aspect, il y a des tests.
Oui, tu fais encore plein d'assomptions de...
J'ai plus le mot qui me vient en tête, mais tu mets déjà plein de pré-roquis.
Et effectivement, ça va souvent ensemble.
C'est-à-dire que les équipes qui ont dû mal écrire les tests, je remarque,
ont du mal aussi à écrire des recettes, des cahiers de recettes qui tiennent un peu la route avec des critères et qui...
Parce qu'effectivement, une fois que tu as ce boulot, de te dire que en tant que développeur, tu vas automatiser cette recette,
c'est juste de la bonne féniontise, en fait.
Exactement.
Donc, tests unitaires,
à minima, des tests end-to-end et des tests de régression graphique aussi.
C'est les trois points, là.
Pour moi, après, il y a des tests de performance.
Mais je ne vois pas comment une équipe peut survivre si elle n'a pas ces trois points-là
pour aller vers de la livraison plus continue, plus souvent,
pour livrer à l'utilisateur des fonctionnalités les unes après les autres.
Dmitri, je te propose que ce soit le mot de la fin, parce qu'on a mangé la Timebox.
Si les auditeurs veulent en savoir plus sur ce que tu fais, ils peuvent venir où ?
Ils peuvent venir à Flocone.
On en parle pas mal.
Tout le mois de novembre.
Et puis, sur le Slack de Tech Rocks, effectivement, d'envoyer leur Tech Lead,
ou de venir parler sur le Slack de Tech Rocks.
Ok, on mettra tous les liens dans la description de l'épisode.
Je te remercie, Dmitri.
Merci beaucoup.
Quant à toi, chers auditeurs, j'espère que cet épisode t'a plu.
Je pense qu'il fait partie de la catégorie de ceux qui méritent une écoute commune.
Donc, si tu as un petit peu envie de chattouiller tes collègues,
de voir carrément de jouer les poils à la gratter,
je t'invite à organiser une écoute commune.
C'est assez facile.
Tu prends un truc à manger que ton équipe aime bien manger,
du heurte des gâteaux, des biscuits, des bonbons.
Ça marche toujours avec les développeurs.
Tu organises un petit café.
Tu écoutes tous ensemble l'épisode et après, vous en débattez.
Ça fait une petite animation sympa de 30 minutes.
Et va savoir ce qui pourrait en émerger.
Je te remercie.
Je te dis à bientôt.