
101 - Le TDD C'est Trop Dur Avec Michael Azerhad
Durée: 15m19s
Date de sortie: 15/11/2018
Le profil linkedin de Michael : https://www.linkedin.com/in/micha%C3%ABl-azerhad-9058a044/
L'entreprise de Michael : http://wealcomecompany.com
Se former dans la maison des compagnons : https://maison.artisandeveloppeur.fr
Rejoindre la communauté des artisans développeurs :
https://artisandeveloppeur.fr
Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.
Bienvenue sur le podcast Artisan Developer,
l'émission qui combine technique et agilité pour partager la passion du code.
Aujourd'hui je suis avec Michael Azerad, Michael bonjour.
Bonjour Benoît.
En préparant cet épisode, on échangeait un petit peu et je suis tricuré de ton retour d'expérience
parce que je pense qu'il peut intéresser les auditeurs.
On disait, tu me disais, je viens de me rendre compte que parler de TDD c'est trop dur
et de commencer par TDD c'est trop dur.
Et j'avais fait le même constat il y a quelques mois,
c'est-à-dire qu'une équipe qui veut mettre en place du TDD
souvent parce qu'il commence à se préoccuper de la qualité logicielle,
il se dit, tiens, si on automatise et n'autaises, donc il vient de noter TDD.
En général évidemment sur du code legacy,
mais géraliser un truc c'est le plus dur en fait.
Mettre en oeuvre du TDD sur du code legacy, c'est le truc le plus difficile à faire en fait.
C'est comme si tu me disais, viens on démarre l'alpinisme
et que je te disais, ok on va tout de suite dans l'Himalaya en fait.
Exactement.
Qu'est-ce que t'en penses toi ?
Moi ce que j'en pense en fait c'est que TDD en fait
est une pratique qui englobe énormément de pratiques en fait.
C'est à dire, c'est un mix en fait de plusieurs connaissances.
Ce qui se passe aujourd'hui c'est qu'il y a beaucoup d'aigles
qui sont sensibilisés au clean code, d'autres aigles
qui sont sensibilisés aux dizaines paternes, d'autres aigles aux tests etc.
Et rarement en fait, on a dans les entreprises des devs
qui sont déjà à l'aise sur tous ces sujets là.
Ce soit le design, parce que TDD à l'avant tout c'est du design.
Ce soit en termes de culture, la culture des termes au niveau des tests,
c'est quoi un Moc, c'est quoi un Spy, c'est quoi un demi, c'est quoi un double, c'est quoi...
Tout ces trucs là.
Si une personne n'a pas en fait un oeil assez diversifié sur toutes ces connaissances
elle peut pas commencer à TDD, c'est pas possible.
Et donc ce qui va se passer c'est qu'elle va tenter de le faire
parce que à ce qu'il paraît c'est à la mode etc.
Mais va avoir un retour d'expérience rémové en fait.
Ou qu'il n'est pas du tout optimisé, un petit peu comme une ferrarée en première vitesse.
On n'a jamais mis en 6e.
Et donc au final ces personnes là vont écrire dans leur CV
on a fait du TDD, on est expert TDD, mais en fait ils ont loupé toute la facette magique de ce truc là.
Et donc c'est pour ça qu'en fait je pense que
pour commencer TDD soit il faut le vivre
déjà avec quelqu'un qui te guide au quotidien
par exemple Tadkid qui lui est s'il est formé là-dessus
qui a l'habitude de le faire.
Le vrai TDD, à ce moment là c'est l'idéal.
C'est ce que j'ai vécu l'année dernière avec...
enfin cette année même, avec un développeur
qui avait 25 ans, donc même pas 24 à l'époque.
Et donc il était junior en fait, junior Java.
Et quand je me présente TDD etc.
la première question c'est oui que j'en ai entendu parler
mais je sais pas comment m'y prendre.
Donc ce garçon florien avait des très bonnes bases en Java
à mon avis un petit peu au-dessus de la moyenne
donc ça m'a... c'était rassurant
mais avait pas du tout la bonne culture au niveau des tests
au niveau de TDD.
Et il pensait vraiment que TDD c'était juste testé et compagnie
et qu'au final c'était en quelque sorte facultatif
combien de fois on a vu TDD douter
ça devient même lourd de dire à je sais pas
cette petite citation, cette petite phrase
l'idée c'était de lui enseigner pendant un an
je travaillais un an avec cette personne en TDD
pendant un an je lui ai enseigné ce que c'était TDD
et aujourd'hui elle est fascinée par cette pratique
et le problème c'est que ça lui ferme énormément de portes
c'est parce que la plupart des missions
n'ont pas en fait ce perfectionnisme
à porter par TDD etc.
et donc du coup cette personne refuse.
Donc la question c'est comment on arrivait là
comment on arrivait de quelqu'un
qui ne connaissait pas ce monde là
qui avait juste comme prétention, comme exigence
de vouloir bosser sur des techniques récentes
aujourd'hui on ne rend n'importe quel développeur ce qu'il veut
c'est l'idéal c'est ah moi vous faites du rien
mais tout le contexte derrière qui en fait
la matière première du contexte
pour lui c'est pas important
est-ce que c'est du code EGASIS
il y a vraiment du clean code
il y a des gens perfectionnistes dans l'application
ou est-ce que c'est du code à l'arrache
non, ce qui va intéresser le développeur c'est la technique
et moi j'ai pris un an avec ce merc au début
donc je pris un mois avec cette personne
que j'adore et je lui ai expliqué
justement que le plus intéressant
c'est tout ce qui est clean code
c'est comment arriver à avoir du clean code
pour au final se débarrasser dans le gira
au sens anomalie
c'est à dire qu'on a plus d'anomalie en fait pendant un an
on a plus d'anomalie sur gira
comment on fait c'est pas la recette magique
et si on revient au truc d'origine
tu dis on disait comment
comment le mettre en oeuvre
donc là tu nous as décrit le scénario
un peu idéal de j'ai un mentor en fait
c'est ça, c'est ça
j'ai un mentor qui me guide
et si j'ai pas de mentor
moi je trouve que j'ai fait ce mentor
j'ai fait avec des livres
j'ai appris avec des bouquins
à la dur ça a été lent
mais j'y suis arrivé comme ça
mais par contre
j'y suis arrivé parce que pour moi
enfin c'est comme ça que je l'analyse rétrospectivement
c'était un nouveau projet
c'est à dire qu'il y a à la fois
il y avait les ingrédients de
on repart de la feuille blanche
et il y avait une énorme détermination
de ma part à le mettre en oeuvre
je suis d'accord
parce que souvent moi je vois des équipes
qui disent ah c'est cool
on démarre un nouveau projet
on redémarre à zéro
cette fois c'est promis on refait plus les mêmes erreurs
et au bout de 3 mois qu'est-ce qu'il se passe
en fait ils sont retombés dans les mêmes écoles
ça marchera pas
oui c'est pas possible
ça marchera pas
c'est comme une équipe de foot
qui est mal formée, qui perd 4 zéro
et elle se dit bon les mecs on commence le match
ça te rend très bien
oui mais tu t'auras toujours le même niveau
tu seras toujours en league 2
alors tu joues qu'on est une équipe
du league des champions
je pense que
contrairement à ce que beaucoup de monde pense
attendre le projet from scratch
pour faire TDD la plus grosse des erreurs en fait
c'est que justement
le meilleur moment pour s'entraîner
à TDD c'est le projet legacy
parce que c'est celui là qui en général
n'a pas de tête c'est à dire qu'on peut pas tomber plus bas
en général c'est celui là justement
qui va t'apprendre à découpler ton code
à découpler tout ce qui est
bundary, donc le base de nez etc
avec des interfaces
on peut pas lui disait bien
tu ne vas pas dépendre des détails d'implémentation
voilà donc
et ça
on l'apprend
avec du code crade
on peut pas démarrer
en pensant
ça y est je vais avoir du code clean dans mon projet
sachant qu'il n'y a pas d'expérience derrière
appartient maintenant c'est un nouveau projet tout va être clean
c'est faux
2 jours après ça va être, on va revenir sur un projet legacy
c'est clarinette
donc pour moi je...
alors imagine le développeur qui a très envie
qui écoute là
un auditeur qui a très envie
qui dit ça a l'air bien
comment il démarre
c'est quoi les principes de bal qui doit s'enfreiner
qui doit s'enfreiner
très simplement
moi je vais avoir pour expliquer ça en une phrase
TDD c'est comme un graphe
à un arbre binaire avec des nez
et il y a des branches en bas
la maîtrise TDD
c'est le nez parent
pour y aller
il faut déjà avoir fait tous les nez enfants
donc dans les branches en fait
c'est à dire il faut qu'il y ait d'abord
qu'il se spécialise d'abord
pendant quelques temps
sur un domaine précis
par exemple ça peut être le nomage
de...
le nomage de variable
il va se focaliser dessus
il va se dire il pousse
moi je prends 2-3 semaines
je vais regarder
ça monte pas sur internet
y a des vidéos donc LeBov d'ailleurs
qui sont super bien sur cleancoders.com
qui s'axent dessus aussi sur les nombres variables
je les conseille à tout le monde
je les ai toutes regardés
y en a peut-être 48 un truc comme ça
j'ai grandi avec en fait
en 2011 j'ai appris TDD grâce à ça
et donc ça ça marche très très bien
cleancoders.com
et donc déjà se focaliser sur
le perfectionnisme
quant au détail
c'est à dire les noms des variables
la taille de ces méthodes
les mini-duplications
des variables temporaires
des choses etc
avoir l'envie déjà de faire
d'être fier de ce qu'on écrit
c'est à dire dans le minimalisme en fait
minimalisme est très propre
une fois qu'on a déjà...
parce que c'est une des étapes
vers TDD
TDD veut être...
enfin...
prendre le minimalisme aussi
donc déjà être sensibilisé
à tout ce soin qu'on apporte au code
tout ce qui est cleancode
ensuite être sensibilisé
à tous les paradigmes de développement
aujourd'hui on a des langages objets
on a des langages procédures
on a des langages fonctionnels
on a des langages fonctionnels
on peut dire
ouais mais j'ai vitré
y en a pas 3 en entreprise
y en a énormément en entreprise
tu fais du front-end
en réacte
y en a énormément
en angular
y a que ça
donc quelqu'un est obligé
de connaître les bases du fonctionnel
il doit savoir c'est quoi le reference chef transparent
si c'est obligatoire
s'il ne s'est pas fait qu'il tape sur Google
pour regarder ce que c'est
c'est hyper important
donc voilà
donc y a plusieurs les clean codes d'un côté
c'est à dire prendre soin de son code
l'autre c'est comment optimiser
le code dont on a pris science
c'est à dire faire émerger les designs paternes
donc apprendre des designs paternes
donc un design paterne c'est quoi
c'est un couple
problème solution
qui est nommé en fait
voilà donc c'est les...
c'est en fait c'est des...
c'est des...
comment expliquer ça
c'est des problématiques qui sont tellement fréquentes
qu'il y a 4 mecs
il y a quelques temps
qui sont mis d'accord
pour mettre des noms là-dessus
et pour montrer la solution
voilà tout simplement
apporter qui peut marcher dans beaucoup de cas
qui est assez générique dans beaucoup de cas
faut connaître tout ça
faut connaître ensuite tout ce qui est
dans les branches
on avait dit les premières étapes
je crois que là y a déjà...
ça prend l'air d'accord
y a déjà un bon démarrage
donc si j'entends ce que tu dis
c'est s'intéresser au base
se focuser
moi j'entends la notion d'être focus
après tu parles de perfectionnisme
je n'aime pas ce mot
parce qu'il renvoie à quelque chose de...
de superfaitatoire, d'inutile, de...
de too much
là ou pour...
ça ne parle pas à la définition qu'on en donne
mais oui
enfin c'est vrai qu'il est toujours perçu de plus négatif
ouais
tu vois y a ce côté là
qui me gêne
parce que après on vient opposer à ça
on vient opposer au perfectionnisme
l'efficacité
ou les trucs comme ça
et alors que pour moi c'est juste
une question de précision en fait
c'est juste une question de précision
d'être focus
c'est vraiment un champ de cicale
et d'être précis en fait
sur ce qu'on fait
et de la précision
n'est l'excellent je pense quelque part
donc je te rejoins complètement
se concentrer quelque...
donc si je récapitule tes conseils
c'est
se concentrer sur les règles de base d'une clean code
à commencer par le nommage de variable
et après s'intéresser au design paterne
alors pourquoi c'est une nommage de variable
alors c'est par exemple par le temps d'autre
d'ailleurs qu'une personne peut dire
qu'elle rapport avec les tests
c'est juste en fait
je pense
le détail
enfin ce qui est considéré comme le plus grand détail
dans le monde du développement
combien de fois j'ai entendu des devs
mais j'ai dit ouais je l'apprécie
c'est de variable table
c'est un tableau
je vais dire non mais
mais là appelle là normalement
non mais ça marche
pourquoi je l'en amourais
c'est bon on a compris table c'est un tableau
voilà et donc en fait tout ce qui est
vraiment mi de côté négliger par les gens
s'intéresser à ça
ça va... ça va...
donc c'est pour ça que c'est déjà allé
vers ce qu'on considère vraiment
comme un déchet
comme quelque chose de pas du tout utile
c'est à dire le nomage de variable
pour ensuite apprendre à aimer le détail
parce que t'aider justement
on va se regarder que sur le détail
faut apprendre à aimer
c'est pour ça que j'appelle ça perfectionnis
parce que perfectionnis c'est
il n'y a pas genre je m'occupe de ça
et tout ce qui est aux alentours
c'est pas grave
c'est la périphérie
tout est important
voilà
et tout est important
et tout a son rôle
tout est au premier plan
donc même le nomage de variable
est important
et moi tu vois quand tu me dis ça
ça me fait penser
les maîtres Sushi
la première année
un apprenti maître Sushi
il passe les 12 premiers mois de sa vie
à faire cuire du riz
et uniquement à faire cuire du riz
et il est focus
et il est focus sur ça
parce qu'en fait le riz
ça a l'air de rien
mais dans un Sushi
ça va conditionner
énormément le goût
du Sushi final
au-delà du poisson
et pour moi je te rejoins complètement
que ce soit le nomage de variable
le nomage de méthode
le nomage de classe
c'est le riz
c'est le riz de ton Sushi
c'est-à-dire que
si il n'y a pas ça
si tu ne sais pas le maîtriser
ça n'aura pas bon goût au final
en fait
c'est ça
pourquoi je parle surtout de nomage de variable
parce que dans TLD
ce qu'il y aura c'est surtout des notions abstraites
comme des interfaces
et compagnies contre mon Java
ou dans notre langage similaire
etc
il faut savoir les nomer ces trucs-là
il faut savoir les faire découvrir
parce que TLD est une solution
une design
je ne rappelle pas de test
donc c'est vraiment du design
c'est une technique
qui par l'intermédiaire
de tringuerie de test
va te permettre de faire émerger ton code
donc le but du jeu
c'est de pouvoir donner du sens à ton code
parce que sinon pour le faire émerger
il faut donner du sens
donc il faut penser en termes de rôle
une interface aura un rôle
donc vraiment c'est
quelque chose qui est mangeable
ça va l'appeler itable par exemple
tu vois c'est
donc il faut apprendre le soin
de nommer les choses
d'apprendre à imager les choses
à les nommer
et des fois même avec créativité
j'avais fait un poste qui n'a pas fait longtemps
où il y avait quelqu'un
le but du jeu de l'innocent
en une phrase c'était
il y a des tondeux dans le jardin
elles sont pilotées par une télécommande
il faut que elles puissent tomber
tout le jardin
et donc clairement la classe maître
on va dire la classe main
juste ensuite la classe main
la plupart des développeurs
qui avaient éco-destruct là
il avait appelé programme
programme
mais c'est très générique
c'est très robotisé
parce qu'ils sont dans le monde
électrique, tondeux etc
ils ont dit bon c'est un programme
non mais en fait
ils essaient d'être plus imagiques que ça
en fait c'est quoi le job
ils essaient d'automne les écois
c'est un jardini en fait
je vais nommer la classe principale
gardeneur c'est un jardinier
et lui il active les tondeuses
et c'est plus sympa de voir
le gardeneur 2.0
qui au final est des tondeuses automatisées
plutôt que de voir un nom
qui s'appelle programme
voilà et donc en fait
c'est ça en fait que j'appelle
le nommage de variable
c'est vraiment se concentrer
sur la créativité dans les noms
et c'est ça qui va donner envie
déjà aux développeurs
d'entraîner dans la compréhension
on comprend très vite
plutôt que d'avoir
un déclat qui s'appelle
Toto, Tata et une variable A et B
je préfère avoir des noms vraiment explicites
et voir même marrant des fois
qui amènent à vraiment
prendre soin de ce code
et ça donne plaisir
c'est ça qui va la passion du code
c'est vraiment tout ce côté créatif en fait
et ça commence par le nommage de variable
après par le nommage de Toto et etc
et ça...
écoute Miguel je te propose
que ce soit le mot de la fin merci
pas de soucis
merci
les auditeurs va l'en savoir plus
ils peuvent venir où
pour regarder ton travail, ton profil
ce que tu fais
alors moi je suis très présent
sur LinkedIn aussi
donc Michael Azera
puis j'ai aussi monté ma propre boîte
qui se consacre à la réalisation
de projets au forfait
et aussi du coaching CraftMatch
donc en fait ce que je fais
c'est que je prends des projets de divers clients
que ce soit des grands groupes
ou des startups pour l'autre
et je les réalise à la source
CraftMatch pure et dur
au sein de mes locaux
avec un coup bien préfixé
à l'avance etc
vraiment aucune surprise
et avec une garantie
de 0 bug à la sortie
et c'est quoi que tu as de ton site ?
alors c'est Wilcomcompany.com
donc c'est Wilcom W E A L C O M E
Compagnie Collet donc Compagnie en anglais
point com
eh bah écoute super
je mettrai les liens dans la description
et je tiens merci d'être venu
ça marche
merci Benan
merci beaucoup
et en tatouage à l'auditeur
j'espère que tu apprécies le podcast
si ça fait du sens pour toi
et si tu es envie de creuser
justement
ça tombe bien
parce que les questions de design
et notamment de
comment commencer à démarrer
son processus d'amélioration
et c'est quoi les premiers principes
qu'on va pouvoir mettre en œuvre
sur du code legacy
ben justement c'est le coeur de la formation
que je viens de publier
dans la maison des compagnons
que je t'invite à rejoindre
sur artisandeveloper.fr
je te remercie et je te dis à demain
Episode suivant:
Les infos glanées
ArtisanDéveloppeur
Artisan Développeur est un podcast destiné aux développeurs qui veulent bâtir une carrière épanouissante. Hébergé par Ausha. Visitez ausha.co/fr/politique-de-confidentialite pour plus d'informations.
Tags
Card title
[{'term': 'Technology', 'label': None, 'scheme': None}, {'term': 'Technology', 'label': None, 'scheme': 'http://www.itunes.com/'}]
Go somewhere
Les 12 Facteurs De Scalabilité Avec Christophe Chaudier