Invité : Jonathan Boccara

Au programme :

• Ce qu'il ajouterai à The Legacy Code Programmer's Toolbox
• Les principes premiers derrière les design patterns
• La puissance des feuilles de calcul pour comprendre un code en profondeur
• Le truc pour écrire 2 articles par semaine
• Être régulier

Ressources évoquées dans l'épisode :

• 99 Bottles of OOP
• UML et les Design Patterns, Craig Larman (sur les grasp patterns)
• On Writing, de Stephen King
• Wait but why
• Soft Skills, de John Sonmez

Ressources de Jonathan :

• 105 STL Algorithms in Less Than an Hour 🤩
• World of design 💙
• fluentcpp.com (2016-2022)
• dailies

L'épisode

• Ausha
• Télécharger

Le podcast

Spaghetti to Bento

Transcription

Alexandre

Ok let's go pour ta bio. Tu as découvert le code avec un ami qui t'a montré un programme sur sa calculette où ça demandait te demandait ton nom et après ça te disait, "Salut Jonathan". Ça t'a bien intrigué. Ensuite, tu as fait l'école Nationale des Ponts et Chaussées - une grande école d'ingénierie générale. Tu n'as pas fait une spécialisation informatique, mais dans la spécialisation en finance. Même si j'imagine que tu as touché un peu l'informatique à ce moment-là aussi.

Jonathan Boccara

Un petit peu, oui.

Alexandre

Tu es parti comme analyste au UK. Mais tu n'as pas accroché a priori.

Jonathan Boccara

Pour le coup, j'ai pas mal accroché. J'étais plus trader en fait que Analyst. C'était pendant mon année de césure. Le contrat était défini pour une année et j'ai dû reprendre les études après.

Alexandre

Ok. Ensuite, ton premier poste dans la tech a été chez Murex, à cette intersection entre tech et finance. Tu as fait 10 ans là-bas. Je pense qu'on va pouvoir parler un peu.

Tu as fait 4 ans chez Doctolib ensuite.

Et là, tu viens de commencer chez Datadog.

Je t'ai découvert avec ton livre "The Legacy Code Programmers toolbox.

Et t'as aussi un blog que t'as tenu pendant 6 ans sur le C++ et sur Comment écrire du code expressif.

Tu as une expérience particulière avec les Dailys sur laquelle on reviendra.

Et tu as fait un site interactif avec une carte et plein de concepts autour du design logiciel.

Sur The Legacy Code Programmer's Toolbox, c'est un livre que tu as publié à six ans maintenant. Tu présentes des techniques concrètes pour, déjà changer de perspective vis-à-vis du Legacy Code. J'ai trouvé vraiment cette partie-là hyper intéressante. Tout ce qui est état d'esprit, mindset. Puis, ensuite, comment comprendre le code, comment le débugger, et comment finalement trouver du plaisir à travailler sur ce type de système legacy. Est-ce qu'aujourd'hui, il a des techniques que tu ajouterais à ce livre ?

Jonathan Boccara

Oui. Effectivement, depuis 6 ans, j'ai pu voir d'autres codebase, parler à d'autres personnes, parler à des personnes avec des métiers un peu différents aussi. Déjà, sur ce qui était vrai il 6 ans, beaucoup de choses restent vraies aujourd'hui - malgré le fait que beaucoup de technologies qui ont changées.

C'est assez impressionnant de voir à quel point les problèmes de legacy sont communs d'une boîte à l'autre. Et communs dans le temps. Ce qui est d'une certaine manière une bonne chose parce que du coup il y a des techniques qui s'affinent au fil des années et qui restent toujours valables. Maintenant, si je devais réécrire le livre aujourd'hui, pense qu'il a quelques trucs que je rajouterais. Un des gros trucs que je rajouterais, c'est l'observabilité, les logs, les métriques, etc.

En fait, il y a des choses qu'on a du mal à reproduire en local. Quand on peut reproduire en local, c'est presque gagné. c'est plus qu'une question de temps dans la plupart des cas. Mais il a des choses qu'on ne pas reproduire en local. Par exemple, les systèmes de caching - sur lesquels j'ai pu travailler depuis, où ça dépend beaucoup du trafic. Selon ce que l'utilisateur d'un site va chercher, ça va plus ou moins remplir le cache d'une certaine manière. Et si on voit des problèmes de performance parce qu'il a beaucoup de cache miss, ça dépend de comment les gens ont cherché, qu'est-ce qu'ils ont cherché, comment le cache s'est re-rempli. Du coup, c'est difficile à reproduire en local.

Pour suivre ce qui se passe, un moyen efficace est d'investir dans l'observability, donc d'avoir des métriques, des logs orientés sur ce qu'on recherche à déboguer ou des choses plus préventives, et ça, c'est un point que j'aurais rajouté.

Après, un autre domaine qui existait aussi il y a six ans, mais que j'ai eu l'occasion de plus creuser ces six dernières années, c'est sur le testing.

Quand j'ai écrit le livre, je n'avais pas beaucoup plus à rajouter sur le testing que ce qui est dans Working Effectively with Legacy Code de Michael Feather. Après, depuis, j'ai eu l'opportunité de causer plus le sujet, de voir des techniques comme les Approval Tests et les librairies d'approval testing, qui sont utiles pour un point de départ, pour se faire un environnement safe pour refactorer, et ensuite mettre d'autres types de tests.

Et ensuite justement sur les autres types de tests, quoi tester. Il y a plein d'endroits où on peut tester son code, mais tous n'ont pas la même valeur et la même difficulté. Du coup, ce n'est pas forcément un objectif qui vaut le coup de tout tester, d'avoir des tests sur tous les cas et sur toutes les méthodes, toutes les classes de son code. L'enjeu, c'est comment déterminer ce qu'il y a de la valeur à tester et qu'est-ce qui est, au contraire, parfois contre productif de tester.

C'est un sujet que j'ai pu explorer ces dernières années.

Alexandre

Ce serait quoi tes heuristiques sur ce qui vaut le coup d'être testé / ce qui ne vaut pas le coup d'être testé ?

Jonathan Boccara

Quand on écrit un test, c'est une forme de commitment envers le code qu'on teste, en tout cas envers l'interface du code qu'on teste.

Par exemple : on fait un test sur une méthode. Si on change l'interface de la méthode, je vous rajoute des paramètres par exemple, là le test, non seulement il ne sert pas à valider qu'on n'a rien cassé - parce du coup, il va être rouge parce que l'interface a changé, mais on ne pas si on a vraiment cassé quelque chose ou pas. Et en plus, il va nécessiter un travail supplémentaire pour le réécrire. Alors que quand on change l'implémentation d'une méthode, là on est content d'avoir les tests à l'interface de la méthode. Donc, quand on positionne des tests, on fige un peu les interfaces, on les rend plus difficiles à changer. Et des interfaces, il en a à tous les niveaux. Il n'y en a pas que dans les méthodes et les classes, il les modules, l'interface entre le backend et le frontend, et tout ce genre d'interfaces.

Il faut réfléchir à quelle interface on a envie de se comitter. Et celle-là, on peut la courir de test. Des interfaces où on sent qu'elles sont un peu fragiles, on sent qu'elles ne sont pas très bien définies, notamment dans du Code Legacy, si on rajoute des tests à cet endroit-là, souvent les tests vont être difficiles à écrire. Il va falloir mocker pas mal de choses par exemple. Et au final, c'est des tests qui ne vont pas avoir beaucoup de valeur et qui vont même parfois demander du travail en plus.

Alexandre

OK.

Jonathan Boccara

Sur tout ce sujet d'ailleurs, je ne sais pas si tu l'avais vu, j'avais fait un talk à Devoxx sur ce sujet-là avec pas mal de détails.

Alexandre

J'ai l'impression qu'il y a toujours cette tension entre tu as envie de mettre tes tests le plus haut possible parce que tu couvres le code et ses branchements, mais c'est des tests qui sont plus difficiles à instancier potentiellement t'as pas mal de dépendance que tu dois substituer. Donc c'est plus facile d'aller tester des fonctions directement, mais derrière, tu te retrouves avec un test qui sont couplés à l'implémentation. Ou alors à une interface, mais qui est basse. Il y a un équilibre à trouver entre ces deux placements, positions.

Jonathan Boccara

Ouais, tout à fait.

Alors. Si c'est un algorithme qui est au fond du code mais qui est stable, par exemple chercher une sub-string dans une string, alors, il y a deux axes. En termes de stabilité de l'interface, c'est plutôt stable. Parce que c'est des trucs assez standard. Un truc qui est assez bas niveau et stable, ça ne coûte pas beaucoup de maintenance de les tester. Par contre, termes de valeur ajoutée sur l'ensemble de la reprise en main d'une codebase legacy, avoir un test au fin fond du code sur une fonction, ça ne va pas forcément aider à faire des changements structurels de cette base de code là. Alors que faire des tests un peu globaux, ça va faire une sorte d'échafaudage pour commencer. Après comme tu dis, ils sont parfois plus difficiles à écrire parce qu'il a des choses à mocker.

Alexandre

Oui.

Jonathan Boccara

Ou parfois au contraire, moins difficile à écrire parce qu'ils n'ont pas besoin de se positionner au milieu du sac de nœud.

Le plus extérieur, c'est par exemple, pour un site web, des tests qui vont lancer un navigateur, cliquer sur la page et asserter qu'il y a ce qu'il faut sur la page. Ceux-là sont faciles à écrire. Il suffit de décrire des actions d'utilisateurs. Il a des outils qui permettent de faire ça super facilement dans du code, par exemple Selenium.

Donc ils sont faciles à écrire. ça peut être un point de départ. Puis c'est bien d'en avoir. C'est une forme de certitude qu'on réplique l'expérience utilisateur.

Après, ça ne va pas bien scaler, dans le sens où si on veut couvrir toutes les combinaisons de tous les use cases du site, il va falloir en écrire énormément. ça fait beaucoup de tests. Ce n'est pas facile à maintenir. En plus, c'est long d'ouvrir un navigateur, d'interagir avec lui etc. Ils vont être plus longs en terme de feedback loop, plus cher en termes de compute sur la CI. C'est pas la panacée.

Un principe qui me guide quand j'écris les tests, c'est de le baser sur les interfaces sur lesquelles on est prêt à comitter, et de faire des tests à l'intérieur du code (plutôt qu'a travers le navigateur). En construisant ces interfaces-là, si besoin, en se basant sur des tests plus externes pour commencer comme un échafaudage, quitte à ne pas les garder après dans la CI.

Alexandre

Ok. Sur les autres techniques que tu présentes, comme la technique de compter les mots pour identifier les personnages principaux d'une longue fonction, ça, finalement, est-ce que un LLM, si tu lui files ta fonction, que tu lui demandes quels sont les personnages principaux, quelle histoire ça raconte. Est-ce qu'il n'est pas encore plus fort que ces techniques ? Ou est-ce que ce sont des techniques qui restent utiles ?

Jonathan Boccara

Oui, effectivement ça, il a des choses qui marchent plutôt bien avec les LLM.

Après, ils ne sont pas encore autonomes, de mon expérience. Ce que j'ai essayé de faire, c'est un peu de le guider, par exemple copilote. Et de dire par exemple : on a un fichier qui fait 2000 lignes, je ne sais pas ce qu'il y a dedans, je sais qui est important, aide-moi à comprendre.

Là où ça a plutôt bien marché, c'est en le guidant. En disant par exemple, je sais qu'il y a telle fonction qui est importante dans le code dans ce fichier, explique-moi les choses principales, donne-moi le happy path de ce fichier, en faisant bien attention de parler de cette fonction-là. Et ça, a plutôt bien marché. J'étais impressionné en fait qu'il réussit à faire un peu comme ce que je décris dans le livre, de se focus sur les lignes principales. Il m'a même réécrit du code, une sorte de pseudocode, en ne gardant que les lignes principales. Et ça, c'était vraiment impressionnant.

Après, ce n'était pas parfait. Un autre truc que j'ai fait sur ce cas-là, c'est lui demander de générer des diagrammes de séquence en Mermaid (donc en code). Mermaid, c'est une forme de Markdown pour générer des diagrammes. Et ça, il le fait très bien. J'ai présenté ces résultats à des personnes qui bossaient sur ce code pour voir si ça correspondait à ce qu'ils connaissaient, et dans l'ensemble ça correspondait. Mais il manquait des choses. Des choses importantes dans le fichier en question qui n'étaient pas mentionnées. Donc dans mon expérience, ça n'a pas été parfait. Il n'a pas remplacé complètement une personne.

Après là où ça marche bien, je trouve, c'est quand tu surlignes une petite partie et que lui poses des questions spécifiques, genre, "est-ce que je pourrais écrire ce truc-là de manière plus idiomatique", ça marche plutôt bien je trouve.

Dans tous les cas, dans mon expérience, ce qui a été le plus productif, c'était de le guider de façon rapprochée. De l'utiliser vraiment comme un copilote plutôt que le laisser partir sur des grosses tâches avec des résultats qui n'étaient pas à 100 % exacts.

Alexandre

OK. Et donc ce diagramme-là, est-ce que tu l'as gardé et t'as itéré dessus ou est-ce que tu l'as juste repris de zéro pour le faire toi-même ?

Jonathan Boccara

J'ai itéré dessus avec le LLM.

Alexandre

Parfois, fait de le faire, de le construire à la main, fait partie du processus pour l'intégrer mentalement.

Jonathan Boccara

Oui, tout à fait. Après, je pense que ça dépend pas mal du niveau de compréhension qu'on a besoin d'acquérir du code. Si on a besoin de niveau de compréhension vraiment fin, je pense que c'est bien de l'acquérir soi-même. Après, si on a envie de faire connaissance avec une grosse code base, on peut avoir un niveau de connaissance qui n'est pas hyper précis, on veut savoir dans les grandes lignes ce qui se passe, et du coup de couvrir beaucoup de code rapidement.

Alexandre

Tu parles peu de refactoring dans le livre, est-ce parce que c'est déjà bien couvert par d'autres livres ? Ou est-ce c'est pour une autre raison ?

Jonathan Boccara

Alors effectivement, ce n'est pas un livre de refactoring, même s'il a un chapitre sur le refactoring et sur comment raccourcir des fonctions très longues. à l'époque où j'avais écrit, il y avait déjà le livre de Martin Fowler, qui s'appelle Refactoring et qui rentre beaucoup dans les détails. Ce que j'ai voulu rajouter, c'était plutôt un autre point de vue, de mon expérience personnelle où j'avais eu pas mal à faire à des fonctions très longues. Donc j'ai voulu consacrer un chapitre à ça.

Après, sur le refactoring, il y a un livre qui a été "eye-opener" comme on dit, qui m'a ouvert les yeux, que j'ai lu plus tard, qui s'appelle 99 Bottles of OOP de Sandi Metz qui quelqu'un d'assez connu dans le monde du Ruby.

C'est tout un livre qui explique le principe open-close. Le O de SOLID. Le principe open-close de SOLID, c'est-à-dire que le code doit être open pour l'extension et close pour la modification. Ce que j'avais jamais compris. Parce que s'il est open pour l'extension, veut dire qu'on va le modifier, donc il n'est pas close pour les modifications. Ça a été flou pour moi, ce O. Et en fait, dans son livre, elle explique comment faire pour refactorer son code, pour faire en sorte que quand on a besoin de nouvelles features, on n'ai que du code à rajouter - et pas du code à modifier. Ça veut dire comment faire avec du refactoring pour ramener le code dans cet état qui s'appelle open-closed, qui est le O de SOLID et donné comme une bonne chose.

Ce qui est vraiment très intéressant dans son livre, c'est déjà de comprendre ce principe.

Tout le livre, c'est sur un Kata.

Il y a une petite fonction qui génère les strophes d'une contine qui s'appelle 99 bouteilles de lait. Et toutes les strophes sont quasiment pareilles. Sauf la dernière qui est très différente et l'avant dernière qui est un petit peu différente. Elle propose au début du livre : essayez d'écrire le code vous-même. Donc t'écris. T'arrives tant bien que mal à écrire le code qui génère la comptine, mais on se rends compte que le code est compliqué. Et elle te propose des manières de le réécrire, de le refactorer de manière extrêmement incrémentale, pour arriver tranquillement dans un état open-close.

Ce livre-là, franchement, il a changé ma manière de refactorer du code.

Alexandre

Ok. Tu penses que c'est un bouquin à lire même si tu ne fais pas du Ruby ?

Jonathan Boccara

Oui, surtout qu'il est décliné dans plusieurs langages. Il est décliné en JS, PhP, Python aussi.

Alexandre

Ok.

Jonathan Boccara

Il n'y a pas besoin d'être expert du Ruby ou du JS pour comprendre les principes.

Alexandre

Super.

Lorsqu'on rencompte du code complexe, ça génère une réaction assez primaire chez nous. Des fois, t'as presque en vague d'envie de frapper la personne, de jeter la table, de démissionner. Finalement, c'est assez humain, on partage tous ce truc.

Tu conseilles de renverser la perspective pour faire de cet événement une opportunité d'apprendre, un événement heureux. Et l'idée, c'est d'élaborer sur "pourquoi est-ce que je n'aime pas ce code ?", "quelles leçons je peux en tirer ?". Est-ce que tu t'es retrouvé dans des situations comme ça récemment ?

Jonathan Boccara

C'est primitif oui.

On se retrouve souvent dans des situations où on est dépassé par du code qu'on ne comprend pas. Après, dire "j'aime pas ce code", c'est un côté un peu défouloir, mais ça n'amène pas à quelque chose de productif. Comme ce que tu citais, essayer d'élaborer très spécifiquement sur pourquoi est qu'on n'aime pas un code, ça a plusieurs vertus.

Déjà ça permet de mieux comprendr. En disant, je n'aime pas pour telle raison : parce qu'il y marqué X, ou qu'il y a telle expression. Et en fait quand on creuse, on se dit, en fait, en regardant ça de plus près, je comprends mieux pourquoi il a cette expression là. Ça répond à tel edge case, ça a un petit peu tel problème, etc. Du coup, on a moins d'animosité déjà envers ce code. Et puis bon parfois ça arrive quand on tombe sur des codes qui peuvent être mieux écrits.

Et puis, ça afute notre capacité à lire du code, à comprendre du code, à détecter ce qui est problématique et à trouver des idées pour le fixer.

Alexandre

Est-ce que tu le notes quelque part ? Ou tu fais l'exercice mentalement ?

Jonathan Boccara

Sur des petits bouts, je le fais mentalement. Si c'est une lecture assez longue, une grosse partie de code par exemple, je le note, parce que on va pas forcément pouvoir tout fixer, et avoir une liste, ça permet après de prioriser.

Alexandre

OK.

Ton livre se concentre beaucoup sur les fonctions ? Est-ce qu'il n'y a rien à propos des classes ? Est-ce qu'une classe finalement, c'est juste une grosse fonction ?

Jonathan Boccara

C'est une bonne question.

Il y a plusieurs choses.

Les problèmes de design sur des classes, souvent, ils vont se retrouver dans les méthodes de cette classe. Typiquement, un problème de design sur une classe, c'est que la classe, fait trop de trucs, elle a trop de responsabilités par exemple.

Là où ça va être problématique, c'est quand dans les méthodes de cette classe, du code mêle ces différentes responsabilités-là. Si c'était une classe qui avait plusieurs responsabilités, qui avait deux responsabilités et deux sets de méthodes complètement indépendants qui s'occupaient chacun de leurs responsabilités, ce serait beaucoup moins problématique, beaucoup moins difficile à comprendre. Du coup, les problèmes de compréhension vont se trouver souvent au niveau de l'intérieur des méthodes.

Ceci dit, le sujet de class design, c'est plus vaste que comment écrire le code des classes. C'est les décisions de quelles responsabilités associer à quelle classe. Et ça, c'est le sujet du design de classe dont je ne parle pas dans mon livre, parce que ce n'est pas tellement ce scope-là, mais dont je parle sur le site, sur le design de classe que j'ai fait, qui s'appelle World of Design, et qui parle de comment assigner des responsabilités des classes.

Alexandre

OK.

Il y a beaucoup de concepts que tu as documentés sur ce site. C'est quoi les ressources qui t'ont le plus servies ?

Jonathan Boccara

Le site présente plein de concepts de design. Et l'objectif, c'est de mettre de l'ordre dans tous ces termes.

Déjà de les définir. Il y a par exemple les designs patterns, il y en a plus d'une vingtaine, il a les GRASP pattern. Les grasps pattern, c'est quelque chose qui est un peu moins connu que les design patterns, mais qui gagne à être connu. Peut-être même plus connu que les design patterns.

Dans les initiales de GRASP, les plus importants c'est RA : Responsability Assignment. Et en fait, c'est des principes qui guident la décision de "dans quelle classe je mets quelle responsabilité".

Je les ai appris dans un livre de Craig Larman qui s'appelle UML et les Design Patterns. C'est un livre de design, beaucoup, un peu d'UML, et il parle de ces principes-là qui sont plus générales que les Design & Pattern.

Ce que je montre sur le site, c'est comment les design patterns sont en fait des implémentations de ces GRASP patterns.

Le site qui est sous forme de map, de carte. Il associe une ville sur la carte à un concept de design : un design patern, un GRASP principle ou encore d'autres concepts de design. Dans chaque ville, tu cliques, ça t'ouvre un article pour t'expliquer le concept, et il te montre les connexions entre chaque concept à partir des éléments sur la carte.

Il des rivières qui coulent d'une ville à l'autre. Quand une rivière coule de la ville A à la ville B, ça veut dire que A est une manière d'implémenter B. Et au final, toutes les villes, toutes les rivières, par exemple, convergent vers la même mer parce que tous les concepts de design ont pour un seul, ont pour le même but de rendre le plus facile à changer.

Donc le thème de la mer, c'est rendre le code facile à changer.

Et les principes GRASP permettent de faire ça. Les designs patternes permettent d'accomplir les principes de GRASP. Et au final, le but de tout ça, c'est de rendre le plus code plus facile à changer. **Ce qui fait comme corollaire que si on fait un design pattern qui ne rend pas le plus facile à changer, c'est peut-être pas la peine de le faire. C'est pas la peine de faire des patterns juste pour le principe d'en faire

Alexandre

OK.

Pour toi, c'est le goal ultime du design: de rendre le code plus facile à changer.

Jonathan Boccara

Oui.

Alexandre

Est-ce que tu as un concept de design favori ?

Jonathan Boccara

Je les aime bien tous.

Après, il y en a un qui est beaucoup plus profond que ce qu'il en a l'air en première vue, c'est le polymorphisme. Quand on dit polymorphisme, on entend souvent classe mère, méthode virtuelle, méthodes de classe fille, override, etc. Et on pense à ça quand on pense au polymorphisme. Alors qu'en vrai, c'est juste une manière de faire du polymorphisme parmi un nombre de manières assez énormes.

Le fait de faire des méthodes virtuelles, des classes mères, de l'héritage, etc. C'est du polymorphisme au niveau des classes, du polymorphisme au niveau du runtime, et du polymorphisme qui résout un seul objet à la fois. C'est-à-dire qu'on a une interface, on invoque une méthode sur cette interface et au runtime, le runtime détermine quelle implémentation il s'agit pour un objet. Ça, c'est assez courant dans les langages mainstream, par exemple Java.

Mais en théorie, on pourrait faire ça sur plus qu'un objet à la fois. On pourrait avoir plusieurs objets polymorphiques qui interviennent dans la même expression et on pourrait avoir un appel polymorphique qui résout tous les objets à la fois. Alors, ce n'est pas forcément possible dans tous les langages, mais il a des langages où c'est possible et naturel.

Je prends un exemple, en C++. Il y a aussi ça, un peu comme Java : les héritages, les méthodes virtuelles etc. Mais il aussi d'autres types de polymorphismes. Par exemple les templates en C++. Les templates, c'est des classes, c'est des types, dont les paramètres peuvent être d'autres types. Alors, exemple tout simple, tu prends une liste en C++, ça te fait un vecteur de T. C'est une classe, une liste d'objets de type T, et c'est une classe dont le paramètre est un type qui est T. Donc ça paraît une construction assez alambiquée pour dire quelque chose de simple. Mais en fait, on peut avoir dans les templates plus qu'un seul paramètre. On peut avoir un template qui dépend des types A, B, C par exemple. Et du coup quand on instancie un template avec des types précis, des types concrets, il y a simultanément tous les types qui vont se trouver instanciés.

Et ça, c'est du coup un type de polymorphisme qui est complètement différent parce qu'il n'est pas que sur un seul type, est sur plusieurs types. Dans le langage du polymorphisme, ça s'appelle du multiple dispatch - au lieu de single dispatch.

Contrairement à l'héritage, c'est quelque chose qui ne pas se passer au niveau du runtime mais qui va se passer au moment de la compilation. C'est là que ça va être résolu. Et donc, on voit deux types de polymorphismes qui sont très différents.

En fait, il y a plusieurs axes dans les polymorphismes. Le premier, c'est à quel moment est-ce qu'il va être résolu. Est-ce que c'est vers la compilation runtime ou encore à d'autres moments. Au niveau du pré-processeur, au premier chargement du code dans le runtime, au moment du link pour les langages keylink.

Un autre axe, c'est combien d'entités vont se faire résoudre au même moment, le nombre de dispatch.

Il y a comme ça plusieurs axes, et sur chaque axe, on a plusieurs valeurs possibles. Après, chaque langage permet de faire une certaine combinaison. Et du coup, le polymorphisme dans son ensemble, c'est plutôt une façon de créer de la modularité en disant, il y a d'un côté un client, d'un autre côté une implementation, au milieu une interface qui va pouvoir diriger le client vers plusieurs implementations, et le but, c'est de faire de la modularité pour que les deux soient indépendants.

Alexandre

Ok, ça va plus loin que juste une stratégie avec une interface et plusieurs classes d'implémentation.

C'est un truc dont tu te sers / donc tu aimes bien te servir ?

Jonathan Boccara

Oui, pour le coup oui. En C++ sur le polymorphisme avec des templates, ça j'en ai fait pas mal ouais. ça donne un peu plus de perspectives, même les design patterns. Par exemple, celui qui va bien avec ça, c'est le Visitor.

Dans Visitor, il y a cette espèce de ping-pong entre celui qui accepte et celui qui visite. Quand on découvre le pattern, en regardant juste comment l'implémenter c'est un peu difficile de prendre le recul, de pourquoi est-ce qu'il en a qui acceptent, qui visite et puis on a un peu de mal à entrer dans sa tête, quelle classe est résolue, à quel moment. Et en fait, le Visitor, ce qu'il permet de faire entre autres, c'est du double dispatch. C'est d'avoir plusieurs hiérarchies. Une hiérarchie d'objets, une hiérarchie de Visitor, et d'écrire du code pour chaque combinaison.

Ça veut dire qu'on a une hiérarchie de A, une hiérarchie de B. Dans A, y a A1, A2, A3 comme classe filles. Dans la hiérarchie de B, B1, B2, B3 comme classes filles. Le Visitor permet d'écrire du code de qu'est-ce qui se passe quand A1 vient visiter B1, quand A1 vient visiter B2, etc. Et de faire avec cette espèce d'aller-retour entre l'Accept et le Visit, une émulation de Double Dispatch, en disant, on ne les résout pas simultanément dans le langage qui permet de résoudre simultanément du polymorphisme de mon runtime, on les résout l'un après l'autre, ou chacun appelle l'autre pour se résoudre. Mais le résultat est d'avoir du double dispatch, de permettre d'écrire du code sur les différentes combinaisons des classes filles.

Alexandre

Est-ce que tu as un exemple un peu concret en tête ?

Jonathan Boccara

Il y en a sur World of Design pour coup. Si tu ouvres la page du visiteur, tu vas trouver pas mal de choses sur ça.

Alexandre

Ok.

Jonathan Boccara

Ou si tu veux, j'avais écrit un article qui parle de ça sur Fluent C++. Si tu cherches Visitor sur Fluent C++, tu vas tomber sur un article qui détaille ça.

Alexandre

Ok, j'irai creuser.

Quel concept est sous-estimé ? Est-ce c'est le polymorphisme aussi ou est-ce que c'est un autre concept ?

Jonathan Boccara

Par rapport à ce qu'on a dit oui, le polymorphisme. Parfois, on ne voit que la partie émergée de l'iceberg.

Après sur les autres, je ne saurais pas dire vraiment lesquels sont sous-estimés. Je pense que c'est déjà bien de les connaître tous. Après si on les connaît tous et qu'il en a qu'on exploite un peu moins que d'autres.

Un deuxième niveau est d'aller creuser en profondeur chacun, mais je pense qu'il y déjà une première phase à bien connaître tous les concepts.

Alexandre

Ok.

Tu as ton email qui affiché en clair sur le site. Est-ce que tu ne reçois pas du spam ?

Jonathan Boccara

Pas énormément. C'est raisonnable. Et après, le spam n'est pas très méchant. C'est souvent des personnes qui veulent avoir des guest post sur mon blog, donc écrire sur mon blog pour pouvoir mettre des liens qui référencent leur site, mais qui proposent des articles qui n'ont rien à voir avec le thème du blog.

Mais dans le lot, y a quand même des gens qui écrivent des vrais messages, des vraies questions, des vraies remarques, des vraies suggestions, des propositions, etc. qui sont beaucoup plus intéressantes. Et donc l'un dans l'autre, ça en vaut la peine.

Alexandre

Tu mentionnes quelque part On Writing de Stephen King. C'est un livre que lu pour ton blog ou que tu as lu pour le Software Engineering ?

Jonathan Boccara

C'est un livre que j'ai lu pour mon blog. En fait, pour essayer de mieux écrire, mieux écrire des articles, j'essaie de lire des choses sur les auteurs qui écrivent dans un style où moi, personnellement, j'accroche beaucoup. Stephen King, c'est un auteur de mes auteurs préféré en roman. Il écrit des romans qui sont énormes, mais qui se lise facilement. Je peux en lire pendant des heures sans me lasser, au contraire. J'ai l'impression d'améliorer mon anglais quand je lis Stephen King, et j'ai l'impression de presque de voir un film quand je lis un livre tellement les descriptions et le style sont saisissants et accrocheurs.

Je me suis dit que je pouvais améliorer mon style d'écriture en essayant d'aller dans cette direction-là - sans viser d'atteindre un niveau professionnel comme ça.

Du coup, j'ai lu ce livre qui s'appelle On Writing et qui est assez intéressant, qui est à mi-chemin entre un livre de comment bien écrire et une autobiographie. Il faut être intéressé par l'auteur si on veut arriver à accrocher au livre. Mais il a quand même des conseils très concrets. Par exemple, deux conseils sur lesquels il revient souvent, c'est d'éviter le passif et d'éviter les adverbes. Ce que je n'aurais jamais deviné tout seul. Il te montre des exemples, comment avec, comment sans, etc. Tu vois que c'est une différence, et ça te permet de fluidifier ton style, d'avoir moins de décisions à prendre quand tu écris. Tu prends des habitudes d'écrire dans un certain style.

Ça, c'est une des deux sources d'inspiration sur le style d'écriture.

La deuxième, aucun rapport, c'est un blog qui s'appelle Wait But Why. Et pareil, son style d'écriture, je le trouve vraiment très accrocheur. C'est comme si tu scrollais sur les réseaux sociaux où il y a des algorithmes qui font que tu vas rester accroché le plus longtemps possible. Mais lui, il fait un peu ça sans le faire exprès je pense, avec son style d'écriture. En tout cas, je me trouve des fois vraiment happé par ce style, et j'aimerais bien que le mien ressemble plus à ça.

Alexandre

Ouais. Ses articles sont hyper bien construit. Ils s'enchaînent super bien. Sa logique qui hyper claire. Et les petits dessins qui sont marrants.

Jonathan Boccara

Ouais. Et dans la formation des phrases, il a un style qui super impactant.

Alexandre

Je n'ai jamais essayé d'analyser son style. Mais à faire.

Jonathan Boccara

Si tu veux écrire sur un blog avec une fréquence régulière, il te faut du contenu. Donc, pour être capable d'écrire ce contenu, il faut que tu l'aies toi-même assimilé. ça te force quand même à apprendre beaucoup de choses. Une source d'inspiration pour les idées que j'ai eues sur mon blog, c'est de regarder autour de moi au quotidien. C'est-à-dire au travail, de faire attention aux choses qui vont bien, aux choses qui ne vont pas bien. Quand je vois des gens qui améliorent des choses, j'essaye de comprendre qu'est-ce qu'ils ont fait, pourquoi ils l'ont fait, etc. Et du coup, on s'intéresse à beaucoup plus de choses. Et donc, naturellement, on apprend avec.

Alexandre

Ok. Je me demandais ce qu'est ton secret pour écrire deux articles par semaine, parce que ça me paraît beaucoup. Je me demandais où est-ce que tu trouves les sujets. Et en fait, quand tu te dis que va écrire deux articles par semaine, là d'un coup, tu te mets à les voir autour de toi.

Jonathan Boccara

Alors c'est presque ça.

Ce que tu vois sur le site, c'est que je publie deux articles par semaine. Mais en réalité, à l'époque où je publiais deux articles par semaine, j'en écrivais trois par semaine, pour être sûr d'avoir toujours deux articles par semaine. parce qu'il y a des fois où t'as à la grippe, tu es couché au lit. Tu ne peux pas écrire ton article. Ou tu pars en vacances, ou que sais-je.

Et pour écrire trois articles par semaine, je trouvais quatre idées par semaine. Parce que parfois, il y a des idées qui n'aboutissent pas forcément. Il y a des idées que tu as eues, et quand tu écris un article, tu ne te rappelles plus vraiment les détails de l'idée. Et ouais. Pour générer des idées, il a beaucoup de regarder autour de soi dans le quotidien du travail. Genre, quand on est développeur, on est tout le temps exposé à des situations intéressantes, techniques. Et Discuter avec des gens aussi.

Quand tu te lances un peu dans le monde du blogging, tu rencontres assez naturellement les autres personnes dans ta sphère. Que ce soit des lecteurs, des blogueurs, des conférenciers, ou des gens qui vont assister à des conférences comme toi. Tu rencontres des gens, tu discutes, et tu t'entends en parler de pas mal de choses, tu découvres beaucoup.

Alexandre

Et qu'est-ce que tu as commencé en premier ? Est-ce que c'était ton blog, ou est-ce que c'était les Dailys ?

Jonathan Boccara

les Dailies.

C'est vraiment la première chose que j'ai faite dans tout ce monde-là.

Les Dailies, c'est un format de présentation auquel j'ai pensé, qui est de faire une présentation tous les jours à une équipe, mais qui ne dure que dix minutes, et toujours dans le même thème. En 2016, j'avais commencé le Daily C++. Je donnais à mes collègues une présentation de C++ qui durait 10 minutes sur un thème donné chaque jour, et globalement tous les jours sur le thème du C++.

Au début, je le faisais avec mon équipe. On était une petite dizaine. Ensuite, mon équipe et l'équipe dans le box à côté. Et puis ça a suscité pas mal d'enthousiasme. Des gens d'autres équipes qui venaient de 11h à 11h10 dans notre bureau pour écouter le daily, et puis ça a fait pas mal d'intérêt même pour d'autres qui ont dit "bah moi je connais tel autre domaine, je vais lancer mon daily" et puis il y a eu des daily qui se sont mis à poper dans notre boîte un peu partout.

A un moment, on pouvait plus faire rentrer tout le monde. On ne pouvait faire rentrer que plusieurs dizaines de personnes dans notre box, donc j'ai refait les daily à d'autres équipes. Il y avait comme des saisons, avec des rediffusions des dailies, mais toujours en présentiel, comme ça les personnes pouvaient écouter C'était délivré chez eux. Il n'y pas besoin d'aller se connecter et regarder une vidéo - même si c'était aussi enregistré en vidéo.

Ces dailies, ça m'a donné un point de départ pour partager de la connaissance et trouver un peu ma voix sur le thème. C'est ça qui a un peu bootstrappé le contenu de Fluent C++ de mon blog. Ça a commencé à me faire du contenu et puis on a pu continuer dans la même direction tout en maintenant les dailies.

Alexandre

Ok. Et un truc qui me marque, c'est que tu étais relativement junior quand tu as commencé à faire ça. Tu avais 4 ans, donc c'est beaucoup et pas beaucoup à la fois. Surtout dans une boîte où il a des personnes qui étaient beaucoup plus seniors que toi. Et est-ce que ce n'est pas un peu bizarre de prendre cette posture de je vais vous partager des choses quand tu as des personnes qui sont beaucoup plus expertes ?

Jonathan Boccara

C'est vrai que chez Murex, il y a beaucoup de développeurs. Et c'est vrai qu'il avait des développeurs de toutes expériences, y compris des gens très très seniors.

Mais pour répondre à ta question, non, ça n'a pas été bizarre. En fait, le but, c'est de partager des connaissances. Et un développeur qui a 5 ans d'expérience, il ne connaît pas forcément "tout ce qu'un développeur de 4 ans connaît" + des choses. C'est plutôt, chacun suit son chemin. Chacun rencontre les problèmes techniques qu'il rencontre et s'intéresse à ce qu'il s'intéresse. Tout le monde a des choses à partager, même assez tôt dans leur carrière.

En se plaçant dans une posture de "j'ai trouvé quelque chose d'intéressant, je veux le partager", tu ne dis pas forcément que tu as la vérité. Des fois, on présente et on fait des erreurs. C'est l'occasion de se faire corriger un peu ce qu'on connaît, et c'est aussi ok.

Je pense que ça dépend aussi de l'état d'esprit, de la présentation et comment elle a communiqué, mais en tout cas non, ça n'a jamais été bizarre au contraire.

Alexandre

Ok, donc ça n'a pas généré de défiance, ça a été plutôt bien reçu.

Jonathan Boccara

Oui, ça a été très bien reçu. Au contraire, ça a plutôt généré l'émulation.

Alexandre

Est-ce que tu as eu des feedbacks de personnes qui l'ont implémenté dans d'autres entreprises ?

Jonathan Boccara

Ouai.

Quand on l'avait un petit peu au rodé chez Murex, on s'était dit que ça serait bien de le partager un peu plus à l'extérieur. Du coup, j'ai fais une présentation à Devoxx sur les Dailies. J'en ai parlé aussi sur mon blog. J'essaie d'en parler à différents endroits.

Des personnes qui l'ont essayé dans leur boîte, qui m'ont fait le feedback, qui avaient parfois des questions de ce que le sujet est pertinent pour tenir en 10 minutes, ou qui avaient des feedbacks, genre "voilà, j'ai parlé de ça, ça vient de passer", ou "j'ai parlé de ça, il y a des choses à corriger". Donc ouais, pas mal de gens qui ont essayé.

Alexandre

C'est vrai qu'en plus, quand tu présentes un truc et que tu te trompes, on te corrige. Et c'est hyper puissant. Le fait de se tromper en public et qu'on t'apporte une correction, en général, tu t'en souviens.

Jonathan Boccara

Oui, c'est clair.

Il ne faut pas avoir peur de se tromper.

Sinon on ne se lance pas.

Et puis si jamais on a peur de se tromper, le jour où on se fait corriger, ce n'est pas facile effectivement.

Ça pour le coup, c'est un truc que j'ai pu apprendre en écrivant en public, en bloguant par exemple, et en donnant des conférences. Il y a toujours des gens qui ne vont pas être d'accord. Et souvent c'est bien. Toi, tu apprends d'autres perspectives, tu t'enrichis. Et puis, il y a des gens qui ne vont juste pas aimer ce que tu fais, et qui ne vont pas hésiter à le dire. Rarement en personne, souvent sur Internet.

Alexandre

Ok.

Jonathan Boccara

Et du coup, il faut avoir un minimum de la peau dure, sinon c'est difficile.

Ce que j'avais vu sur ça, c'est un truc intéressant de John Sonmez. Il conseille de prendre les critiques comme de la data. De prendre les critiques comme des gens qui n'aiment pas ce que tu fais, et de dire ok, ça me fait un point de data. Ils n'ont pas aimé pour telle et telle raison, et puis tu accumules les points comme ça.

Bon, tu essaies de ne pas en accumuler de trop non plus. Mais ça te donne du feedback en fait sur ce que tu as à améliorer. Et puis ne pas le prendre personnellement, même si parfois, il a des personnes qui le font sur un ton où eux, ils ont l'air de le prendre personnellement - alors que tu parles de code.

Alexandre

C'est vrai que tu expliques que c'est en lisant un livre de John Sonmez que tu as l'envie de démarrer ton blog.

Jonathan Boccara

Oui, tout à fait.

C'est un livre qui s'appelle Soft skills, qui est un livre qui target les développeurs, mais pas sur des sujets techniques. Donc ça va parler de productivité, de blogging, de présentation, tout plein de sujets sur lesquels en tant que développeurs, on n'est pas spécialement bons. Les sujets de learning, généralement, c'est plutôt quelque chose qu'on aime bien. Mais il y a pas mal de sujets, comme les finances personnelles, sur lesquels on est pas forcément très très bien instruit. Il donne pas mal de détails sur un ton très clair, et j'avais trouvé ça utile et inspirant. Après, c'est un personnage parfois controversé, mais ça n'enlève rien, je trouve, à la qualité des messages de son livre.

Alexandre

Ah, je ne connais pas ses controverses.

Est-ce qu'il a d'autres choses que tu retires de ce livre ?

Jonathan Boccara

ça fait longtemps que je l'ai vu, c'était avant les dailies, donc ça va faire bientôt 10 ans.

Il incite beaucoup sur la régularité, déclinée sous toutes les formes. Quand tu blogs, ce qui fait ou pas le succès d'un blog. C'est être régulier sur la fréquence, régulier sur la qualité, régulier sur le thème.

Il parle aussi de la régularité dans l'apprentissage, de la régularité dans ton schedule de la semaine, la régularité quand tu vas naturellement rencontrer un mur parce que tu t'es attaqué à un projet un peu ambitieux et malgré tout trouver des routines dans ces cas-là aussi qui vont te permettre de ne pas laisser tomber ou de ne pas procrastiner.

C'est un des thèmes du livre.

Après, il y a beaucoup de choses dans le livre. Il y a 70 chapitres qui font chacun 3-4 pages et où il aborde des thèmes très différents.

Alexandre

Ok.

Sur ton expérience avec DotoLib, tu as fait plusieurs articles de blog, qui sont vraiment hyper riches. A un moment, tu expliques que pour développer une feature dans une codebase complexe, vous avez répertorié toutes les fonctions, vous les avez mis dans une feuille de calcul, je n'ai pas bien compris ce que vous avez fait avec. Est-ce que tu peux en parler un peu plus ?

Jonathan Boccara

Oui bien sûr. En fait, ce sujet-là, ça s'inscrit dans un thème qui est indépendant de Doctolib, c'est à quel point tu as besoin de comprendre du code. On l'a un peu évoqué tout à l'heure. Est-ce que tu as besoin d'une vue de haut niveau pour comprendre comment les composants voisins du tien interagissent avec le tien par exemple ? Ou est-ce que tu as besoin de comprendre de manière très détaillée. Ou entre les deux.

Là en l'occurrence, on avait besoin de comprendre de manière très détaillée. Comme j'explique dans l'article, c'était une feature assez élaborée, on avait besoin de faire des transformations assez en profondeur dans le code, et c'était un code plutôt critique. Et du coup, il fallait vraiment bien le comprendre. Là, ce que j'avais fait, c'était de se dire, il faut comprendre chaque fonction.

Alexandre

Ok.

Jonathan Boccara

Du coup, j'avais listé toutes les fonctions dans une spreadsheet. Chaque fonction, je la lisais. Si je ne comprenais pas, je regardais quelle fonction elle appelait. Enfin, j'essayais de voir un peu, pas juste lire le code de haut en bas, mais voir un peu, comme quand on dit du code en général, voir comment il s'interagit avec les autres parties. Et en fait, dans la spreadsheet, de mettre en face de la fonction « ma compréhension » en quelques mots. Cette fonction sert à tel truc.

ça peut paraître un peu laborieux. Du coup, pour rendre le sujet un peu plus prenant, c'était de compter la proportion restante de fonction à comprendre. Comme c'est une spreadsheet, c'est facile de faire des formules pour afficher le pourcentage de fonction que tu as déjà compris.

La première fois, tu dis ok, là j'ai compris 10%. Et puis la fois d'après, tu dis bah là j'ai compris 16%. Super. Maintenant je suis passé à 24. Et tu vois le score avancer et ça te permet d'aller jusqu'au bout. Et ça, ça m'avait donné une compréhension vraiment très fine. C'était indispensable en tout cas pour démarrer ce projet.

C'était le point de départ après pour créer de la doc, pour être en partenaire avec un PM, pour reprendre le contrôle et démarrer des projets sur ce côté.

Alexandre

C'est marrant comme approche. Lorsque j'aborde du code, j'ai tendance à la placer dans un graphe 2D. Cette approche m'a surpris.

Jonathan Boccara

C'est vrai qu'il y a des applis qui te permettent de faire des graphes à partir du code. Mais quand il a beaucoup de codes, c'est difficile à exploiter. Alors quand il y a beaucoup beaucoup de code, ça devient plus un graphe, ça devient une tâche. Tous les points sont confondus dans un seul grand. Là, c'est inexploitable, à part pour dire, "regardez à quel point ce code est grand". Mais même quand c'est du code à ta taille qu'on peut vous visualiser, je n'ai jamais réussi vraiment à en tirer quelque chose.

Parce que tu vois, le graphe qui est généré, un problème, c'est de savoir pas par quel bout le prendre. Il y a plein de termes dans les noeuds qui ne sont pas forcément évocateurs. Et au final, je trouve qu'on passe plus de temps à lire le graphe qu'à comprendre quelque chose. Et puis, on fait beaucoup d'allers-retours dans le code. Du coup, j'ai préféré plutôt partir du code.

Alexandre

Ok.

J'ai vu que tu vendais des t-shirts. Est-ce qu'on a besoin d'un t-shirt imprimé d'YAGNI ?

Jonathan Boccara

Aha.

Ça a déjà été utile.

Ça déjà été utile en réunion, de partir sur des solutions un peu compliquées. YAGNI, c'est les initiales de « you ain't gonna to need it ». C'est une recommandation de ne pas développer du code qui est complexe dans le but d'anticiper des use cases qui viendront dans le futur en disant "je vais faire du code qui sera future proof", en réglant des problèmes qui arriveront dans le futur, et du coup rendre le code plus compliqué maintenant.

YAGNI, c'est un truc qu'on dit pour mieux éviter de faire ça. Parce que souvent, on a du mal à vraiment prévoir le futur, et le code peut évoluer dans une direction complètement différente de celle qu'on anticipé. Du coup on se retrouve sur avec quelque chose qui sert pas forcément. En tous cas ce qui est certain, c'est qu'on doit le maintenir dès le premier jour, alors que ce n'est pas certain que ce sera utile un jour.

YAGNI, c'est pour éviter de faire ça et écrire du code qui résout seulement les problèmes de maintenant.

En fait, c'est intéressant comme sujet parce que d'un autre côté, tu peux avoir des préoccupations légitimes de backward compatibility. ça dépend dans quel milieu tu travailles, mais par exemple tu ne pas forcément pouvoir faire des livraisons si c'est sur l'embarqué. Tu peux avoir vraiment des problèmes légitimes de devoir penser dès le premier jour à faire quelque chose qui ne posera pas de problèmes de compatibilité dans le futur.

La limite entre ce qui est YAGNI et pas YAGNI, c'est de faire ton design aujourd'hui d'une manière qui ne te bloquera pas pour plus tard. Et on revient un peu toujours à ce thème de rendre le facile à changer.

C'est bien de prendre du temps et de réfléchir à comment structurer son code pour ça.

Par contre, là où c'est trop, c'est de se dire, je vais rajouter des choses dans le code, des features, pour résoudre des problèmes qui n'existent pas encore. Là par contre c'est ce qui est déconseillé par YAGNI.

Pour en revenir à ta question, pour les t-shirts, ça m'est déjà arrivé d'être en réunion, d'avoir un t-shirt yagni et de pointer le t-shirt. Pour dire attention, on est en train de partir, quand je me rends compte qu'on est un peu emballé. Et puis bon, c'est rigolo de pointer ton t-shirt.

Aussi, le fait que ce soit un visuel comme ça, ça a déjà provoqué une discussion. En disant soit, ah ouais c'est cool, t'as un t-shirt yagni. Ou alors, qu'est-ce que ça veut dire Yagni ? Et puis du coup, on rentre un peu plus dans les détails.

Alexandre

Ok. C'est marrant. Oui, c'est aussi de l'avoir sur toi et de te rappeler le concept.

Il y a toujours un curseur comme ça, à trouver entre à quel point tu anticipes le futur et à quel point tu ne l'anticipes pas. Parce que si tu ne l'anticipes pas à l'extrême, ça peut être gênant aussi. On ne veut pas pousser le concept trop loin.

Jonathan Boccara

Ouais tout à fait.

Ce qui m'a été utile pour ne pas faire quelque chose de trop naïves, c'est d'essayer plusieurs use case sans trop abstraire. Imagine que tu conçois un modèle de données pour ta base de données, donc ça va être un peu galère à changer ensuite. Ou alors quelque chose qui va être exporté dans une API qui est visible par tes clients, pareil, ça va être compliqué à changer.

Le truc, c'est te dire, ok, j'ai un use case, que je peux représenter de manière très simple. Qu'est-ce que ça donnerait si mon use case était un petit peu différent ? Et là, tu te dis, en fait, avec le use case différent, ça me fait rajouter des colonnes, et ça ne va pas bien scaler. Est-ce qu'en fait, je n'aurais pas un concept, dans use case par exemple, le concept d'une opération par exemple, plutôt que de dire je mets en vrac des opérantes par exemple et se dire, j'isole Le concept d'opération. Et ce concept d'opération, lui il est polymorphique par exemple. C'est un cas qui m'est vraiment arrivé. Et ça a fait un design qui était même mieux pour les use-cases qu'il y avait déjà au premier jour.

Alexandre

Ok.

C'est Kevlin Henney qui a écrit la préface de ton livre. C'est un speaker assez connu dans le milieu des confs. Comment est-ce que vous vous êtes rencontrés ?

Jonathan Boccara

Je l'ai rencontré dans une conférence, à ACCU à Bristol en Angleterre. J'avais assisté à une de ses interventions qui était vraiment très intéressante. J'avais été le voir à la fin pour lui demander s'il était d'accord que j'écrive un article sur mon blog qui reprenait les idées que j'avais apprises dans sa présentation, en le citant bien sûr, et s'il serait d'accord de le relire pour m'assurer que je l'avais bien retranscrit.

Et il était super sympa. Il m'avait dit ok. Et puis il l'avait fait. On avait fait une première petite collaboration on va dire. Et puis on s'était revu plusieurs fois dans des conférences. Quand je lui ai proposé de faire la préface de mon livre, il a été d'accord là-dessus.

Alexandre

Ok génial.

On en a déjà un peu parlé, mais est-ce que tu as des cas d'usage préférés IA/LLM en ce moment ?

Jonathan Boccara

Hormis ce dont on a parlé, j'utilise ChatGPT pour générer des petits scripts, du style, "je veux savoir le nombre de lignes de chaque fichier de ce répertoire, fais moi un script bash en quelques lignes pour le faire". Et ça va très vite. Ou alors pour apprendre des langages. J'ai appris Clojure récemment, et je lui demande comment faire tel ou tel truc de manière idiomatique. Je trouve que ça m'a permis d'apprendre beaucoup plus vite le langage.

Après il y a Cursor. C'est un peu dans le même style que Co-Pilot, en sens où il est intégré à ton IDE. Mais si je comprends bien, il parse la codebase dans son ensemble - là où Co-Pilot, je n'avais pas réussi à lui faire répondre à des questions comme "dis-moi, dans la codebase, où se trouve le code de telle fonctionnalité". Si j'ai bien compris, Cursor serait plus à même de répondre à des questions comme ça.

Alexandre

Ok. Oui, parce que du coup là, j'ai datadog. T'es sur quel langage ? T'es sur quel langage là ?

Jonathan Boccara

Il y a plusieurs langages chez DataDog. Dans mon équipe, c'est du Java principalement. Il y a des petites choses faire dans d'autres langages, mais c'est essentiellement du Java.

Alexandre

Ok. Et est-ce que tu as une mission particulière chez eux ?

Jonathan Boccara

Je suis développeur dans une équipe qui s'occupe des logs - par opposition par exemple aux métriques. Les métriques, c'est des valeurs qui arrivent dans Datadog qui sont envoyées par les applis clientes. Les logs, c'est des logs, dans le sens du texte ou des données structurées. Il y a plusieurs équipes qui s'occupent des logs et je fais partie de l'une de ces équipes.

Alexandre

Ok.

On en revient à l'observabilité !

Jonathan Boccara

Ouais, pour le coup, vraiment à fond.

Alexandre

Ok cool.

Est-ce tu as un mot de la fin ? Un message que tu aimerais faire passer ou une ressource que tu aimerais partager ?

Jonathan Boccara

On a déjà évoqué pas mal de ressources, entre les livres, les sites, etc.

Après, comme message, j'encourage les gens à avoir une vision positive de leur code. Ce n'est pas forcément plus vert ailleurs. Parfois c'est plus vert ailleurs, parfois c'est moins vert ailleurs, mais en tout cas, c'est toujours plus utile pour soi-même et pour l'entreprise d'avoir une approche constructive et positive du le legacy code.

C'est notre métier. Notre métier, n'est pas de faire des scripts dans du code tout nouveau ou de faire des classes dans du code tout nouveau. C'est aussi de faire grossir des projets. Donc c'est complètement notre métier. Ce n'est pas une tâche en plus qu'on a à faire, c'est au cœur de notre métier. Et c'est quelque chose à prendre avec un aspect positif.

Alexandre

Oui. Je pense que change tout en plus, de l'approcher avec cet état d'esprit.

Trop cool.

Merci beaucoup pour ton temps, ta disponibilité et toutes tes réponses.

Jonathan Boccara

Merci à toi de m'avoir invité.

Alexandre

Avec plaisir.