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 Vénor.
Je te propose aujourd'hui qu'on parle, en fait c'est même toi qui vient de me le proposer,
ça me va très bien, de comment transmettre le craftmanship, en fait,
comment transmettre dans un point de vue très concret, comment ça marche en fait,
quand un maître et un apprenti travaillent ensemble.
Dès les mots de maître et apprenti, tu peux mettre les termes que tu veux,
moi c'est ceux que j'utilise.
Tu me parlais de ton expérience avec un collègue que tu avais formé pendant un an.
Moi aussi, plusieurs reprises, j'ai cherché à transmettre ça de plein de manière.
Je suis vraiment curé qu'on échange de la suicide, c'est ok ?
Ouais, pas de soucis.
Justement, vas-y, je te laisse démarrer, comment est-ce que,
dans le point de vue très concret, ça fonctionnait pour toi avec ton binôme ?
Alors déjà, très simplement, en général, j'étais taquillé de cette personne dans un grand groupe.
Donc déjà, très simplement, moi, en général, quand je commence,
déjà avant de parler technique, j'essayais vraiment de sympathiser avec les personnes.
Il n'y a pas de notion de hiérarchie ou autre, parce que je suis taquillé,
tu es dans un monde, c'est vraiment sympathisé, humour, on mange ensemble, etc.
Et puis à peu on discute, on arrive dans le métier, on discute, etc.
Et donc au fur et à mesure, on avait des tâches qui s'imposaient,
contexte agile, grand groupe, etc.
On avait des tâches qui s'imposaient.
Et tout de suite, on avait forcément les poker planning,
et à partir de là, les gens chiffraient, etc.
Donc cette personne chiffrait.
Et à un moment donné, elle chiffrait, et j'étais très étonné du chiffrage.
Et je me suis dit, sincèrement, soit tu es une fusée spatiale et dans ce cas-là, chapeau,
mais là, tu oublies plein de choses.
Dans ma tête, je me disais ça.
Et donc au final, en discutant avec elle, comment je m'y prenais ?
Pour une tâche, avant de la commencer, avant de la signer, forcément, etc.,
on allait sur un tableau blanc.
On prenait une salle de réunion, tableau blanc.
Et je prenais cette personne et je lui dis, donc on va prendre ta tâche,
qu'on est censé t'assigner.
Maintenant, tu vas m'expliquer comment tu la vois.
Qu'est-ce que tu imagines ?
Je sais que t'as pas vu le code encore.
Je sais que tu viens d'arriver.
Je sais que tout.
Mais comment tu imagines la chose ?
Comment tu es dans tes précédents projets pour faire une tâche similaire ?
Et là, il va commencer à dessiner en fait des choses,
au marqueur, vraiment, c'est un tableau blanc, etc.
Et on va commencer à discuter des concepts.
Et on va commencer à discuter des oublies,
de là où il a oublié de gérer,
des pratiques différentes, etc.
Donc au moment où vraiment, on va faire craftsmanship.
Alors je sais pas si tout le monde fait comme ça,
je ne sais pas vraiment toi,
est-ce que tu prends comme ça Benoît quand t'es entre Ymer et Apprenti.
Mais moi, je trouve ça bien.
Un mot là-dessus, si tu vois.
Ah ouais, alors avant de réagir sur ça, ça m'intéresse.
Quand tu disais, on dessinait des choses concrètement,
si je voyais le tableau, c'est quoi ?
Tu dessinais des concepts, tu dessinais des classes,
tu dessinais, ça ressemble plus d'un diagramme d'interaction,
plutôt un diagramme de classe.
Alors c'était un diagramme très macro.
C'est-à-dire qu'il n'y a même pas de diagramme de classe.
C'est un autre sujet, mais avec TLD,
il n'y a pas de diagramme de classe
parce que les classes, je les découvre en même temps.
C'est plus en amont, c'est plus UML d'avant.
C'est une autre façon de faire.
C'est un autre sujet.
Donc là, l'idée c'est...
Attends, je vais juste découper parce que là,
pour moi, UML,
UML n'est que le langage qui permet d'exprimer les choses.
Après, il y a le design, le processus,
qui est avec, et le final procès.
Globalement, les gens vont faire quand même les carré
avec des méthodes en intérieur.
J'ai vu.
Donc au final, ça apparence quand même à une sorte de UML.
L'idée, c'est vraiment de ne pas parler méthode,
c'est de parler vraiment le flux, en fait.
Et surtout des concepts.
Ça, tu dois gérer ça.
C'est tout bon.
C'est vraiment avec des flèches, avec des liens entre...
Ok, donc il n'y avait pas de formalisme précis pour quoi ?
Aucun formalisme.
Ce n'est pas le but.
Le but, c'est déjà de voir ce qu'il a dans le cerveau.
C'est voir qu'est-ce qu'il imagine, comment s'il prend.
Après, évidemment, on descend au fur et à mesure.
Mais d'abord, comment tu t'y prends ?
Voilà, je dois créer une réunion.
C'était une application de gestion de réunion, par exemple, un exemple.
Comment tu t'y prends pour créer la réunion ?
Tu dois faire le front et le back.
Tu fais quoi ? Qu'est-ce qui se passe ?
Tu t'y prends comment ?
Par quoi tu commences ?
Voilà, c'est toutes les premières questions.
Et donc après, évidemment, cette personne était plus back au début.
Donc après, elle est devenue front, je vais faire le mot aussi au front,
mais maintenant plus back au début.
Donc elle s'intéresse à toute la partie logique.
Je lui ai dit, d'accord,
quelle règle de gestion tu vois là-dedans ?
Qu'est-ce qu'il faut gérer ?
Donc là, elle m'écrivait au tableau toutes les règles de gestion.
D'abord.
Donc déjà, c'est pour ça qu'on veut dire que le craftmanship commence d'abord
par une analyse, un peu comme cher médecin.
Il fait une analyse globale du truc.
Après, il parle de ce qu'elle a à personne.
Un scanner global pour voir déjà,
est-ce qu'on parle de la même chose
et est-ce qu'on va penser au niveau des mêmes concepts.

Je ne sais pas si toi, t'abords,
de la même chose en général,
quand tu vas essayer de transmettre le craftmanship.
Mais moi, j'aime bien, en fait, partir près de toi.
En fait, là, ce que tu évoques pour moi,
c'est plus...
C'est pas tellement forcément une manière de transmettre,
c'est juste le process normal
où je vais réfléchir à mon analyse
avant de me lancer.
Le fait qu'elle soit faite à plusieurs,
je pense à beaucoup de valeurs.
J'ai pas forcément eu l'occasion,
par le passé, moi, de partager beaucoup ces trucs-là.
Quand je réfléchis à comment j'arrivais à transmettre,
d'abord, je dois faire un constat,
c'est que c'est dur à transmettre.
Je ne vais pas confaronner.
Et plusieurs manières avec une équipe remote,
ce que je faisais, c'est que je leur écrivais les tests
et eux écrivaient le code.
En fait, petit à petit,
au début, ils me commentaient les tests.
C'est sûr que la barre, elle passait verte.
Ils m'ont commenté les assertions
parce que ça les déchirait ce truc.
C'est rigolo, ça veut dire qu'ils les percevaient comme un bug.
Là, je me suis dit, oh là là,
il faut leur sortir les rames parce que ça va devenir...
On part de loin.
Au final, franchement, au bout de 2-3 ans,
ils avaient compris le concept
et après, eux étaient capables,
finalement, à force de voir des tests écrits,
ils étaient capables d'en écrire.
Et je crois que le plus efficace, sinon,
c'est par le binommage.
Mais il manque un truc à ça.
Je t'enjouis en là-dessus, mais en fait,
il y a une étape qui est sautée importante.
Avant d'apprendre le craftmanship
et d'apprendre les bonnes pratiques,
il faut reconnaître les mauvaises pratiques.
Donc le fait de le prendre sur un tableau blanc
et de lui montrer les sages,
je veux qu'ils, de manière consciente,
avec un Vélida, etc.,
ils prennent, à partir d'une discussion, évidemment,
ils prennent conscience de la mauvaise pratique
qu'il avait et d'essayer, justement,
par cette mauvaise pratique de me dire
« mais Mikael, d'accord, mais on fait comment ? »
Est-ce que t'as un exemple concret ?
Est-ce que j'ai un exemple concret ?
J'ai un exemple concret.
J'ai réflécié à ça.
Moi, la première tâche que j'ai demandé
à cette personne-là,
j'essayais de lui donner une tâche,
en tant que tech-leaf de la CIS sympathique,
je voulais lui donner une des meilleures tâches.
Donc moi, j'étais prêt à apprendre les tâches un peu moins
vraiment épanouissantes.
Et je lui ai dit, voilà,
tu vas me créer un framework de mail.
On va créer, parce qu'on a le genre de library de mail
dans l'application, c'est un peu tout le coeur de l'application,
il va falloir créer un algorithme de gestion de mail
assez générique,
que tu peux gérer pas mal de styles de mail, etc.,
de façon envoyée, etc., de manière générique.
C'est un vrai algo d'algorithmie,
un vrai exercice d'algorithmie.
Et je lui ai dit, voilà,
tu vas étudier ça une journée,
tu demandes en en parle, au tableau blanc,
et tu me dis comment tu vois la chose.
La personne disait, oui, pas de soucis.
En fait, voilà, j'ai mon mail sender,
j'appelle, j'ai le library, regarde,
je vais ma mail, avec java mail, j'appelle,
et hop, ça marche.
Et je lui dis, d'accord,
et comment tu testes ça ?
J'ai mon test d'intégration,
et puis voilà, je lance,
je vois qu'il y a un mail qui passe,
et voilà.
Et d'après toi combien de temps
on va durer ce test d'intégration
à s'exécuter ?
C'est rapide, je sais pas,
une minute, deux minutes,
et est-ce que ça, c'est rapide ?
Il me dit, oui, et je lui dis non.
Moi, je veux que ça dure deux secondes.
Comment faire que ça dure deux secondes ?
Et à partir de là, je lui ai expliqué
qu'il fallait découpler tout ce qui était
appliqué de java mail,
par rapport à ton algorithme
d'orchestration des mails,
qui a rien à voir, en fait,
et qui lui, pourtant, est le coeur.
Donc, à partir de là,
le premier concept en craft magic
que je vais montrer,
c'était comment
le separation of concerns.
C'est exactement ça le terme,
donc separation of concerns,
c'est vraiment séparer les concepts.
D'un côté, t'as le concept
qui lui est l'envoyeur de mail,
c'est l'implémentation technique,
c'est java mail,
c'est la librairie java
qui va te permettre de faire ça.
De l'autre côté,
t'as notre personnalisation custom
d'algorithmes.
Comment envoyer un mail,
quand le faire,
avec quelle donnée,
avec quel truc, etc.
Mais on parle de mail,
pas au sens email,
c'est une donnée,
c'est mail au sens courrier.
Ça peut être un premier SMS,
ça peut être voilà.
Donc je lui ai expliqué,
première partie du craft man-cheap,
c'est vraiment apprendre déjà
à différencier les différents concepts
dans une tâche,
dans une US,
quels sont les concepts ?
Il y a des concepts,
des fois, c'est plus du design,
des fois, c'est plus
une implementation technique,
des fois, c'est plus
de configuration,
d'injection de dépendance,
des fois, comment différencier tout ça ?
C'était le premier tâche qu'on avait.
Et donc par le biais du tableau blanc,
il permettait de...
qui voit son erreur,
qui voit cette flèche
qui m'a écrite
entre l'orchestration
et direct java mail,
qui voit qu'il a couplé tout en même temps
et qu'il comprenne les erreurs.
Voilà, c'était un petit peu ça.
Donc je sais pas ce que t'en penses,
mais ce tableau blanc
permet justement de voir la flèche
et cette liaison qui casse
en fait ces séparations de conserves,
qui mettent tout à la fois
et qui va mener vers un mauvais design
très rapidement.

Et...
Bah je trouve ton exemple
doublement parlant,
c'est-à-dire doublement parlant
parce que tu es arrivé
à exprimer d'abord au tableau
les choses,
qui à mon avis
permet
une meilleure interaction
que sur du code
qui va être potentiellement
un peu long à écrire.
La vitelique proco, surtout.
C'est ça.
On parle d'ailleurs.
Et le deuxième point
que je trouve très intéressant,
c'est que finalement
on en arrive très vite
à ce qui est pour moi
un des premiers principes
et c'est d'ailleurs un des premiers principes
que j'aborde
qui est l'injection de dépendance.
Comment découpler
via l'injection en fait.
C'est ça.
Et c'est intéressant.
C'est la base de l'injection.
Tout ce découplage c'est la base.
La base,
oui.
La base c'est lutter contre le couplage.
C'est-à-dire que pendant très longtemps
moi j'ai lutter contre
le terme
« méchap »
quand tu as deux fois la même chose.
La duplication.
La duplication.
Pour moi la duplication
est la mère de tous les mots.

Et au fur et à mesure
ces dernières années
je prends conscience
que si la duplication
ça reste le number one
et sous toutes ses formes
le couplage.
C'est pire le couplage.
C'est le pire que tout.
Et vraiment l'ennemi
en fait c'est un ennemi
qui serpente
parce que tu ne le vois pas.
C'est ce que tu vois
dans cet exercice
que tu as eu.
Oui.
Le mec
était en train de commencer
à construire un couplage
hyper fort.
Ah oui.
Il s'en rendait pas compte.
Il s'en rendait même pas compte.
Complètement.
Non, pour lui c'était normal.
Il me disait
« je faisais ça dans mes anciennes missions ? »
Oui.
Et donc mon but à moi
c'était de lui montrer
avec du code
en pire programming
sa façon de faire.
On la faisait ensemble en même temps.
On prenait une demi-heure
on la faisait.
Et je lui dis voilà
maintenant dis-moi où est le problème.
On regarde, on regarde
il ne le trouvait pas
et je lui dis regarde ça.
Et là, direct,
je lui fais quelque chose
et elle me dit putain,
ouais, ah ouais.
Là je commence à voir le truc.
Ouais, ouais je comprends.
Et ça fait plaisir.
Il me fait un décès tout le temps en fait.
Pour commencer à évoluer là-dedans
il faut avoir des errequarts.
C'est-à-dire se dire
« ah mais en fait je le voyais pas
mais là c'est concret, ah ouais
je vois l'erreur.
Je comprends ce que tu veux dire Miguel.
»
Voilà les phrases qu'il disait.
Et j'adorais ce mec là
parce qu'il comprenait super vite.
Ça ça aidait énormément.
Quand je disais un truc
je ne le répétait pas 2-3 fois
il avait absorbé.
Et donc du coup
son but à lui
c'était plutôt de me challenger.
Il me dit
« t'es sûr de ça ?
Mais regarde, mais si on fait ça
et pas qu'il avait la réponse derrière.

Et lui ça le sécurisait.
Il se dit
« putain il a quand même réponse à tout.
Ça doit être assez sympa.
Je vais tenter sa façon de faire.
»
Et donc voilà.
Donc le but du jeu
je pense que ça va être une erreur de dire
« voilà je vais t'mâcher le travail.
Je vais te dire comment faire quoi etc.
Maintenant fais-le.
»
Le mec ne se rendra jamais compte.
Il pourra même pas le faire.
Il ne sera pas autonome plus tard.
Si on lui mâche le travail
il faut qu'il s'en rende compte.
Il faut qu'il devine
« jamais je lui ai donné la solution rapidement.
Je vais toujours d'abord fait travailler.
Et si vraiment il ne savait pas
qu'il avait montré un effort
là je lui montrerai la solution.
Est-ce que ça faisait perdre du temps ?
Non au début.
Parce que forcément
si je voyais que le délai était
on se rapprochait des délais
je prenais sur moi de faire la tâche.
Mais au moins il aura pris plein de choses.
Et plus tard
il sera plus à l'aise dans la prochaine tâche
etc.
Donc voilà.
Être mentor de craftmanship
c'est aussi prendre les choses pour soi
et prendre plus de travail aussi pour soi
s'il le faut
pour donner cette opportunité au mec de se former.
Avec l'auteur merci
je propose que ce soit le mot de la fin.
Ça marche.
Pas de soucis.
Si les auditeurs ont envie d'en savoir plus
sur ce que tu fais
ils peuvent venir où Mickael ?
Alors ils peuvent venir
sur mon LinkedIn
où je poste pas mal
sur l'actualité du craftmanship
et sur
pour les personnes intéressées
par la rédaction de projets
ou carrément des boîtes
qui sont intéressées par du coaching craftmanship
où j'enseigne vraiment
à des personnes justement
à être passionnées du code
et surtout
maîtriser pas mal de pratiques
comme t'as joué bien développement
l'exagulation architecture etc.
Ils peuvent venir sur www.willcomecompagnie.com
donc www.eale.com.com
en anglais.com
où je détaille exactement ce que je fais
avec un mail de contact
si jamais vous voulez me contacter
et voilà j'en fais mon métier pur et dur
et je serai ravi d'avoir
vos écrits.
Ça marche.
Merci encore d'être venu.
Merci Benoît.
Quant à toi cher auditeur
j'espère que t'as kiffé ce podcast
si c'est pas déjà fait rejoins nous
sur artisandevelopers.fr
rejoins la communauté des développeurs passionnés
je te dis à demain.