Alexandre Petit

Spaghetti to Bento #1 - Nicolas Carlo - Transférer 30 ans de connaissance en 2 mois

Invité : Nicolas Carlo

Thèmes :

Ressources évoquées :

L'épisode

Transcription

Nicolas

Hello, ça va ?

Alexandre

Hey !

Salut Nicolas !

Merci d'avoir accepté mon invitation et bienvenue dans ce tout premier épisode de Spaghetti to Bento, le podcast de Refactoring.

Nicolas

Oui. C'est un nouveau podcast que tu vas lancer c'est ça ?

Alexandre

Oui. Tu es mon premier invité et je suis trop content.

Nicolas

Je suis honoré. C'est intéressant.

Alexandre

Comme je te disais, quand je pense à Refactoring ou Legacy, je pense direct à toi. Tu es un peu "le mec qui écrit sur le Legacy".

Nicolas

Oui. C'est un sujet que j'ai pas mal pensé. Il y a tellement encore de choses à voir, mais je me suis un peu spécialisé là-dedans.

C'est particulier parce que c'est une communauté où d'un côté je trouve qu'il n'y a pas assez de ressources. Quand tu vois par exemple sur React, tu as tellement de communautés, de gens, d'influenceurs et tout. Sur le legacy code, il n'y pas autant de ressources. Mais il y a quand même des gens qui se spécialisent là-dedans. C'est juste qu'en général, ils sont plutôt anglophones.

Alexandre

C'est un truc que je me suis demandé oui. J'ai envie de creuser le sujet, lancer un podcast en français : est-ce que je vais trouver beaucoup d'invités en français ? C'est pas sûr.

Nicolas

Après je peux te suggérer quelques noms. Il y a une belle communauté craft en France et ça se déploie dans les pays francophones. Je pense que tu trouveras quand même des gens. C'est sûr que tu n'as pas un bassin aussi vaste que le monde entier si tu fais ça en français. Mais je suis certain que tu arriveras à trouver des amis.

Alexandre

Ok. Je vais commencer en français puis je verrai, peut-être que je basculerai en anglais à un moment donné.

Nicolas

Oui, c'est ça. Et puis tu verras au fur et à mesure, avec les feedbacks, dans quelle direction tu veux aller. Y'a un autre podcast en français. Ils font des épisodes régulièrement et ça fait au moins un an maintenant. Adrien Joly et Jérémie Girault. Adrien Joly, c'est quelqu'un qui a fait de présentations sur tout ce qui Legacy, Refactoring. Oui c'est ça le SAV de la tech. Ils en sont à 31 épisodes. Donc écoute, podcast en français sur les pratiques de développement.

Alexandre

Génial, je vais creuser après l'échange.

Sur ce podcast, l'idée c'est de :

  1. comprendre le marché, l'écosystème du legacy/refactoring
  2. découvrir les techniques
  3. et puis se rencontrer, passer un moment sympa

Si ça te va :

Nicolas

Aller.

Alexandre

Du coup :

J'ai lu que tu fias 12 000 impressions par mois.

Nicolas

Je t'avoue que je ne suis pas trop les stats. Je ne sais même pas si j'ai mis des analytics sur le site. Au début j'ai dû en mettre, puis à un moment donné je me suis dit, euh... J'suis pas en train de faire ça pour suivre des indicateurs... C'est pas un business. Et du coup je ne voulais pas me prendre la tête avec ça. C'est plus un blog.

Alexandre

C'est une vanity metric ?

Nicolas

Ouais, puis tu te fais prendre dedans. Au début j'en avais mis. Je les regardais trop souvent et je me disais mais pourquoi je fais ça ? Au final, je me suis concentré sur : "j'ai un sujet que je veux creuser", et voilà. Mais du coup, je ne saurais pas te confirmer ce chiffre.

Alexandre

En tout cas, c'est une vraie mine d'infos. C'est un bon point d'entrée pour aller creuser le sujet.

Nicolas

J'ai essayé de faire ça, collecter les ressources à un seul endroit. Après, je redirige aussi sur plein de choses, de ressources différentes comme les livres. J'en ai lu pas mal. J'ai essayé de trouver tout ce qu'il y a sur le sujet. Il en a qui ne pas rentrés dans la liste parce qu'ils n'étaient pas terribles. Ceux que j'ai mis sur le site, c'est ceux qui m'ont vraiment plu. Je les ai d'ailleurs classés le premier. C'est vraiment ceux que je trouve qui ont changé un peu ma vision de faire et dont je me sers. Les derniers sont intéressants, mais plus anecdotique peut-être.

Alexandre

Il a le top 3 avec Working Efficiently with Legacy Code, Refactoring et celui de Adam Tornhill.

Nicolas

Oui, celui d'Adam Tornhill. Et toujours à date, après toutes ces années, ça reste la seule personne qui creuse vraiment ce sujet-là (de l'analyse comportementale). C'est fascinant.

Alexandre

Tu as donné des conférences pour Devoxx (FR), MenderCon, ConFoo, Software Crafters Luxembourg. J'ai vu que tu e as deux encore en préparation pour bientôt.

Nicolas

Oui, la semaine prochaine. On a une conférence ici qui s'appelle ConFoo. C'est pas aussi gros qu'un Devoxx, mais c'est quand même pas mal. Il a 700 développeurs à peu près. C'est quand même un gros truc. Et c'est à domicile. Souvent je participe. Et ils sont toujours en recherche de speakers. Quand c'est une grosse conférence, il y a plusieurs tracks. Ils cherchent pas mal de speakers.

Alexandre

C'est cool ça. 700 ça commence à faire un bel event.

Nicolas

Après c'est pas 700 dans la même salle, il y a plusieurs tracks en parallèle. Je vais avoir une centaine de personnes à peu près. Mais c'est cool. J'étais en France avant d'arriver ici, et l'écosystème français et européen est je trouve plus riche parce que c'est facile d'accès. Il a plein de conférences dans chacun des pays et tu y vas assez rapidement, c'est à une heure d'avion, deux heures, ou du train. Alors qu'ici, c'est loin. Donc, à Montréal, on a une conférence par an, mais après le plus proche, c'est New York. Et après, c'est de l'autre côté. Il y a moins d'activités.

Alexandre

Ok, parce que c'est quoi la capitale du Canada ?

Nicolas

Tu vas avoir Ottawa mais il n'y a pas grand chose là-bas. À Toronto tu vas avoir de la Tech. Si tu veux y aller en voiture je crois que c'est 5h. Sinon c'est Vancouver. Les distances sont grandes et du coup je trouve qu'il y a moins d'effervescence, de conférences, d'animations, etc.

Alexandre

Ok, vous êtes un peu isolé.

Nicolas

Il y en a plus aux Etats-Unis mais pareil, ça va être soit sur une côte ou soit sur l'autre et du coup si tu veux y aller c'est 6 heures de vol. Donc tu le fais pas trop. Pas autant qu'en Europe.

Alexandre

Ça me fait une parfaite transition. Tu as fondé le meetup Software Crafters Montréal qui comptabilise plus de 80 événements.

Nicolas

On en fait un par mois sans exception. Et puis des fois on en fait des bonus.

Alexandre

2000 membres inscrits et quelques invités de marque comme JB Rainsberger, Gleb Bahmutov.

Nicolas

On en profite quand il y a des événements. J'en profite du coup pour leur dire, "est-ce que ça vous dirait de venir parler à notre communauté ?". En général, ils disent oui.

Alexandre

Ils sont assez accessibles ?

Nicolas

Oui. Et puis tu demandes. Au pire, ils te disent non.

Alexandre

Oui tu n'as rien à perdre.

Tu organises Socrates Canada pour la troisième édition.

Nicolas

J'ai essayé. On a fait deux éditions. Il y eu la pandémie. Ça a été compliqué. J'ai mis ça en pause pour l'instant parce que j'avais du mal à trouver des sponsors. Je veux garder les prix accessibles pour les participants. Du coup, pour l'instant, on est en train de monter des conférences, mais avec les autres meet-up. Socrates pour Canada, c'est une tentative, ça reviendra peut-être, mais pour l'instant c'est pas actif.

Alexandre

Ok. J'ai vu les photos des deux premières éditions, ça avait l'air vraiment bien.

Nicolas

On avait fait deux éditions. C'était cool. J'aimerais bien que ça reprenne, mais pour l'instant les sponsors ne savent pas trop avec le contexte économique. Et là les américains qui sont en mode, on va mettre des tarifs / pas des tarifs. C'est compliqué d'avoir du sponsoring. Mais ça reviendra. On est patients.

Alexandre

Par ailleurs, tu as créé Abracadabra, un plugin VS Code qui automatise les refactoring et qui a été installé plus de 100 000 fois.

Nicolas

Oui. J'ai écrit Abracadabra avant d'arriver au Canada, il a un peu plus de sept ans. Je continue à le maintenir, là où il en a beaucoup qui sont nés et qui sont morts. C'est l'écosystème JavaScript. Il y a beaucoup de choix, mais des choix qui durent dans le temps, c'est dur d'en trouver. Et VS Code, c'est un bon éditeur, mais c'est vrai que si tu le compares à IntelliJ, il manque de fonctionnalité. Ces fonctionnalités de refactoring me manquaient, donc j'ai fait une extension. Avec le temps, c'est installé pas mal de fois.

Alexandre

C'est un outil que utilises toi personnellement ?

Nicolas

Oui, à la base je l'avais fait pour moi. Je n'utilise pas tous les refactoring. Il en a que j'avais codé plus pour l'exercice. Mais extraire une variable, inline une variable, ça je les utilise tout le temps. En général, ceux qui ont des raccourcis claviers déjà prédéfinis, je les utilise tout le temps. Et les guard closes ou les trucs comme ça, ça m'arrive aussi souvent.

Alexandre

C'est vrai que je suis assez dépendant de PyCharm sur les refactorings.

Nicolas

IntelliJ c'est les meilleurs. Ça reste le meilleur éditeur que je connaisse pour du refactoring automatique, la suite IntelliJ, donc PyCharm pour Python, WebStorm pour ceux qui font du web. Dans le web c'est pas l'IDE le plus populaire, la communauté JS est plus sur VS Code ou maintenant toutes les alternatives, genre Cursor, etc.

Alexandre

IntelliJ est fermé, assez lourd à lancer, payant souvent.

Nicolas

Oui. Avec la Abracadabra, j'ai essayé de grappiller les quelques trucs qui sont vraiment bien et dont je peux pas me passer. Genre extraire une variable, tu mets ton curseur, tu fais extract variable et c'est instantané.

Alexandre

VS Code ne te fournit pas ça ?

Nicolas

Non, de base, tu ne l'as pas. C'est assez basique. La seule chose qu'il te fournit c'est Rename, ça c'est VS Code qui le gère. L'équipe TypeScript a commencé à rajouter quelques fonctionnalités, mais en général l'expérience utilisateur ne me plaît pas. Par exemple, il faut que tu sélectionnes exactement le code que tu veux extraire avec ta souris, alors que moi je veux juste mettre mon cursor au milieu, lancer mon raccourci et que ça le fasse, voilà. L'extension, je m'en sers encore tous les jours.

Alexandre

C'est vraiment les trucs de base dont tu te sers tout le temps.

Nicolas

C'est ça. L'avantage c'est que du coup, ceux-là je les ai codés il a longtemps et c'est assez stable. Je n'ai pas eu besoin de les modifier beaucoup. Parfois ça m'arrive d'avoir un bug parce qu'il a un scénario que j'avais pas rencontré avant et j'ajoute le cas.

Alexandre

Je serais assez curieux d'aller voir le code source parce que du coup c'est des refactoring statiques. T'as une part de suggestion ? Il y a une part d'IA dedans pour de la suggestion ?

Nicolas

Il n'y a pas d'IA, il n'y a pas de LLM derrière. Après tu vas avoir deux choses.

En fonction de où est le curseur, la sélection de code et le fichier, je peux regarder quels refactorings peuvent être exécutées et je te propose ces refactorings. Tu as un raccourci qui te donne "ok je peux faire quoi depuis là où je suis ?" et qui te liste les deux ou trois refactorings que tu peux faire. Donc c'est de la suggestion mais c'est plus : je regarde ce que je peux faire et je te propose ceux qui sont valides. Il n'y a pas d'IA derrière.

La deuxième chose c'est quand tu rename, quand tu extrais un truc, si ce que tu extrais c'est du texte ou des trucs comme ça, je vais te suggérer un nom de variable. Mais c'est pareil, il y a des règles. C'est pratique, mais il n'y pas de LLM.

Alexandre

Ce qui fait qu'il est prédictif.

Nicolas

Oui, oui, c'est ça. Et puis je ne voulais pas en faire un side project, donc c'est pas un truc sur lequel j'ai investi non plus énormément de temps. Je voulais pas commencer à rajouter ces idées que tu as des LLM, du coup tu as un budget potentiellement, des tokens, des trucs. Il y en a plein d'autres qui font ça. C'est plus pour améliorer ce que peut faire VS Code pour toi en tant qu'outil. Mais mon ambition n'était pas de remplacer un éditeur.

Alexandre

Oui les LLM ajoutent une couche de complexité.

Ok, c'est cool. Peut-être que je pourrais me lancer sur un portage en python ! Ça pourrait être un chouette projet.

Nicolas

Oui

Alexandre

Tu un parcours assez atypique puisque tu n'as pas du tout fait d'école d'ingénieur.

Nicolas

Non !

Alexandre

Tu as découvert HTML à 15-16 ans en bidouillant sur un forum de jeux de rôle. Ensuite, tu fait une prépa physique-chimie. Tu as fait un premier pivot vers une école de commerce, où tu t'es retrouvé à coder avec la junior entreprise du département tech.

Nicolas

Oui, en fait l'école que j'ai faite c'est Télécom. Sur le même campus, il y avait une école d'ingénieur et une école de commerce. Moi j'étais dans l'école de commerce, mais il y avait un mélange. Ce qui fait que dans la vie associative, j'étais vice-président de l'association qui gère les réseaux informatiques. Il avait une perméabilité. Il y avait le cursus ingénieur, le cursus manager. J'ai fait une spécification qui était un mélange entre les deux. Et typiquement, les gens qui terminent ça vont ensuite dans le conseil en informatique. J'avais un profil plus manager, mais en pratique, je codais aussi.

Alexandre

Ce qui t'a amené à vendre ta première solution de e-commerce pour 200 euros.

Nicolas

Oui. Alors ce n'est pas exactement ça. Effectivement, j'ai commencé à travailler quand j'étais encore étudiant. Je me suis lancé en auto-entrepreneur. Et j'avais eu un premier client sur du e-commerce. On avait fait un site e-commerce pour une petite boutique parisienne. Je sais pas si c'était 200 euros, mais c'était moins de 2000 euros en tout, pour toute la prestation, pour deux, et on a passé six mois dessus. C'était le premier projet.

Alexandre

Après quand tu débutes je me demande si finalement ce que tu cherches c'est pas juste un use case et de l'expérience.

Nicolas

Oui c'est ça, de l'expérience. Et c'était de voir "tiens est-ce que je peux être payé pour ce que je fais ?" Avec le recul, ce n'était pas la meilleure chose pour le client, même s'ils étaient satisfaits, mais je sais pas ce qu'ils en ont fait après. Ils ont certainement dû le refaire parce que c'était une solution faite à la main par des jeunes étudiants. En même temps ça leur a pas coûté cher.

Alexandre

Après :

J'ai l'impression que c'est à ce moment là que tu t'es dit, il a un truc à faire sur le Legacy. Le sujet est méconnu. Il y a un truc à creuser.

Nicolas

Oui. En fait, avec le Meetup Crafter, c'est des discussions qu'on avait souvent à Paris. OCTO c'est boîte de conseil. Quand j'y étais, il y avait des tribus et tu pouvais choisir où tu allais. Moi, j'étais allé dans la tribu Craft. C'est là où j'ai vraiment appris comment gérer du Code Legacy. C'est un gros sujet, avec des pratiques autour. Avec OCTO, j'avais commencé à faire des formations aussi. D'abord en faisant du shadowing, puis ensuite en gérant les formations de TDD, refactoring, ce genre de choses. Quand je suis arrivé à Busbud j'ai continué à faire un petit peu tout ça mais pas en tant que consultant, en interne dans la compagnie, et c'est là où je me suis dit : bon c'est bien mais les formations que je fais, plutôt que juste de les faire à 10 personnes, j'aimerais bien les mettre en open source, genre sur un blog. C'est là que j'ai commencé à créer le blog et à écrire des articles, pour que ce que moi je faisais comme recherche ait un impact public.

Alexandre

Tu as passé deux ans chez Busbud, puis deux ans chez Centered, dans le domaine de la productivité.

Nicolas

3 ans chez Busbud. Et j'étais pas mal chez Busbud. La chose qui m'a fait partir, c'est qu'il y a des américains qui m'ont contacté. Ils travaillaient sur une application de productivité personnelle. C'est un autre gros sujet que j'aime beaucoup. Du coup ça me tentait beaucoup de travailler sur ça. Busbud c'est un Expedia pour les bus inter-cités. Ce qui était intéressant, mais le produit ne résonnait pas avec mes intérêts personnels. Je n'étais pas un gros utilisateur du produit, alors qu'eux, ils me proposaient de travailler sur un produit que j'utilisais moi-même. Donc, je suis parti, j'ai rejoint Centered. Ça duré deux ans. Cétait la pandémie. Je ne sais plus trop quand c'était, mais en gros, ils n'ont pas réussi à faire la levée de fonds. Il n'y plus eu d'argent, donc ça s'est arrêté. Ça n'a pas marché.

Alexandre

Avec les startups, ça arrive. Et là, tu es repassé freelance du coup.

Nicolas

Ouais, c'est ça. J'aurais pu retourner chez Busbud, mais après je me suis dit : "bon bah écoute, je suis à mon compte". J'étais devenu résident permanent du Canada aussi. Je n'étais plus sous visa. Donc je pouvais faire ce que je voulais. Je me suis dit, je vais rester à mon compte, voir ce que ça donne. Et finalement, pour l'instant, j'ai eu des clients jusque-là. Donc ça va.

Alexandre

Tu travailles avec qui aujourd'hui ? Des grands groupes ? Des scale ups ? des PME ?

Nicolas

Pas des grands groupes comme quand j'étais à OCTO parce que les grands groupes ne travaillent avec des auto-entrepreneurs tout seuls. Après ça existe, mais en général, il faut faire un portage à travers une autre grosse compagnie.

Effectivement, c'est plutôt des scale-ups. Des startups qui ont levé des fonds, qui commencent à recruter du dev, puis ça fait quelques années qu'ils ont du code et puis il a plus ou moins des problèmes et du coup ils ont cet intérêt pour le legacy là. Maintenant ça fait un an et demi que mon client principal, c'est un client américain et en fait c'est un studio, c'est différent. C'est un studio de développement. Donc là je suis revenu encore très early, je n'ai jamais été aussi early stage dans la vie d'un produit.

Là je travaille sur des prototypes. L'idée c'est de travailler sur un prototype de produit, si ça marche ils en font une startup, il y en a deux qui ont marché l'année dernière par exemple, et si ça marche pas, au bout d'un moment on dit stop et on passe sur autre chose. Quand je fais ça je fais pas du legacy, je travaille pas avec du code existant.

C'est intéressant parce que ça m'oblige un petit peu à changer mon fusil d'épaule sur les pratiques, à les adapter en tout cas parce que c'est pas la même approche quand tu sais pas si le code que tu fais dans trois mois tu le jettes ou pas. Mais c'est pas non plus un aspect à complètement dégager donc c'est un peu ça que j'apporte. Pour ceux qui marchent, il faut que ça parte bien et pas que vous vous retrouviez dans trois ans dans la situation de mes clients d'avant.

J'essaie de les envoyer dans la bonne direction. C'est assez fun. Je fais ça maintenant depuis un an et demi à peu près. Et ponctuellement, il m'arrive de faire des formations, du coaching ou des truc plus ponctuels quand un client a un besoin spécifique.

Alexandre

Ok. T'es plutôt sur une mission longue, avec en satellite, formations, des trucs comme ça.

Nicolas

Oui, voilà. En tout cas, c'est le format que j'ai depuis un an et demi, depuis que j'ai ce client-là. Après, entre le moment où j'ai arrêté Centered et le moment où j'ai commencé ce client, il s'est passé un an à peu près, où là, j'ai plutôt enchaîné des missions qui ont duré quelques mois pour des clients différents, trois clients différents. Donc, ça m'a fait tenir un an à peu près. J'ai un peu tout touché. C'est aussi le côté un peu fun d'être à son compte, c'est que tu peux expérimenter des choses différentes. La recherche client qui s'apparente un petit peu à la recherche d'emploi, mais le processus est quand même plus simple. Le client, si tu le convainc que t'es là pour répondre à son besoin et que tu as des compétences, tu passes pas à 8 entretiens techniques pour évaluer si tu as un culture fit, tout ça.

C'est plus flexible et il a pas de relation de dépendance. Mon client, c'est mon client. Je lui dis quand je suis dispo, quand je ne pas dispo. Je peux avoir un truc ponctuel de temps en temps et je lui dis je ne pas dispo, je lui facture ce que je travaille. C'est une relation différente. Je ne sais pas si je ferais ça toute ma vie parce que c'est du travail. Il y a aussi l'incertitude. Mais d'un autre côté, en ce moment, je m'éclate pas mal. Je prévois pas d'arrêter.

Alexandre

Est-ce que tu as déjà eu des boîtes qui sont venues te voir vraiment pour du legacy, genre on a un problème de legacy, est-ce que tu peux venir jeter un oeil sous le capot et nous filer un coup de main ?

Nicolas

Oui, j'ai déjà fait des audits pour ça. Une fois en particulier. Là, c'était terrible parce que j'étais déjà engagé, donc je n'avais pas vraiment le temps. Eux voulaient que je vienne dès que possible chez eux, pour plusieurs mois. C'était une compagnie qui était dans l'immobilier. Leur système a des décennies, et ce qu'il se passait c'est que leur développeur principal il allait partir à la retraite. Il était là depuis une trentaine d'années. Il a fait sa carrière là-bas. Et ils se sont rendu compte, alors qu'il devait partir dans quelques mois à la retraite, que le reste de l'équipe n'était pas autonome. Avec la manière dont ils travaillaient c'était lui qui prenait toutes les décisions. Quand ils ont réalisé ça alors qu'il restait deux mois, ils étaient en panique parce qu'ils se disaient "mais comment on va faire quand il sera plus là ?". Alors ils se réveillaient tard mais c'est aussi la réalité de beaucoup. Et du coup ils étaient là littéralement, "on te paie ce que tu veux pour que tu puisses venir nous faire une transition la meilleure possible etc". J'ai pris un peu de mon temps pour les orienter, mais j'ai dit que moi non, j'étais pas disponible en ce moment. Et je ne pouvais pas venir dans six mois, c'était maintenant.

J'ai fait un suivi avec eux pour savoir comment ça se passait et ça va. Ça a été un peu houleux. Je leur avais dit, il n'y aura pas de mystère, ça va être un petit peu compliqué. Mais ils se sont quand même réveillés avant que ça arrive. Et ils ont pu anticiper. Ça a été un peu rude, mais ils ont réussi à faire une transition. Ils ont recruté des gens, ils ont fait de la passation de connaissances. Ils ont documenté, beaucoup. Ils ont changé aussi leur manière de travailler aujourd'hui. Les derniers échos que j'ai eu en tout cas c'était ça, c'était que ok ça va, ça se passe, ils ont survécu.

Alexandre

Et tu leurs as préconisé quoi comme pratiques ?

Nicolas

Là on était pas mal sur des mesures à court terme pour gérer le off-boarding. Je leur ai parlé du livre d'Adam Tornhill et des pratiques qu'il présente : "Ok, on va lancer quelques scripts juste pour voir dans toute votre code base c'est quoi les trucs qui sont changés le plus souvent et dont cette personne est la principale contributrice. Focalisez-vous sur ces parties-là." En gros, réduire le champs, prioriser ce sur quoi il faut transitionner d'abord, c'est quoi qui va être le plus critique. Tu combines ce que cette personne maîtrise le plus et qu'est-ce qui est le plus souvent modifié sur ces 12 derniers mois, en général ça donne une bonne idée de ce qui a besoin d'être couvert. Et on a priorisé la passation de connaissances là-dessus.

On a aussi travaillé sur les pratiques de documentation, le pairing, le fait que cette personne-là, il faut qu'elle arrête de travailler toute seule à partir de maintenant. Maintenant, elle doit travailler avec au moins une autre personne et elle lui dit quoi faire. Et ça va être un peu pénible, mais cette personne-là, il ne lui reste que trois mois à travailler, puis il finit, c'est pas grave. Mais c'est ce qui va faire la différence entre la connaissance va passer ou elle va être perdue.

Donc ça, c'était les deux gros points. Et après, dans les points long terme, pour l'avenir, que ce serait bien de faire des ADR pour documenter les décisions que les gens prennent.

Un des points que j'avais recommandé aussi, c'était de faire un peu le tour des scripts. Tout ce qui était un petit peu script ad hoc, les trucs que ce développeur avait en local sur sa machine ou avait tendance à rouler. Et donc de prendre conscience de ça pour qu'il les transmette. Parce qu'on ne s'en rend pas compte, mais en fait, tu accumules des petits trucs types script qu'un développeur qui est là depuis 5, 6, 7 ans, il a toute sa petite réserve de codes, de choses, de machins, de procédures qu'il n'utilise que lui et qu'il partage pas. Parce qu'il a juste construit ça pour simplifier sa vie. Il faut absolument qu'il montre aux autres ce qu'il a, ce qu'il fait. Ça a été beaucoup au partage.

Alexandre

Ça peut vite rester dans l'angle mort.

Nicolas

Oui, c'est classique.

Un des trucs qu'il faut regarder aussi, c'est, est-ce que quelqu'un d'autre est capable de faire une mise à jour en production ? D'amener un changement de code jusqu'en production, qu'est-ce que ça prend ? Des fois, tu as des surprises. Il y a plein choses qui ne pas automatisées, pas documentées.

Eux, ils ont vraiment touché du doigt le côté où la personne par à la retraite et il a rien que tu puisses faire à ça. Mais il y a plein d'entreprises qui sont dans des situations comme ça de dépendance où si la personne tombe malade, si elle fait un burn out ou quelque chose, tu n'as pas forcément trois mois pour anticiper. Donc c'est bien d'en prendre conscience le plus vite possible et d'essayer de mettre en place des mesures pour que ta compagnie ne dépendent pas exclusivement d'une ou deux personnes. Et en fait, ça c'est angle mort, comme tu dis, parce que eux ils avaient une équipe, dans leur tête tout allait bien. Mais ils se sont rendus compte que la dans manière dont l'équipe travaillait, il n'y avait que lui, et les autres étaient en mode "je fais ce qu'on me dit de faire mais je sais pas".

Alexandre

C'est hyper intéressant, je vois bien pourquoi ça a marché. Et ça illustre bien l'intérêt des techniques d'Adam Tornhill.

Nicolas

C'est ça.

Ce que j'aime beaucoup aussi avec ça, c'est que c'est quelque chose auquel on ne pense pas. Eux ils utilisaient Git. Maintenant, je dirais que c'est fréquent. Il y a peu d'équipes matures qui travaillent du Code Legacy qui n'ont pas une manière ou une autre de versionner leur code. Et si tu as ça, tu as une mine d'or d'informations sur qui a touché à quelle partie du code et quand. Et juste avec ça, tu peux avoir plein de points de données, plein de trucs qui vont t'aider à prendre des décisions.

Ça ne suffit pas en général, tu combines ça avec parler avec les gens pour apprendre et avoir un côté un peu plus qualitatif, mais ça, te donne des métriques.

Je m'en suis souvent servi pour faire le point sur la situation.

Ça m'est arrivé aussi avec un autre client, de sortir ça pour voir les hotspots, pareil, juste pour voir un petit peu où est la dette technique, mais surtout où est la dette technique qui fait mal, celle qui est là où la plupart du temps les gens travaillent. Là, peu importe la taille de la code base. Ça dépend de la taille de l'équipe.

Ça aussi, c'est génial. Si tu as une code base qui fait 5 millions de lignes de code, même si tu n'as que trois personnes qui travaillent dessus, de toute façon ils ne touchent qu'une infime partie de tout ça, et la question c'est, "sur cette partie qu'ils touchent, c'est quoi qui est compliqué ?". Et en général ça permet de venir avec un plan d'action.

Je parle avec des développeurs qui me disent, "oui mais moi j'arrive pas à vendre le refactoring", ou les trucs comme ça, ce genre de projet un peu technique à des gens qui sont business. Ce qui est normal aussi parce que les gens business, ils voient le business, et si tu n'arrives pas à expliquer pourquoi ton truc technique est nécessaire, et surtout si tu leur dis il va falloir s'arrêter je sais pas trois mois pour tout nettoyer pour faire une refonte, bah ils sont très frileux. En général, ça ne se passe pas comme prévu. Il y a des retards, il des coûts, voir il ya des échecs. On a des exemples de ça au Québec, de gros échecs là dessus, et ça fait très mal. Mais bon, d'arriver avec des plans comme ça de "ok j'ai un plan d'action", "j'ai identifié ça", "regardez j'ai même des diagrammes", "on va seulement passer 20 % du temps sur cette partie là et on va avoir un meilleur retour sur l'investissement", je trouve que ça aide à débloquer les conversations. Et en général tu peux plus facilement arriver à justement avoir du budget pour refactoring si tu n'arrives pas avec un tout-ou-rien qui est un peu théorique, mais que tu arrives avec "j'ai des diagrammes", "j'ai des métriques".

Et le livre d'Adam Tornhill est très bon pour ça.

Alexandre

Ok. Et puis t'as un peu découpé le problème en fait. C'est pas tout ou rien.

Nicolas

Oui, tu arrives avec ça. C'est à dire qu'il a une différence entre :

  1. C'est mes opinions et je dis que le code il est vraiment sale, c'est vraiment difficile, etc. Mais là je fais que exprimer mon avis
  2. Alors que tu arrives avec, regardez j'ai fait une analyse, c'est notre code base, vous voyez y a des bulles rouges, plus elle est grosse et plus elle est rouge, plus c'est un point chaud. Donc ce que je propose c'est qu'on va pas s'attaquer à tout ça mais on va s'attaquer à ce point chaud, parce que si on fait ça alors on aura un très bon retour sur l'investissement. On va voir les résultats concrets à réaliser rapidement, et là tu discutes. Ça ressemble à un plan. Je ne dis pas que ça suffit, mais ça aide beaucoup la discussion.

Alexandre

Qu'est qui t'a plus aidé à progresser sur du legacy ? Est-ce que c'est des livres, est-ce que c'est des formations, est-ce que c'est le terrain, est-ce que c'est les meet-up ?

Nicolas

C'est un peu un mélange.

C'est vrai que d'une manière générale, pas que sur Legacy, là où j'avais beaucoup progressé, c'est quand j'avais eu la chance de travailler à OCTO. Les deux ans que j'ai fait à OCTO, c'est là où j'ai appris le plus vite parce que je pouvais travailler avec d'autres personnes qui avaient aussi ces intérêts-là, et en fait, on arrivait tous avec. On fait tous notre veille dans notre coin parce qu'on aime ça, et puis moi je regarde des présentations, je pratique des kata etc. J'arrive avec mes forces, mais la personne avec qui je travaillais, elle aussi elle était passionnée, elle avait étudié des trucs, et en fait, je continuais d'apprendre de cette personne là qui avait fait le travail de tri, et qui m'apportait : voilà, c'est ça, c'est ça que tu dois faire etc. Là, j'ai vraiment progressé très vite.

Depuis, je n'ai plus eu la chance de travailler avec des gens qui étaient comme ça. J'en croise, au meetup. Le meetup, c'est vraiment bien. C'est quelque chose que je recommande en général pour les développeurs, surtout ceux qui se posent des questions, qui veulent changer d'emploi ou changer d'équipe. Tu ne sais jamais quand est-ce que tu vas avoir besoin de retrouver quelque chose. Ou dans mon cas, exemple, je suis à mon compte, ça crée des liens. Je ne suis pas capable de dire quel meetup qui m'a apporté quel client. Mais ce que je sais, c'est que les clients que j'ai eus, et en tout cas les plus intéressants, c'était du bouche-à-oreille. C'est quelqu'un qui m'a recommandé, que j'ai croisé, que j'ai connu à un meetup, et on s'est revu trois fois, et il m'a parlé de lui. En fait, c'est le réseau. Le meetup, ça apporte vraiment ça. Ça me permet d'échanger des idées. Je ressors de là avec, tiens, il y a ce livre auquel je n'avais entendu parler jusqu'à présent, cet article et tout. Mais surtout, je connais des gens, et demain, si j'ai un besoin ou si j'ai question, j'ai des gens à qui parler. Ça, c'est les meetups.

Et la dernière chose, c'est effectivement moi personnellement. Je lis des livres, je fais des exercices, des katas, je regarde des talks, etc. J'ai eu des formations aussi. Celle de JB Rainsberger quand j'étais tech lead à Busbud. J'avais pu utiliser du budget formation pour avoir une formation de lui dans notre équipe.

Et pareil, j'ai appris des choses, ça a consolidé, ça a fait des clics dans ma tête sur des choses où j'avais déjà une intuition, mais il l'a expliqué d'une autre manière qui a fait que j'ai encore mieux compris. Et là, c'est devenu clair pour moi comment le faire concrètement.

C'est un peu un mélange. Ça prend du temps. La meilleure chose, je trouve encore aujourd'hui, c'est d'arriver à avoir la chance de pouvoir travailler en binôme ou plus avec quelqu'un d'autre qui a aussi cette appétence.

C'est là qu'on apprend.

Mais même en équipe, je le vois avec mes clients, j'essaye de pousser aussi pour faire plus de pairing. Mais c'est rare. C'est franchement rare d'avoir du bon pairing. Et pourtant, même quand on le fait, même avec des gens réticents, rien que le fait de les voir se partager les "mais tiens, utilise ça" ou "tiens, ce raccourci, tu le connais pas ?". T'as fait une heure où t'as avancé sur ton sujet, mais en fait t'as aussi appris des trucs que t'aurais jamais appris sans binomer.

Alexandre

Ouais tu vois plein de choses en fait. J'adore voir comment la personne travaille. En général elle utilises ses outils complètement différemment de toi. Tu dis, "ah mais tiens, je n'aurais jamais pensé à l'utiliser comme ça". Ouais c'est cool.

Nicolas

Il y a des choses que tu vas apporter. Tu dis "attends, la manière dont tu fais, fais-le comme ça" et ça va faire un déclic dans la tête de l'autre personne. Et inversement, tu dis, "mais tu utilises ça ?". Il y a des outils que j'ai découvert comme ça. Je l'ai vu utilisé, ça marchait bien, je me suis mis à l'utiliser, et je suis très content de l'utiliser. Mais ça reste quelque chose qui est rare.

En tout cas, à chaque fois que j'arrive chez un client, le standard, c'est : les développeurs se répartissent les tâches et communiquent au stand-up, ou parfois sur Slack, mais travaillent en solo. Surtout maintenant en remote, c'est vraiment le cas. Ce qui est très confortable, je travaille en remote aussi, mais c'est vrai que si ce qui t'intéresse c'est de devenir meilleur, le raccourci que je te donne, c'est de travailler avec quelqu'un d'autre.

Alexandre

Ouais, en pair.

Et si quelqu'un qui est plus avancé que toi ça aide aussi. Ou peut-être pas forcément ?

Nicolas

C'est vrai que des fois, je me retrouve à juste faire du mentorat. Mais même là, c'est intéressant parce que le fait d'expliquer quelque chose à quelqu'un qui plus junior que toi, ça te force à réfléchir à ce point là. Et des fois, tu vas pouvoir mettre en lumière ce que toi tu ne sais pas trop, et donc le creuser; ou ça va le consolider dans ta tête.

En fait, même quand c'est quelqu'un qui est plus junior et qui en bénéficie plus que toi, qui va apprendre, toi ça t'aide aussi. Sur des concepts où tu n'es pas certain, tu les mets à l'épreuve, et en fait, tu en ressors avec des convictions plus solides. Tu as creusé et tu as appris des choses.

Après, quand c'est quelqu'un qui est à ton niveau, en général, cette personne va avoir des compétences différentes des tiennes et ce que tu vas apprendre, c'est là où la personne est douée et pas toi. Tu vas apprendre de ça.

En général, c'est toujours positif.

Après y a deux choses.

La première : c'est fatigant, évidemment. Travailler solo avec mon casque sur les oreilles, c'est une chose, travailler en discutant avec quelqu'un d'autre, c'est plus fatigant.

La deuxième : c'est que ça peut arriver que tu tombes avec quelqu'un qui a une attitude qui ne colle pas à la tienne. J'ai déjà eu à travailler, quand j'étais consultant, avec des personnes qui étaient un peu toxiques, un petit peu... Bon, c'est pas idéal non plus.

Alexandre

Des fois, ça marche pas.

Nicolas

Des fois, ça marche pas. En pair. Ou même parfois en équipe aussi.

Au meet-up crafters, on a souvent des gens qui viennent avec des problèmes : "il y a ça au travail", "comment... ?". Ils cherchent du conseil. Et des fois la réponse c'est "cherche autre chose", parce que si la culture de l'équipe est comme ça, toi tout seul, tu pourras pas changer la culture de l'équipe. À moins que tu sois dans position de leadership, mais en général c'est pas le cas.

Alexandre

C'est quoi le truc le plus tordu que t'as eu à réfactorer ?

Nicolas

aah j'ai pas de tier list en tête.

Si, un point là-dessus, c'est que les exercices de code, les katas et tout, c'est très bien. D'ailleurs, j'avais fait une liste de ceux qui étaient utiles pour le Code Legacy. Parce que les katas, y en a plein. Et je les avais classés par ordre de difficulté. Le plus connu, c'est le Gilded Rose. Qui est bien pour commencer, mais ça ne suffit pas parce que c'est pas du code qui ressemble à du vrai code de prod. Il n'y a pas d'effet de bords, c'est de la pure logique, etc. Dans la vraie vie, c'est jamais comme ça.

Les codes les plus tordus que j'ai eu à Refactor, je ne sais pas. Mais en général, la caractéristique, c'est qu'il y a des side effects que tu ne vois pas quand tu lis le code. Il a quelque chose d'autre qui se passe ailleurs et tu n'as pas d'idée de comment c'est déclenché. Ça peut venir des données, peut venir de comment c'est déployé, c'est pas forcément dans le code. Et ça pour moi, c'est là où c'est le plus difficile. C'est là où en général aussi l'IA se casse les dents. J'ai beaucoup creusé ce que l'IA peut faire pour le Code Legacy. Dans la réalité, il y a toujours des bouts comme ça où l'information n'est pas dans le code, elle est ailleurs, dans la tête de certaines personnes ou dans certains documents. Et c'est difficile de réorganiser ça.

C'est pour ça aussi que c'est important de binomer, parce que des fois, l'information est dans la tête d'autres personnes. Il y a des gens qui sont un peu sceptiques, surtout quand ils sont seniors, ils sont un peu sceptiques sur le fait de binomer, ils ont l'impression que ils perdent du temps, surtout quand ils l'ont jamais fait. Mais ces personnes ont déjà au moins expérimenté une fois une situation de crise où il y a eu une espèce de war room où tu mets les développeurs en même temps dans le même call ou dans le même salle pour résoudre le problème et tu vois les échanges qui se passent à ce moment là. Pour moi, c'est exactement ça ce qu'il se passe quand tu as du code vraiment legacy, vraiment velu et que tu veux le simplifier.

Il faut que tu ramènes les gens qui travaillent avec ce code parce qu'ils ont tous des morceaux d'information. C'est un escape game et tout le monde a sa vision, son indice, etc. Il faut parler.

Je n'ai pas répondu directement à ta question parce que je n'ai pas d'exemple de code le plus tordu, mais en général, quand c'est compliqué, que l'info n'est pas que dans le code. Et la solution est de discuter avec les autres.

Alexandre

J'aime beaucoup l'image de l'escape game. Tu vois bien la force de communiquer, de parler.

Après en sortant de ton livre, je ne sais pas si c'est un effet Dunning-Kruger, mais j'ai l'impression que qu'avec ces outils, je peux tout faire. Il n'y a aucune code base qui peut me resister. Et je me dis "qu'est-ce qui pourrait être compliqué quand même ?" Et je me dis peut-être si t'as des microservices. Y'a les microservices et le front-end qui sont encore deux cas à part.

Nicolas

Le front-end c'est un sujet qui est toujours intéressant. Je sais que dans les conférences par exemple des DDD Europe ce genre de choses, ils sont assez friands de talks qui vont partir sur du DDD sur le front-end par exemple parce que c'est souvent négligé. C'est pas un discours que t'as beaucoup dans le front-end où on s'intéresse plus aux technos. Mais pour moi l'explication c'est que parfois le front-end c'est vraiment juste une vue de ton back-end et en fait, quand tu as une application web, tu as des applications mobiles et puis que tu as aussi des APIs etc, le front-end web c'est pas nécessairement le cœur du domaine.

Il y a toujours ces discussions de savoir où doit se trouver le domaine, est-ce que c'est plutôt côté back-end, plutôt côté front ? En général, souvent le cœur va être plutôt côté back et le front-end est négligé. Mais d'un autre côté, avec les exigences qu'on a aujourd'hui sur des applications front-end, où on veut que ce soit hyper réactif, t'es un peu obligé d'avoir de la logique qui reste côté front. Et il y a toutes ces discussions de comment tu partages ça.

Et ça, je trouve que ça se complique aussi avec la manière dont sont organisées les équipes. Je vois très fréquemment, et je comprends pourquoi, mais une séparation : l'équipe front, l'équipe back. Alors qu'en fait, pour réaliser une fonctionnalité, tu as besoin de toucher aux deux. Et là, tu as la loi de Conway qui se met dedans, est-ce que tu alignes tes équipes avec ton architecture, ce genre de chose.

Ça va peut-être faire un peu bateau, mais le plus compliqué en général, n'est pas le code legacy : c'est la culture et c'est les gens. Je disais, le plus tordu, c'est quand c'est pas dans le code, c'est quand il faut communiquer. Les trucs les plus difficiles en général, c'est ça, c'est de travailler ensemble, en équipe.

C'est différent de travailler quand tu es une équipe où quand tu n'es que trois. Même si le code est vieux, si tu n'es que 2 ou 3 à travailler dessus, et on le voit sur des vieux projets open source. Souvent en open source, tu as un mainteneur ou une très petite équipe de mainteneurs qui sont là depuis longtemps. Et eux, savent. En contrepartie, tu as des petits contributeurs. En général, et c'est dans le bouquin d'Adam Tornhill, il y a beaucoup plus de chances d'avoir une régression quand c'est un petit contributeur qui arrive et qui fait un changement par rapport à si c'est le mainteneur qui le fait. Le mec qui est là et qui a créé le code et qui maintient ça depuis 20 ans, c'est la grenouille dans sa casserole. Lui, connaît, il sait, c'est dans sa tête. Il n'y a pas que dans le code, il y a aussi tout son modèle mental. Il est capable d'évoluer dans cette codebase.

La difficulté dans une équipe, en tout cas de ce que je vois chez mes clients, c'est que c'est rare d'être dans ces cas-là. général, tu as plusieurs équipes qui doivent travailler ensemble sur le même produit qui est là depuis des décennies et il a des régressions tout le temps parce que quelqu'un fait une modification, il ne savait pas que ça a été fait il cinq ans par quelqu'un d'autre, qui n'est plus là, et donc ça casse. C'est pas facile.

Alexandre

Ça me fait penser à cette question. Ce serait quoi la suite de First Aid Kit ?

Nicolas

Le livre que j'avais fait, je l'ai appelé "first aid kit" parce que c'était plus une trousse à outils qu'un livre théorique. Pour chacune des techniques, j'explique pourquoi ça marche. Mais je voulais que ce soit très concret. Ce qui fait que c'est une caisse à outils. Donc ça ne résout pas tout. Tu disais, "avec ça, je peux attaquer n'importe quel code base legacy". Oui et non. Oui t'as les outils, mais ce qui va te manquer ensuite c'est de savoir t'en servir.

Ce que j'ai mis là dedans c'est ceux que j'utilise le plus. Parce qu'en fait, il y en a plus que 14 des techniques. D'ailleurs, c'est à ça que sert mon blog, c'est que j'y mets ce que je trouve. Il y en a que j'utilise, il en a que j'utilise moins. J'avais refait le point il a un an ou deux et en fait mon kit est toujours d'actualité. Je fais une présentation la semaine prochaine sur des refactoring justement. Les refactoring du code legacy, c'est deux qui sont dans le bouquin : Extend and Override, Distill et Extract. C'est des trucs que j'utilise tout le temps.

Ce sont des outils, ce qui manque ensuite c'est pratiquer.

J'ai une certaine expérience parce que j'ai fait des recherches puis j'ai pratiqué. Il y a d'autres gens, il a la communauté Legacy Code Rocks. En général je redirige les gens là-dessus parce qu'il y a d'autres personnes qui ont plus d'expérience que moi, qui ont une expérience différente, qui ont une expérience sur d'autres langages. Personnellement, je n'ai jamais fait de COBOL ou de Fortran. Je sais que ça existe, je sais des trucs, mais même avec mes outils, ça va me prendre de la pratique avant que je sois capable de venir sur une code base COBOL et d'améliorer l'état des choses. Je vais savoir quelle approche prendre, mais ça prend de la pratique.

Après, la suite de Legacy First Aid Kit, c'est de pratiquer, faire des formations. C'est pour ça aussi que je mentionne aussi les coding kata dans les différents langages, parce qu'en fonction du langage, ce n'est pas non plus la même philosophie. Il y a des principes qui sont les mêmes de refactoring, mais ensuite tu as des refactoring qui sont spécifiques à un langage ou une techno, et des approches différentes. Donc il faut pratiquer.

Un projet que j'avais en tête, mais je l'ai mis sur pause parce que ça prend du temps et je fais d'autres choses pour l'instant, mais peut-être je le ferai un jour. Je voulais faire une formation en ligne sur le refactoring, mais à ma manière.

Pour des développeurs qui travaillent sur des applications JavaScript et TypeScript, il a le bouquin de Martin Fowler sur le Refactoring, l'édition 2. Il l'a fait avec des exemples en JavaScript. Je l'ai lu, ça fait partie des références que j'ai. Il y a plus d'une soixantaine de refactoring. Dans cette soixantaine-là, j'avais fait l'exercice de me dire : "lesquels je trouve les plus utiles ?". Et en fait, il y a plein de refactorings où je n'ai jamais vu ce genre de code en JavaScript en vrai. Donc, je n'utiliserai jamais ce mouvement parce qu'en JavaScript, ça n'existe pas trop. Les gens ne codent pas comme ça. Par contre, il y en a d'autres. Eux, c'est tout le temps. Ce smell là, apparaît tout le temps, etc.

Et puis, il a aussi des refactoring qui utilisent d'autres refactoring. Par exemple, à la présentation que je vais faire, je commence à montrer inline, extract, rename, parce que ces trois trucs de base, ça nous permet de faire un change signature par exemple. Change signature, souvent tu peux t'en sortir en faisant un extract, tu modifies ton truc, ensuite tu fais inline et rename, et bam t'as fini. Donc, ce que je voulais faire, c'était une espèce de formation où on les prend dans l'ordre. On prend des refactoring, on les pratique, avec une espèce d'endroit où tu peux coder.

Le livre de Martin Fowler est bien, mais c'est de la lecture. Ce qui est mieux, c'est de coder, d'avoir une espèce de playground où tu dois refactor le code. Quand tu refactor le code à la manière de Martin Fowler, l'idée, c'est que tu veux garder le code dans un état qui passe les tests le plus longtemps possible. Tu ne veux pas tout casser pendant cinq minutes, puisque plus longtemps tu restes dans un état cassé, plus tu prends des risques de ne pas revenir sur tes pattes. Et donc on pourrait imaginer un playground où si tu casses le code, il a un timer qui se lance, et le but c'est d'avoir le plus bas score possible. Je pense que ça, ce serait un bon endroit où pratiquer. Ensuite le cours, ce serait : je te fais pratiquer les refactoring dans un ordre qui est logique et qui va t'amener à une maîtrise, plus rapidement que moi qui ai passé des années à pratiquer tout ça.

Peut-être qu'un jour je ferai ça.

Ce serait la prochaine étape.

C'est pratiquer, pratiquer, pratiquer.

Alexandre

Oui, parce qu'en fait le secret c'est de pratiquer derrière.

Je crois que c'est ça que j'aime bien dans ton livre aussi, c'est le côté où tu dis : "ok, la grande idée, ça va être de séparer le core de l'infrastructure, et en fait, on va voir plein de techniques pour parvenir à faire ça en petites étapes, sans casser le code, en restant toujours dans un état stable".

Nicolas

Oui c'est ça, as compris le cœur de la méthodologie.

Je dirais même que c'est... Parce là on parle de legacy code et de refactoring depuis le début. Mais il y a aussi tout un domaine dont on parle avec les Software Crafter, qui est l'architecture du code, la software architecture en général.

Il a plein de buzzwords, les gens parlent d'hexagonal architecture, de clean architecture, d'onion architecture, il y a même la A-frame architecture. Il y a plein de patterns différents. Ce qu'ils ont tous en commun, et ça je l'ai vraiment réalisé avec la formation de JB Rainsberger d'ailleurs, parce que j'avais cette idée là, qu'il y a un truc quelque part qui est commun à tout ça, mais je n'arrivais pas à mettre le doigt dessus, et il m'a fait mettre le doigt dessus, c'est que toutes ces architectures, même les principes solides, etc. Souvent, cœur, c'est... OK :

Et en général, quand on code, on combine les deux, on mélange les deux complètement, ce qui est logique parce qu'on est en train de connecter des trucs extérieurs, appliquer nos règles et connecter encore avec de l'extérieur pour que ça fasse le software qu'on veut.

Tous les principes d'architecture, avec leur manière de le dire, ils essayent de distinguer ta partie, tes règles business, ton domaine au sens DDD, où ensuite le DDD va dire comment organiser ton domaine, quoi mettre dedans, etc. Mais on s'en fout. Ton domaine, peu importe comment tu l'organises vs le monde extérieur dont tu as besoin. Le premier principe, c'est de séparer les deux autant que possible.

Et ensuite, quand tu en as deux, qui dépend de qui, tu veux que ton domaine ne dépendent pas du monde extérieur, mais que ce soit plutôt ton adaptation du monde extérieur qui dépende de ton domaine. Ça, c'est juste parce que c'est plus pratique, si tu veux derrière pouvoir changer tes solutions techniques sans impacter ton domaine. C'est plus facile dans ce sens-là. Et puis ton domaine, c'est ce que tu contrôles. Donc s'il est isolé et pur, tu atteins le Saint Graal.

En Legacy Code, tout est mêlé, et on essaie de démêler ça avec des techniques.

Alexandre

C'est la cible.

Nicolas

Ouai, c'est la cible.

Alexandre

Cool.

On arrive bientôt à la fin de l'échange et il me rester 4-5 micro questions.

Nicolas

Ok.

Alexandre

D'où vient ton blaze Nico Espeon ?

Nicolas

Ça vient d'il a très longtemps, de quand j'étais étudiant. Quand j'avais commencé à 15-16 ans, je m'intéressais au HTML/CSS et il fallait des pseudos. Le point, c'est que Nicolas Carlo, c'est beaucoup trop commun dans le monde. Je n'ai jamais pu avoir une adresse gmail Nicolas Carlo dans quelque sens que ce soit. Donc, il me fallait un autre truc et à l'époque, je jouais à Pokémon. Espeon c'est un Pokémon.

Alexandre

Donc c'est Mentali

Nicolas

Oui, c'est ça, c'est Mentali. C'était mon Pokémon préféré quand j'avais 15 ans. Du coup, je l'ai pris en pseudo. Et puis après, j'ai construit mon identité numérique autour de ça. Donc, c'est resté. Aujourd'hui je n'y pense pas, c'est mon blaze, Mais à la base, ça vient de là.

Alexandre

Est-ce tu fais appel à un designer pour ton site et pour ton livre, ou tu fais ça toi-même ?

Nicolas

C'est moi qui fais tout. Je touche un petit peu à tout. Je suis pas un gros graphiste, mais j'ai quelques notions.

Alexandre

Sympa. Je trouve ça réussi.

C'est quoi le design pattern dont tu abuses ?

Nicolas

Souvent, dans tous les refactoring que je présente, on fait deux choses. D'abord, l'inversion de dépendance. Donc : le pattern injection de dépendance, si tu fais de l'objet. Si tu fais du fonctionnel, passer en paramètres et composer.

Et le pattern adapter. Si je ne me trompe pas, c'est celui-là. Mais en gros, c'est ça : j'ai une interface qui est dans mon domaine, et j'ai besoin d'avoir deux implémentations de cette interface.

Alexandre

Stratégie.

Nicolas

Oui les deux patterns vont ensemble. Il a un endroit dans mon software où, systématiquement, le plus haut possible dans mon application, où je choisis quel est l'implémentation avec laquelle je roule et je m'en sers quasiment tout le temps. J'en ai besoin d'une en prod, j'en ai besoin d'une en test, et en général, j'en ai une pour mon dev. Et je peux choisir. C'est hyper pratique.

Donc stratégie, adapteur ça arrive fréquemment.

Facade, ça m'arrive aussi de devoir avoir à le faire.

Mais l'inversion de dépendance, vraiment, c'est le truc que je fais tout le temps.

Alexandre

La base.

Nicolas

Oui.

Alexandre

C'est qui les trois développeurs que tu admires le plus ? Ou peut-être un développeur que tu admires beaucoup ?

Nicolas

En fait, c'est plus difficile d'en choisir un que plusieurs. En tête qui me viennent, j'ai JB Rainsberger, qui pour moi, a été une grosse source d'apprentissage. Adam Tornhill aussi, toujours. Je suis beaucoup les travaux qu'il fait encore. Il creuse beaucoup sur l'IA, comment combiner ça avec les outils aujourd'hui pour le Legacy. J'aime beaucoup. Je pense à Emilly Bache aussi parce qu'elle fait toujours beaucoup de contenu pour le code legacy et pour la pratique, le coding kata, le coaching aussi qui est quelque chose dont j'ai besoin. Et après, il y a aussi Kent Beck, Martin Fowler, Michael Feathers.

En fait, tu vas voir la collection des livres que j'ai classés et tu regardes les auteurs. En général, ils ont eu une grosse influence sur qui je suis.

Et après, j'ai aussi des gens qui ne sont pas connus, mais qui, quand j'étais à OCTO, qui ont été mes mentors. Sebastien Rocassera ou Christophe Thibaut par exemple, qui sont deux noms qui me viennent en tête, ils m'ont aidé à apprendre beaucoup de choses quand j'étais + junior.

Alexandre

Chouette.

Est-ce que tu as un projet perso en ce moment ?

Nicolas

J'ai cette idée comme je te disais de cours sur les factoring qui me trotte dans la tête. Cette année, je voulais faire de nouvelles présentations avec le contenu que j'avais donc c'est ça qui m'occupe pour l'instant. J'ai deux présentations la semaine prochaine puis je vais les rejouer aussi plus tard dans l'année. Et d'un point de vue plus personnel, j'ai eu un deuxième enfant il y a six mois. c'est ma priorité. Sur mon temps libre, c'est ça qui m'occupe.

Alexandre

Ouais, c'est un gros projet !

Nicolas

Oui c'est ça. C'était aussi l'une des motivations de venir à Montréal il a sept ans, plutôt que de rester en région parisienne. C'était qu'ici, on a un rythme de vie qui nous permet plus d'avoir ce temps familial. Et pour moi, c'est important. J'ai une fille qui a cinq ans qui est autonome mais j'aime bien passer du temps avec elle, et j'ai un petit bout qui a six mois, ce qui veut dire que quand j'ai fini de travailler à 16 heures, ce qui n'est pas concevable à Paris, mais à 16 heures, quand j'ai finis de travailler je peux m'occuper de mon petit. C'est ça mon projet pour l'instant.

Alexandre

Trop bien.

Est-ce que tu as un mot pour la fin ? Ou un conseil ?

Nicolas

Oui, c'est plus un conseil. Donc là, je m'adresse plutôt aux gens qui souffrent un petit peu du legacy. On doit tous travailler du legacy à un moment ou à un autre. Et il a des gens qui le vivent plus difficilement que d'autres. Surtout des gens qui sont un peu passionnés par le code, qui ont appris plein de trucs et qui aimeraient les utiliser, puis ils regardent leur quotidien et ils disent, non, c'est pas faisable. À ces gens là je leur conseillerais si possible de rejoindre des communautés où il a d'autres personnes comme eux, parce que ça permet d'échanger, et aussi, mine de rien, d'avoir une soupape de décompression. Il y a les communautés Crafters qui existent pour ça. Et pour ceux qui n'en ont pas une à proximité, il y a Legacy Code Rocks, avec un slack. Toutes les semaines il y a une heure de meetup virtuel pour les gens qui veulent. Des fois, ne dis rien, j'écoute juste. Pendant une heure, les gens parlent. Alors évidemment de Legacy, mais en vrai de tout et de rien aussi. C'est vraiment une conversation d'une heure avec des gens qui travaillent avec du Legacy. Certains peuvent donner des conseils, peuvent répondre à des questions. Legacy Code Rocks, allez regarder ça. Ils ont un onglet communauté, et un Slack

Rejoindre une communauté, serait mon conseil principal.

Alexandre

Génial. Merci beaucoup Nicolas.

Nicolas

Merci à toi Alexandre.