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 Azerat. Michael, bonjour.
Bonjour, Benan.
Je te propose aujourd'hui qu'on partage sur la transmission de la passion du code
et comment transmettre les bonnes pratiques.
Tu me racontais des anecdotes sur certains cas que je trouve super intéressants.
J'ai envie de commencer l'épisode en partageant une et je pense que ça va t'inspirer.
Il n'y a pas longtemps, j'accompagnais une équipe avec un gars très branché dans les approches King Code.
Il me racontait que son premier comite, il a amené un truc, il avait fait un super réfacto,
il était super fier de son truc, sauf que, quand il a poussé sur develop,
au moment de passer sur Master, les mecs ont juste fait un énorme rollback sur tout ce qu'il avait fait.
Comment ça te fait réagir ?
Pour l'avoir vécu environ 10 000 ou 11 000 fois, je les comprends.
C'est-à-dire que je les comprends et finalement, au début, on sent tête, on est frustrés, etc.
et finalement, quand on réfléchit, on se dit qu'ils ont raison.
Ils ont raison parce qu'en fait, ce n'est pas le bon contexte pour le faire souvent,
surtout dans les grands groupes, ce n'est pas du tout le bon contexte.
J'explique pourquoi. Moi, j'ai été par contre dans une émission passée, donc c'est en frilance,
mais c'est même délire, c'est pareil.
Dans une émission passée, c'était le monde web, ok ?
On était donc avec Angular 2 et Compagnie et tout ce qu'il va avec, etc.
Mais on ne codait pas en classe. Il n'y avait pas de code en classe, ça n'existe pas.
Alors que le S6 est Compagnie, le but du jeu, c'est de coder en objet et de Compagnie.
Premier réfacto, je prends toute ma tâche, je mets tout en classe.
Avec les tests, attention, on tédé des compagnie, tout marche, tout fonctionne,
j'assure le truc pleinement.
J'envoie le code review.
J'envoie le code review, j'étais pas tête-lide à cette époque.
D'ailleurs, tout le mal que je me souhaite, c'était ça.
Et donc au final, ça a été refusé.
Mickael, je ne comprends pas. T'as touché tous les fichiers.
Moi, je prends pas ce code.
La réponse, elle est très simple, en fait.
C'est que le projet était déjà à moitié sous l'eau.
On ne parle pas d'un projet qui est clean et on essaie encore de faire mieux.
C'est un projet qui était déjà sous l'eau.
Et ce qui est remonté, en fait, c'était qu'il y avait trop d'anneaux déjà sur Gira et compagnie
et qu'on ne pouvait pas se permettre de tomber plus bas.
Les anneaux, elles revenaient tellement qu'elles étaient hyper connues du grand public.
Des autres collègues, etc. Elles étaient super connues.
Si on vient et qu'on leur change la source de données qui étaient potentiellement déjà buguées,
potentiellement avec des bugs, mais eux ne le savent pas, ils pensent ça.
Là, ils se disent, d'accord, on n'a plus la maîtrise du tout. Là, on est mort.
On a fait du code crade, on le sait tous.
Mais au moins, on sait ce qu'on a fait.
Et on sait comment on a mis nos fixes. On sait comment on a fait nos trucs.
Si toi tu viens et tu nous sors un diamant, c'est plus notre code, on ne le trouverait plus.
Et c'est même pire que ça, c'est qu'on ne comprend même pas.
Alors, on n'est pas formés sur les classes. Nous, ça fait trois ans qu'on est dans cette boîte,
on ne fait que du code sans classe et compagnie.
Là, tu arrives et tu fais des méthodes, des objets et de l'héritage des compagnie, on est largué.
Donc, en fait, ici, ils ont dit, ils ont dit, écoutez, c'est très bien ce que tu fais.
On ne dit pas que c'est mauvais, etc. Mais ce n'est pas le moment.
Ce n'est pas le moment. On est sous l'eau, on a 350 ans sur Gira.
On ne peut pas se le permettre.
Et donc, en fait, il y a deux choix quand tu es perfectionniste, comme je l'étais.
C'est soit tu quittes la mission et tu expliques pourquoi,
tu expliques que tu n'as pas à ça tout simplement.
Et que tu dis, moi, j'ai pour vocation d'essayer d'améliorer les choses.
Si je vois qu'en fait, ce n'est pas possible,
tchao, mais vraiment, d'un bon accord.
Sinon, on se tue aux règles.
Mais à ce moment-là, il faut assumer.
On voyait un code pourri.
Il faut assumer, ne pas pratiquer ce que l'on lit dans les boucs.
Il faut assumer avoir une dette non pas technique, mais une dette d'apprentissage.
Parce que dans 3 ans, tu changes de mission.
Ben bonjour.
Il faut avoir l'habitude, en fait, de bien suivre le mouvement
pour ensuite être capable de le suivre dans une autre boîte,
qui elle peut-être ferait des classes.
Et est-ce que tu crois qu'il n'y a pas une troisième voie qui est de...
Parce que dans les deux voies que tu exposes,
il y a l'impression que c'est des choix sépinaires.
Soit je démissionne et je me casse.
Parce que c'est intolérable.
Soit je tolère une situation qui ne me convient pas.
Comment est-ce qu'on peut faire pour rester dedans ?
Parce que quand même, il y a des fois où le projet et le contexte
font qu'on a envie de rester.
Et faire bouger les choses, même si c'est plus lent que ce qu'on aimerait.
Alors, c'est ça.
Alors pour moi, ce qui a du sens pour essayer de former, etc.,
ce ne sera jamais dans l'étape correction de Doug.
C'est-à-dire si on réfactore un code existant
pour montrer la bonne pratique
et essayer de prouver une méthode de clean coding
par infactoring d'un code legacy,
c'est la hyper mauvaise approche.
Ce qu'il faut faire, c'est essayer de se débrouiller.
Je parle dans le cas où on n'est pas TechLead.
Quand on est TechLead, là, c'est nous le roi.
On est responsable de tout ce qu'on fait
dans ce cas-là avec infactoring partout.
Mais quand on n'est pas TechLead et que la demande ne passe pas très bien,
l'idéal, en fait, c'est d'essayer de négocier pour faire des nouvelles US.
Il y a toujours un moment dans un projet où il y a des nouvelles features,
j'espère bien.
Et à ce moment-là, là, on le forme
et on le clean de la manière la plus optimale qu'il soit
pour évangéliser la bonne approche.
Il n'y aura pas de risque parce que personne ne connaît ces codes avant.
Il est tout neuf.
Donc il n'y a pas de...
Ouais, mais attends, là tu nous casses un code
que j'ai fait il y a deux ans.
Et celui il y a deux ans, moi je le connais.
Là, tu me la réfactaurais.
C'est plus mon code.
Je ne sais plus ce que c'est.
Si demain toi, tu pars tes frilances.
Demain, il y a un bug.
Il n'y a que toi qui le connais.
Voilà, c'est pas content.
C'est un nouveau truc.
From scratch, un petit module dans l'appli.
Là, j'ai pu le constater.
Les gens le prennent et vraiment s'intéressent.
Et ça, ils vraiment de comprendre, de lire le code, etc.
Et ils se disent souvent, il y a des bonnes surprises.
Ah mais en fait, c'est vrai.
Putain, c'est simple.
Ah ouais, t'as fait en trois lignes que je fais en 150 lignes.
Ah mais c'est pas mal.
Et t'as réutilisé ça en plus.
Ah mais c'est cool.
Ah tiens, je ne connais pas ce concept.
C'est quoi ?
Ah, ça s'appelle CQS.
Tiens, c'est sympa.
Et là, là, il y a une description qui peut se faire.
Donc moi, ma réelle, en fait, c'est ça.
Au lieu d'être binaire, tu quittes ou tu restes,
ou t'assumes, c'est à les deux.
Entre les deux, je dirais essayer de négocier
pour prouver les approches qu'une coding est compagnie
à des gens qui ne connaissent pas
ou qui ont de mauvais préjugés là-dessus
sur des nouvelles features,
sur un petit code from scratch
qui pourrait les sensibiliser.
Je vois la chose comme ça.
Ok.
Le truc, c'est que parfois,
parfois, c'est compliqué de faire ça.
Moi, ce que je constate, c'est que
quand t'es embarqué dans un projet,
il y a une notion de cohérence
à avoir sur le code, je trouve en tout cas.
Et puis, il y a même des fois où ça,
j'ai vu des cas où finalement,
pour pouvoir faire un truc propre,
même sur du nouveau,
tu tires une des, tu tires assez rapidement
une espèce de pelote de laine,
où tu crois que tu vas prendre 10 cm de fil
et en fait, tu embarques vite fait tout de la pelote, quoi.
C'est ça.
C'est pour ça qu'il faut essayer
de jouer avec des solutions de façade,
d'interface, etc.
Faut masquer en fait le code legacy,
comme si on confie un petit peu de autour.
Tu fais une façade pour l'encapsuler
et le mettre à part, quoi.
Tu lui définis un périmètre...
Exactement.
Je peux détailler l'implémentation,
c'est le code legacy.
Et je joue avec les interfaces et compagnies
pour essayer de reconstruire la chose
et de manière clean.

Après,
ce qu'il faut savoir, c'est qu'on dit
qu'il y a une cohérence du code,
dans les grands groupes en tout cas,
ça n'existe pas.
Tout simplement pour la bonne raison
qu'il y a un interne ouvert très actif.
Les développeurs en tous les niveaux
complètement disparaissent.
Il y en a qui sont très bons,
il y en a qui sont hyper mauvais, ultra mauvais.
Chacun a son code, son style, etc.
Je doute en fait que quand une personne arrive
sur une appli qui fait 2 millions de lignes
et se disent, vous savez quoi, avant de coder,
je vais déjà étudier l'harmonie du code
pour essayer de m'en imprégner et faire pareil.
Personne ne sait ça, ça n'existe pas.
Donc au final, chacun va apporter son style,
un peu comme au foot, dans une équipe de foot,
tu as le dribbler, tu as le passeur,
on va apporter son style
et dans ce cas-là, ça va forcément casser une cohérence.
La cohérence dans des gros projets,
pour moi, elle n'existe pas.
Par contre, avec du refactoring,
si toute l'équipe s'y met, si l'équipe est durable
et compagnie, ou même les nouveaux,
s'ils sont aussi formés sur la pratique,
là on peut amener la cohérence au fur et à mesure
de la faire émerger.
Mais sinon, la cohérence dans un projet,
je n'y crois pas trop,
à partir du moment où c'est un projet d'envergure
et qui date.
J'y crois pas trop.
Ça n'existe pas, en fait.
Je suis obligé de reconnaître
que je suis assez d'accord avec toi sur ce point-là.
C'est gentil.
Je te remercie, Miquel, d'être venu.
Je te propose que ce soit le mot de la fin.
Avec plaisir.
Donc voilà.
Comme vous l'avez vu,
le refactoring,
vous le savez,
ce qui me connaît,
c'est une des notions les plus importantes
dans un projet.
Je suis complètement pour,
même des gros refactoring,
du moment qu'il y a,
vous savez très bien des tests.
Ça pourra embrayer peut-être
sur un prochain épisode
qui parle de TDD.
Mais voilà,
c'est une passion pour moi.
Je fais pas mal de vidéos là-dessus
aussi sur YouTube.
Vraiment,
je vous conseille vraiment
de lire des bouquins
sur le refactoring,
sur le design.
Un livre,
c'est super design pattern,
par exemple,
qui reprend beaucoup de notions,
pas que design pattern, etc.
Qui vont vous permettre
de progresser dans le milieu
et surtout de prouver
à vos managers
et vos chefs
que vous êtes dans l'ouvret
et que vous avez quelque chose
à leur apporter.

Encore merci, Michel.
Merci, mais non.
Quand t'as toi, cher auditeur,
bah écoute,
je t'invite à venir partager
la passion du code
sur artisandeveloper.fr
et t'inscrire
si c'est pas déjà fait.
Je te remercie,
je te dis à demain.