Bruno Boucard & Thomas Pierrain

Qui parmi vous a déjà travaillé sur des codes legacy ?
Ouais, pas mal. Qui est développeur ou développeuse dans la salle?
Ça va quand même. Ok. On va parler de Legacy, mais pas que de développeur. On se présente, Thomas Pira, architecte technique. Ça fait plus de 10 ans que je bosse dans une grosse banque. Et donc j'ai quelques heures de vol. En pratique de code legacy, mais pas que.
Alors moi je suis Bruno Boucard, c'est pareil, j'ai pas mal d'expérience sur le code legacy. Voilà, bon, ça suffit.
Alors legacy,
C'est souvent, ça commence par un triste constat. On regarde ce qu'on a, base de code, les équipes, les gens. Parfois, ça ressemble un peu à ça.
Parfois, c'est des situations dont on n'arrive vraiment pas à comprendre. Le code nous ment, ce qu'il raconte n'est pas ce qu'on observe. Les gens n'ont pas forcément retenu ce qu'il fallait faire. On ne se comprend pas tous entre métiers, développement, etc. C'est un peu compliqué. Dans des situations, c'est même pire que ça. C'est complètement absurde.
On marche sur la tête.
On marche sur la tête, oui. Et donc, en gros?
En gros, on court, on court, on court, on fait des sprints. Et au final, on est crevé. Et puis, pire que ça, c'est qu'à la fin, on obtient un tas de boue.
C'est un peu le bordel.
Et le pire, c'est pas tellement ça, c'est que ça nous coûte une fortune.
Non seulement on a produit un truc qui n'était pas maintenable, mais ça le coûte très très cher.
Ça coûte cher pour les entreprises, donc la facture comme ça, ça coûte aussi cher dans la tête et le moral des gens. Le nombre de collègues que j'ai vus...
Les dégâts moraux, comportementaux... Même s'ils ne sont pas clairement exprimés, existent et sont parfois graves.
Vous imaginez si on arrivait tous ensemble à travailler main dans la main, unis par un même objectif, ça serait quand même pas mal.
Bon, alors, à votre avis, d'où il vient le legacy? Alors moi j'ai un peu réfléchi Bruno avant qu'on se voit.
Ouais, ouais, ouais, je sais.
Quelques propositions à te faire.
Ouais, vas-y.
Legacy, c'est surtout les autres.
Ben voyons.
Si, tu arrives dans un projet, le code il est là, c'est d'autres gens qui l'ont fait, franchement... Non, ça ne le fait pas. Le legacy, c'est lié à notre industrie.
C'est un peu le café du commerce.
Je suis désolé, je n'ai pas eu beaucoup de temps pour le dégérer. D'ailleurs, on est la seule industrie qui parle de legacy pour parler de choses négatives, il me semble. Dans tous les autres contextes, ça a un autre sens, ça a une autre saveur, ce terme. Bon, donc il y a quand même un peu de ça.
Il y a un peu de ça, mais ça ne me sent pas être la bonne cause.
Bon, ok, j'essaie. Le legacy, pour moi, c'est comme une malédiction. C'est tout que ça revient, on l'observe sur quasiment tous les projets, même pour des projets qui sont jeunes, au bout d'un an, deux ans, parfois on est dans une situation de legacy. D'ailleurs le legacy c'est quoi pour vous? Vous avez des petites idées? Comment vous caractériseriez, c'est quoi une application ou un contexte legacy?
Le code des autres. Le code avant le mal. C'est pas mal. Ouais. Tu valides?
Du code sans test, c'est la définition de Michael Fieser. Alors moi j'en ai une autre qui est personnelle, qui est c'est du code qui fait souffrir, ou c'est une situation qui fait souffrir. Quelle que soit l'origine, on souffre. Que ce soit lié au code, au métier, au contexte, etc. Donc bon, t'es pas convaincu?
Non, non, non.
Bon alors d'après vous, on a vu ce que c'était, mais d'où ça vient le legacy? Une petite idée?
Toujours pas ?
Oui, en fait, ce n'est pas faux, Christophe. Mais en fait, c'est nous. C'est vous, c'est tout le monde en fait.
Le legacy c'est vous, enfin c'est vous et puis c'est nous, c'est nous tous dans cette salle. Si ces situations se reproduisent encore et encore, on y est pour quelque chose. Alors le legacy c'est un peu comme quand on a une cuisine dans cet état et qu'on continue à faire la bouffe.
C'est absurde.
On ne le fait pas à la maison, j'ose espérer pour nous tous et toutes, mais on le fait au boulot dans certains cas.
Legacy, c'est aussi une situation comme ça, où on se dit qu'on ne comprend pas ce qu'il faut faire, mais on le fait quand même. Parce que si ça se trouve, si on s'arrête, un peu comme dans l'hoste, si on n'appuie pas sur le bouton, il peut se passer un truc de grave. Donc on est tous embarqués dans cette... Donc c'est nous tous. Et puis c'est donc le code et nous autour.
Oui, exactement. Et bon, voilà, pomper pour faire quelque chose dont on ne comprend pas le sens, c'est malheureusement le lot de nombreux projets, nombreuses organisations.
Et c'est dommage.
Le contexte, ça fait des années qu'on dit que le logiciel mange le monde, Marc-André Sen l'a dit, etc.
Est-ce que vous avez l'impression qu'on est à la hauteur de ces enjeux? Aujourd'hui, tous et toutes dans cette industrie.
Pour nous, on considère qu'il est un peu temps de changer de posture. C'est-à-dire que les réponses qu'on apporte aux enjeux d'aujourd'hui ne sont clairement pas adaptées. Et ces situations récurrentes de souffrance, de non-adéquation par rapport aux attentes et aux valeurs attendues, etc., il va falloir qu'on en sorte. Alors, on peut se dire, est-ce que vous êtes prêts à nous suivre? Il me semble qu'il y avait un truc, peut-être après. On va faire trois chapitres. On va faire le chapitre 1, c'est la culture.
Oui, la communication et la culture. En fait, j'étais pas mal bouleversé en lisant le bouquin Sapiens. Et il dit à un moment dans ce livre qu'il y a une période chez les premiers hommes, les premiers sapiens, période chasseur-cueilleur,
Un petit clin d'œil à Pablo. Où les humains étaient presque dans une posture humaniste de partage et ils n'avaient pas forcément de problème de domination. Et ça se passait plutôt bien.
On est des animaux sociaux. Pourquoi ça ne tombe plus rond?
On n'est plus dans le même contexte. On est dans des entreprises, des équipes. Pourquoi ça ne tombe plus rond chez nous?
Parce qu'effectivement, souvent, il m'arrive de poser des questions à des développeurs. À quoi sert leur application? Ils ont beaucoup de mal à me répondre. Donc, il y a une perte de sens, une perte de motivation.
La perte de motivation venant souvent comme conséquence.
Oui, c'est lié, bien sûr. Et puis, il n'y a surtout pas de communication, pas assez du moins. Donc, du coup, on est un petit peu comme un radar sans écho. Pas de feedback, on est perdu. On est à deux doigts de décrocher.
Sans feedback, où aller? On essaye, mais bon. Alors première étape, quand on est face à une situation de légacie un peu pénible, c'est le réveil.
Alors, le réveil.
Le réveil, c'est restaurer le lien avec le métier, ça c'est super compliqué. Qui pense que c'est compliqué de restaurer le lien avec le métier quand on est côté dev? Ouais, je ne suis pas tout seul, ça va.
Donc la communication c'est important. La communication c'est pas de l'information, c'est pas je balance un truc de l'autre côté du mur, si c'est reçu tant mieux, si c'est pas reçu tant pis. C'est vraiment bidirectionnel, on s'assure que l'autre comprend ce qu'on vient de lui dire. Et donc ça c'est clé et c'est assez peu utilisé alors que c'est un truc assez puissant. Premier réflexe comme développeur, c'est Jérémy Grodzinski avec qui...
qu'on fréquente un peu, qui dit que c'est toujours comprendre le domaine. Avant de coder, le premier métier d'un développeur, c'est comprendre le domaine sur lequel il est. Alors ça paraît la palissade de dire ça, mais en fait c'est très très peu observé. En tout cas, moi, sur les projets sur lesquels je suis intervenu, c'est assez rare.
Comprendre l'autre, c'est l'empathie aussi, c'est important. Alors, on est tous plus ou moins adaptés à faire preuve d'empathie, c'est-à-dire à se mettre à la place de l'autre. J'ai même lu récemment...
Tu m'as parlé de pays nordiques où ils donnaient des cours d'empathie.
En Islande, je crois que c'est en Islande, où ils donnent à l'école des cours d'empathie. Donc apparemment, ça s'apprend.
Et ils ont l'air d'être contents, ils ont l'air de trouver que ça a du sens. Donc de faire preuve un peu plus d'empathie quand on est sur le volet technique par rapport au métier, ça ne nous fait pas de mal. En général, les résultats sont sympas.
Et puis alors si l'autre ne veut pas, parce que parfois on a envie d'aller comprendre le métier, de parler avec le business, etc. Parfois on est un peu cloîtré, cantonné, il y a plein d'intermédiaires, des business analystes, product owners, il y a plein d'intermédiaires entre les experts du domaine et nous qui allons réaliser.
Alors comment on fait? Et parfois ils ne veulent même pas collaborer, c'est-à-dire que quand on se retrouve dans la même pièce, il ne se passe pas cette magie dont je parlais au début, l'équipe de rugby qui tire tous dans le même sens.
Il y a une phrase, moi c'est sous forme de punchline d'Alberto Brandone, qui était là ce matin pour l'Eonstorming, qui m'a servi à nombreuses reprises dans de nombreux contextes, face à des gens qui ne veulent pas expliquer ce qu'ils sont en train de faire pour qu'on puisse le réaliser, c'est de leur expliquer que très sincèrement, ce n'est pas ce que vous savez déjà qui va partir en prod, c'est ce que les développeurs ont dans leur tête. Donc si vous ne les aidez pas à changer les modèles mentaux et ce qu'ils ont compris et ce qu'ils ont dans leur tête, c'est tout le monde qui va y perdre. Cette petite phrase-là, moi franchement, elle m'a sorti de situation de workshop où tout le monde se regardait en chaîne de faïence.
C'est assez pratique. Alors, hop, si l'autre ne veut pas, c'est ça. Alors, l'event storming, on en parlait ce matin, l'image est de plus en plus sombre. Je ne sais pas si vous allez réussir à voir quelque chose. Qui était l'event storming ce matin au workshop d'Alberto? Quelques-uns. C'est quoi? C'est une façon exploratoire de comprendre ce qu'il y a de la valeur pour le métier. On est technicien et non technicien dans la même salle. On utilise des post-it sur une grande surface. Et à travers ces possibles, ce sont des événements métiers, des choses qui apportent de la valeur. On part d'un événement, paiement encaissé par exemple, et on essaie de se dire, tiens, qu'est-ce qui s'est passé avant? Qu'est-ce qui a mené à cet événement-là? Et ainsi de suite, et ainsi de suite. De proche en proche, le fait d'être debout, le fait de travailler sur une grande surface permet d'exploiter le non-verbal, permet de mieux comprendre quand des gens ne sont pas d'accord. Et c'est un moyen d'avoir des discussions assez rapides. Parce que l'important, Bruno,
L'important, c'est d'avoir des bonnes conversations. Alors, pas forcément des fights, mais de bien s'expliquer. Et si je peux refaire un parallèle avec Sapiens, c'est que nous, en tant qu'êtres humains descendants de Sapiens, on a une facilité à comprendre des exemples plus que des abstractions. Donc, bien évidemment, souvent, les ouvrages universitaires sont plus tournés vers des formules génériques.
Il est évident que nous, en tant qu'êtres humains, on préfère avoir des exemples en premier pour ensuite aller vers l'abstraction. Donc avoir des conversations illustrées par des exemples, c'est essentiel. Ça nous permet de comprendre.
Un nombre de projets où j'ai vu qu'on partait directement sur des abstractions, pensant avoir compris tout de suite ce qu'il fallait faire et essayer de comprendre comment fabriquer la solution et trouver les abstractions qui allaient avec alors qu'on n'avait pas compris vraiment le besoin. Donc partir d'exemples pour abstraire après dans un second temps, c'est assez important. Dans cette discussion avec le métier. Alors, un autre truc important, c'est d'agir au niveau de la culture, parce que la culture, comme disait l'autre, c'est ce qui bouffe la stratégie au petit-déj tous les matins. Si vous n'agissez pas au niveau de la culture de votre équipe, des équipes autour de votre métier, ça va être un peu scisif. Et puis très très vite, les habitudes du terrain miné, du legacy, vont revenir. Donc, agir sur la culture. Alors, comment on fait pour agir sur la culture? Je crois que c'est Nick. qui ont parlé hier. Une astuce, c'est que nul n'est prophète en son pays. Vous pouvez avoir des superbes idées, vous pouvez avoir une vision, vous pouvez avoir tout un tas de choses. Si c'est vous qui êtes dans les murs depuis longtemps qui l'a formulé, en général vous ne serez pas vraiment entendu. Donc il ne faut vraiment pas hésiter à faire appel à des gens de l'extérieur. Il y a la version consultant, etc. Il y a aussi des versions plus simples pour réveiller votre équipe de dev, par exemple, ce qu'on appelle des brown bag lunch. Qui sait ce que c'est qu'un brown bag lunch? Déjà pas mal. En fait, c'est quoi? Pour ceux qui ne connaissent pas, c'est que vous faites venir un expert ou un speaker le temps du déjeuner. Vous le défriez juste d'un sandwich, il vient vous parler de sa passion, d'une chose qui l'intéresse ou d'un retour d'expérience. Et c'est l'occasion pour vous de sortir du contexte, vos collègues aussi, de se réveiller un peu, en voyant que d'autres gens travaillent différemment, font autre chose. Et ça peut donner des idées, après, en interne. Donc voilà, c'est assez simple à mettre en place. Il suffit juste d'une salle de réunion. d'un barco ou d'un picoprojecteur si la salle de réunion n'est pas équipée. Et ça peut insuffler un vent nouveau dans votre équipe de dev. Alors il ne faut pas être ambitieux et se dire, tiens, je convoque la salle de réunion du président et puis on va convoquer tout le monde. Vous allez avoir un peu de mal à faire ça. Faites ça déjà au niveau de votre équipe. Prenez un rendez-vous le midi de temps en temps pour faire ce genre de choses. C'est assez apprécié, c'est rare que ça ne prenne pas. D'ailleurs, c'est sur la base du volontariat, c'est gratuit, c'est sur la base du volontariat. Donc les gens y viennent tout naturellement.
Je suis Bruno.
Eh bien, il faut être effectivement curieux, s'entraîner et être tourné vers les autres. C'est une excellente manière de changer en apprenant, en échangeant. Alors, effectivement, il y a un document qui existe en programmation qui est...
Vous n'allez pas lire grand chose, on va en lire deux fois pour ceux du fond. Le premier c'est que vous n'êtes pas votre code, c'est à dire que quand vous faites du code review, etc. Il ne faut pas se sentir attaqué si quelqu'un critique votre code. Ce qui critique ce n'est pas vous, c'est votre code. Donc il faut prendre un peu d'altitude par rapport à ça.
Le second il dit que... Ce n'est pas parce que vous vous sentez un peu fort qu'il n'existe pas quelqu'un qui connaît plus de choses que vous. Donc, ce n'est pas la peine de se la péter. Autant rester humble, ce sera plus facile pour collaborer.
Le troisième, c'est assez spécifique à ce qu'il y avait dans l'extrême programming, c'est de dire que la seule constante, c'est que le monde change. Donc, essayez de vous y faire. Le nombre de gens et de collègues que je vois râler quand il y a un truc qui change, au lieu de voir ça comme une opportunité, c'est juste un état d'esprit, mais ça peut changer beaucoup. Juste d'accueillir chaque changement comme une opportunité, de faire un truc mieux, de faire un truc différemment, et trouver d'autres idées.
Oui, enfin, ne soyez pas le développeur au fond, à côté du radiateur. Ça n'a pas forcément aidé à communiquer pour comprendre le domaine.
Et puis quand on fait des code review, alors autant il faut être bienveillant avec les gens, autant avec le code il faut y aller. Quand on fait une code review, il faut se dire les choses, il faut y mettre l'effort. Mais il faut y aller. Donc bienveillance ne veut pas dire tout accepter. Et puis arriver dans des situations où au bout d'un moment, les gens n'en peuvent plus comme des cocottes minutes. Ils n'ont pas réussi à exprimer quelque chose qui les gênait depuis longtemps sur le projet. Et ça part à la catastrophe.
Bon, et puis, oui, de ne pas réécrire des choses sans consulter les gens, les collègues, ne pas faire les choses en solo, comme dans le coin. comme une opportunité de faire un truc mieux, de faire un truc différemment et de trouver d'autres idées.
Oui, enfin, ne soyez pas le développeur au fond à côté du radiateur. Ça n'a pas forcément aidé à communiquer pour comprendre le domaine.
Et puis quand on fait des code review, alors autant il faut être bienveillant avec les gens, autant avec le code il faut y aller. Quand on fait une code review, il faut se dire les choses, il faut y mettre les formes, mais il faut y aller. Donc bienveillance ne veut pas dire tout accepter et puis arriver dans la situation où au bout d'un moment les gens ne peuvent plus comme des cocottes minutes, ils n'ont pas réussi à exprimer quelque chose qui les gênait depuis longtemps sur le projet et ça part à la catastrophe. Bon, et puis, oui, de ne pas réécrire des choses sans consulter les gens, les collègues, ne pas faire les choses en solo, comme dans le coin.
Alors, le software craftsmanship, qui connaît?
Donc c'est une culture avant tout, ce n'est pas forcément des pratiques techniques. Donc c'est de la passion, de la discipline, de la motivation, de l'efficacité, mais surtout de la transmission. Donc ça c'est important, c'est transmettre cette passion aux autres.
Ce qui est important, c'est que ce n'est pas un ensemble de pratiques.
Non.
qu'on peut lire ici ou là sur Twitter, etc. C'est vraiment une culture, c'est aimer apprendre et aimer transmettre.
Et aimer progresser. D'ailleurs, la progression se fait tout simplement par le fait d'observation, d'amélioration, observation, etc. On est assez proche de l'esprit de l'événement aujourd'hui.
C'est aussi ça le software craft mentoring. Ah ouais, Bruno?
Oui, ça c'est souvent dans le... Mon métier, chaque jour, c'est plutôt du coaching. Et il arrive que l'équipe, et pour tous les coachs, ça a souvent été cette remarque. Moi, je n'ai pas besoin parce que chez nous, c'est différent. C'est plus compliqué que les autres. Il faut que cette réponse, chez nous, c'est différent.
Qui s'est dit ça dans la tête depuis le début? Son petit pas, ça a l'air sympa, mais chez nous, franchement, c'est pas possible.
Non? Bon, ça va. Vous êtes timide, vous savez?
Ouais. Impossible de reprendre le contrôle? Ouais. Alors, ça c'est un truc que j'aime bien, c'est au XVIe siècle, il y a un jeune français d'un âge de 18 ans qui a écrit un petit texte qui a en quelque sorte changé la face du monde. Alors, ça fait un peu... Grand sans phase, etc. Mais qu'est-ce qu'il dit ce petit texte? Ce petit texte, il dit que les autres n'ont de pouvoir sur nous que si on y consent. Donc, en gros, ce texte, il dit« Soyez résolus de ne servir plus et vous voyez à libre». C'est la Boétie et son discours de la servitude volontaire. C'est un petit texte qui a été repris et qui a déclenché en partie la Révolution française.
Tous les mouvements d'émancipation, que ce soit contre l'esclavage, pour le peuple noir à l'époque, l'apartheid, les plus grands théoriciens ou les gens qu'il y a derrière ont tous dit qu'ils s'étaient inspirés de ce petit texte-là. En psychologie, pareil, quand on parle de victimes, bourreaux, etc. Ce texte a vraiment transformé. former beaucoup de choses. Vous imaginez, à 18 ans, le mec, au XVIe siècle, à 18 ans, écrit un texte comme ça. Bon, alors, la Boétie, c'est quand même la Boétie, mais nous, avec nos petits problèmes d'informatique, etc., on pense, avec Bruno, qu'on est capable de faire quelque chose. Il n'y a rien d'impossible aux situations qu'on vit en ce moment.
Alors, chapitre 2.
Chapitre 2, c'est les pratiques.
Oui, on a parlé beaucoup de communication, de posture, un peu d'humanisme. À un moment donné, on est quand même des praticiens, on fait du code. Donc, pour le faire correctement, il faut effectivement lire, discuter. reformuler, chercher des métaphores et proposer.
Tout ça, ça appartient un peu au livre sur le domaine du design, mais ce n'est pas la peine de lire le livre, c'est quand même du bon sens et ça permet quand même de mieux comprendre le besoin afin de coder correctement.
Qui pense qu'on met assez le domaine, la valeur métier, enfin pas la valeur, mais les logiques métier, en tout cas le métier au cœur de nos développements dans les projets? Un, deux, trois qui pensent ça?
Oui, parce que la plupart des cas, les situations que j'observe en tout cas, c'est la tentation, quand on ne fait pas assez appel à notre curiosité, en tout cas qu'on ne met pas ça au cœur de nos décisions et de nos développements, c'est de trouver une situation où en tant que technicien, on peut se sentir un peu dévalorisé. Je suis développeur, je n'ai pas toujours accès au métier, il y a tellement d'intermédiaires. et parfois on me demande même de ne pas aller au métier, c'est un peu dévalorisant. Alors qu'est-ce qui se passe? Moi ce que j'ai observé, en tant que technicien, on se dit, tiens comme ce n'est pas hyper valorisant, je vais essayer de me trouver une autre source de valorisation. Je vais devenir un super expert d'un truc technique. Et ok, je ne ferai pas partie de leur réunion, leur workshop, etc. Mais au moins, on me reconnaîtra cette expertise. Donc on va se hyper spécialiser et tomber dans une sorte de zone de confort où en tant que développeur, on va s'intéresser surtout aux frameworks techniques, aux librairies, plus que le nouveau métier ou le métier sur lequel on doit bosser. Alors la caricature, je ne sais pas si vous l'avez vue, M. Manhattan, c'est le monsieur qui sait tout sur tout.
La caricature, c'est devenir un peu aigri et se crisper sur ce truc-là, hyper technique. Et puis d'ailleurs, comme on ne comprend pas le reste, de toute façon, c'est des blaireaux, c'est machin. On reste dans la tour d'ivoire et on se focalise sur la partie technique.
On est un peu cynique.
Oui, ça c'est la version, l'état d'après. Qui a rencontré des gens comme ça un peu dans les équipes? On n'est pas tous seuls. Ça arrive. On n'est pas trop...
Ça arrive, ça arrive.
On a parlé de pratique.
Il y a quand même quelques fondamentaux quand on veut faire du code qui ne soit pas du legacy. C'est effectivement appliquer quelques principes. Donc, KISS, la double boucle. Connaître ses raccourcis clavier, faire du pair programming, ne pas utiliser un framework parce que c'est juste la mode, et puis connaître les principes de base de l'objet si on fait de l'objet.
Ça paraît évident quand même, mais c'est vrai que le nombre de collègues que j'ai vu ne pas maîtriser leur outil de travail, c'est-à-dire leur IDE, les raccourcis, etc., et être bloqué, être crispé parce qu'ils ne se sentaient pas à la hauteur, alors qu'il suffit juste de répéter un peu. On va le voir après, mais il y a moyen de s'améliorer sur ces petits gestes pour pouvoir dépenser sa CPU, son cerveau, sur d'autres choses.
Il y a un ouvrage qui est un petit peu une référence d'exercice de code qu'on appelle Kata, donc répéter des mouvements comme dans les arts martiaux pour obtenir des automatismes.
C'est aujourd'hui un moyen de pratiquer quotidiennement et de s'améliorer. Ce n'est pas les seuls exercices qui existent dans le monde, mais c'est un bon début.
Il y en a qui pratiquent des codes kata dans les développeurs de la salle régulièrement? Oui, quand même. On est dans une conférence, donc ce n'est pas surprenant. Mais ça fait du bien et ce n'est pas si compliqué, pas si long que ça. Sinon, vous feriez ça, vous?
Moi j'ai le vertige, donc clairement jamais, jamais de la vie. Même regarder la photo ça me fait bizarre. Quand on est face à du Legacy, moi je préfère me protéger. Quand je pars à l'attaque du Legacy, je me protège. Alors pas vraiment comme ça, plutôt en mode Arnett test. Test Arnest.
Donc, on n'attaque pas le Legacy sans avoir un minimum de sécurité.
Ça, c'est un premier point. Le deuxième point, il faut reconnaître ses adversaires. C'est-à-dire qu'il n'y a rien à faire, on est en terrain hostile, le code a été fait n'importe comment, il n'y a pas de sens métier, donc il va falloir un peu comme le code de la route, connaître les signaux qui nous vont permettre d'avoir des bons réflexes. Donc on ne va pas les énumérer tous, mais il y en a quelques-uns.
Ils ont des petits noms, ça fait les codes smell.
Oui, c'est les codes smell. C'est une image un peu émotionnelle sur des mauvaises odeurs qui émaneraient le code. On peut en prendre un comme, je ne sais pas, on peut prendre le cas de Feature Envie, par exemple. Feature Envie, ça veut dire qu'on a une portion de code dans une méthode, par exemple, qui est très envieuse d'une autre classe qui existe dans notre code.
Qui n'arrête pas de l'appeler. Oui, voilà.
C'est un principe de responsabilité, en fait. On a une responsabilité qui n'est pas à la bonne place, et donc on a qualifié le problème avec un nom.
Donc ça simplifie la manière de faire.
Tu pourrais peut-être nous montrer ça sous forme de code?
Oui.
Je rassure ceux qui... ne code pas, ce que va vous montrer Bruno est indolore. On va essayer d'expliquer, je vais essayer d'expliquer ce qu'il est en train de faire et ce que vous aurez sous les yeux. On l'a déjà fait une fois, on a réussi à ne pas perdre des non-développeurs et des non-développeuses. On ne voit pas ton IDE par contre.
Oui, je vais arrêter.
Bruno va nous montrer un exemple de code qui est issu d'un code kata, un petit exercice de code.
Qui est largement utilisé par les coachs.
C'est un code kata de location. Vous vous rappelez avant Netflix, il y avait des magasins où on louait des DVD?
C'est issu de ce métier-là.
Oui, il y a presque 15 ans, il y avait au coin de notre rue des gens qui louaient des DVD.
Le soir, on ne savait pas forcément quoi faire, il n'y avait rien à la télé. On descendait louer un film. En gros, voilà le contexte fonctionnel. Et on est dans la méthode qui va nous imprimer le ticket après location.
Je rends mes DVD et ta méthode va me calculer combien ça m'a coûté des factures.
Voilà, elle fait un certain nombre de choses. Je vais essayer d'illustrer ce qu'elle fait. Elle s'intéresse pour toutes mes locations à savoir combien coûte chacun des films loués. Voilà, j'ai un petit... Un petit message. Output. D'accord, OK, je ne vais rien starter.
Et ensuite, j'ai un deuxième point. Je ne sais pas ce qui se passe là. Qui fait le calcul des points de fidélité. Donc, il y a deux lignes de calcul. Trois.
Attends, pendant que tu fermes l'erreur, en fait, il y a un for each in book qui dit, pour tous les films que tu viens de me rendre, je regarde pour chacun des films, là, je regarde le type, et si c'est un film régulier, il va falloir que tu arrêtes ça, Bono.
Je ne sais pas ce que c'est.
C'est comme si tu essayais de lancer un debug, j'ai l'impression.
Non, mais je ne fais rien, je ne touche même pas l'écran.
Oui, cache-le. Il va peut-être avoir du mal à taper.
Oui, mais c'est peut-être modal, auquel cas je vais avoir des problèmes. C'est modal.
Si c'est un film régulier, ça va me défalquer un certain montant, avec un algorithme très particulier. Si c'est un film récemment sorti, ça va me défalquer ça. Si c'est un film pour les enfants, ça va me défalquer ça. Avec juste après avoir calculé tout ça, les points de fidélité qui vont être calculés en fonction de l'activité.
Et en final, on va formater le ticket en précisant les montants.
Je vous assure que ce n'est pas un script préparé.
C'est assez incroyable.
C'est comme s'il y avait quelqu'un qui tapait sur mon clavier.
C'est ça.
Je ne touche à rien.
C'est ça, oui.
Voilà, donc, on va essayer de prendre une métaphore. Je vais le laisser pour l'instant. Imaginez que dans votre salon, vous ayez la vaisselle. Vous trouvez ça, c'est pas mal, mais il y a quand même quelque chose qui ne va pas. Et votre femme arrive, vous venez d'aménager.
J'avais ça dans mon premier appart. Pardon? J'avais ça dans mon premier appart.
Oui. Et malgré tout, vous avez une cuisine. Et à mon avis, dès le premier soir, vous allez déplacer le lave-vaisselle dans la cuisine. En fait, ça paraît à peu près logique. Dans le code, c'est souvent comme ça. On a souvent un lave-vaisselle qui se trouve... En plein milieu. Alors, il n'est pas forcément matérialisé parce qu'il n'est pas encapsulé dans quelque chose. Il n'y a pas, on va dire, un élément physique qui entoure la portion de code. Mais finalement, c'est quasiment ça. Et c'est le code que j'évoquais, le feature en vie. C'est-à-dire qu'on a effectivement du code. Qui n'a rien à faire là. Je ne sais pas pourquoi il...
Si tu caches le message, tu remontes un peu plus. Non, je ne peux pas.
Il est modal.
Non, si tu remontes un peu plus.
D'accord.
Juste qu'on voit le feature Envy. Oui, oui.
Alors, là, typiquement,
Mets-le en bas la prochaine fois qu'il apparaît, juste pour qu'on puisse voir. Donc là, on parcourt chaque rental. Alors, il a un nom pourri, c'est Itch. Donc déjà, le premier truc qu'on pourrait faire, c'est changer. Si tu as la main... On peut l'appeler rental, donc location. Ça clarifiera un peu, parce que vous voyez, on l'a partout. Hop, attention, il t'a repris la main. Et donc le rent, rent all là, on est dans la classe customer. Je ne sais pas si vous voyez, mais on est dans la classe customer. Et le customer, il passe son temps à faire appel à de la logique qui est sur la location. Donc il y a un couplage, une dépendance entre la classe customer et l'objet rental. Ça veut dire que ce bout de code...
En fait, on ne voit pas très bien, mais il y a une classe de location. Donc on pourrait imaginer de déplacer cette portion de code dans le bon endroit.
On prend cet exemple parce qu'il est relativement simple, mais si on prend du vrai code legacy, on va trouver cette situation régulièrement. Et la difficulté, c'est que là, malgré tout, il y a des noms de classes qui sont à peu près corrects, mais dans la vraie vie, on n'aura même pas ça. On aura des classes qui ne portent pas correctement le bon nom. On verra tout à l'heure comment on peut s'en sortir. Mais là, juste par rapport à mon... À ma métaphore de la vaisselle. Il me faut une membrane, il me faut quelque chose qui me permette de faire une limite au code qui n'est pas au bon endroit.
Donc là, tu vas faire un carton, tu vas mettre le lave-vaisselle dedans.
Exactement. Je vais essayer.
Le carton s'appelle une méthode. Il va faire un extract méthode. Tout ce qui est sélectionné là va être mis dans un endroit qu'on appelle une méthode. Donc le carton. Et une fois que...
Je vais l'appeler Computer Moon pour l'instant, qui sera finalement, dans un premier temps, suffisant pour déplacer le code.
Quand on travaille sur du code légation, on n'est pas interdit d'améliorer la lisibilité, c'est-à-dire le nommage. Le nommage, c'est clé, parce qu'on passe 70% de notre temps à lire du code. Par rapport à en écrire. Donc c'est important de ne pas lire des inepties. Je disais le code ment, parce qu'on a des noms qui sont pourris bien souvent.
Donc une fois qu'on a fait ça, on a pris la portion de code qui n'était pas correctement placée et on l'a encapsulée dans une méthode, mais la méthode est finalement toujours au mauvais endroit. Il faut la déplacer dans la bonne classe.
Tu prends le carton et tu le fous dans la salle de bain ou dans la cuisine en l'occurrence.
C'est-à-dire dans la classe Renthal?
Oui, dans la classe Renthal.
pour déplacer le code.
Quand on travaille sur du code légation, on n'est pas interdit d'améliorer la lisibilité, c'est-à-dire le nommage. Le nommage, c'est clé, parce qu'on passe 70% de notre temps à lire du code par rapport à en écrire. Donc c'est important de ne pas lire des inepties. Je disais le code ment, parce qu'on a des noms qui sont pourris bien souvent.
Donc, une fois qu'on a fait ça, on a pris la portion de code qui n'était pas correctement placée et on l'a encapsulée dans une méthode, mais la méthode est finalement toujours au même endroit. Il faut la déplacer dans la bonne classe.
Tu prends le carton et tu le fous dans la salle de bain ou dans la cuisine en l'occurrence. C'est-à-dire dans la classe Rental?
Oui, dans la classe Rental.
Donc là, il est en train de faire son déménagement.
À l'aide des outils. Et voilà, donc tu as déplacé le code. Donc là, on est toujours sur la classe Customer, et donc on voit que la méthode a disparu. Et elle est au bon endroit.
Voilà, donc là, je suis effectivement dans la méthode déplacée. En fait, c'est ce truc-là qui est... C'est ça qui est... Je trouvais ça plus probable de le montrer. Ne clique pas.
Je ne fais plus de laser, donc c'est moi le laser.
Voilà, donc l'élément a été déplacé, mais il y a une aberration quand même. L'aberration, c'est que la méthode est maintenant dans la classe de location et reçoit une location. La méthode est statique. On va faire un dernier move de manière à ce que la méthode devienne non statique.
Donc là, tu enlèves le carton, tu pérennises en quelque sorte le fait que cette logique-là, elle se trouve maintenant à cet endroit.
Et donc dans le code d'origine, maintenant, on a l'instance de l'item de la collection Rental qui appelle le calcul.
Juste un petit exemple, est-ce que ceux qui n'ont jamais codé ont un peu compris ce qu'on vient de faire ou pas? Oui? Ok, c'est bon alors.
Donc quand on touche à du legacy, on passe notre temps à dire, tiens, qu'est-ce que c'est que ce truc? Pourquoi il est là? Déjà, on peut mieux le nommer et à le déplacer.
Donc ça, c'était le Cosmel. On a vu première partie la culture, deuxième partie les pratiques. Donc la troisième partie, on s'attaque un peu au dur du sujet.
À l'assaut.
À l'assaut du legacy, on monte dans la camionnette et puis on y va. On y va, on y va, on y va. Alors par où on commence, Bruno?
Ça dépend un peu de la surface à travailler. Donc toujours, effectivement, on est motivé par mettre la valeur en premier. Ça, ça ne change pas.
Moi, j'ai quand même vu des projets de refactoring, donc on change la structure interne du code. Qui n'étaient pas toujours motivés par des objectifs métiers.
Là, non. Ça peut être l'occasion parce qu'on sait qu'on va actuer une nouvelle fonctionnalité dans une portion de code. Et donc, on essaye de faire la place nette avant d'intégrer la nouvelle fonctionnalité.
Donc, un peu comme avant de peindre dans mon salon, je ponce, je fais les enduits, etc. C'est un travail préparatoire. Mais ça doit apporter de la valeur parce que sinon il ne faut pas le faire. Si ce qu'on fait n'a pas... Ça n'a pas de valeur, autant ne pas le faire. Ça paraît évident, mais le nombre de projets où j'ai vu des actions comme ça, on ne savait pas où on allait.
Souvent, on a la remarque que chez nous, non seulement c'est différent, mais le code n'est pas refactorable.
C'est facile, tu nous as montré un petit exemple tout pourri, il y avait déjà les tests, mais si mon code n'est pas testable, c'est un peu ce qu'on entend. Même réponse, pas testable.
Alors oui, il y a un paradoxe quand même.
Oui, il y a un paradoxe parce que d'un côté, on veut poser des tests, on veut refactorer. Mais on ne peut pas refactorer sans test. Enfin, voilà, c'est un peu paradoxal. Donc, la question, c'est comment on s'y prend? Alors, comment on s'y prend? C'est qu'à un moment donné, il va falloir sauter sans parachute. Sans filet. Mais on ne va pas le faire n'importe comment. On va le faire en respectant des patterns qui vont nous permettre d'assurer ce risque. Donc on va regarder excessivement toutes les modifications qu'on fait. On va garder un seul objectif à la fois. On ne va jamais changer d'objectif durant une modification. On ne va pas changer les contrats publics et on va effectivement se reposer sur le compilateur parce qu'on n'a plus que ça pour vérifier si on ne casse pas tout. Un autre élément, c'est qu'on va préférer le faire en pair ou en mob programming pour s'assurer qu'on ne fait pas de bêtises.
On va s'enlever une partie de la pression quand même, parce que quand on touche à du code, Legacy, il y a de la valeur métier, il y a de la prod derrière, en général. Donc le faire tout seul, c'est une grosse pression. Donc le faire à plusieurs, déjà, c'est un gage de sérénité et puis d'efficacité aussi.
Il y a surtout quelques techniques, parce que là c'est sur les premiers mètres où on n'a vraiment rien, donc il faut qu'on avance un tout petit peu pour pouvoir introduire nos premiers tests.
Mais il y a des techniques pour briser nos chaînes, briser nos dépendances. C'est quoi une dépendance dans le contexte Legacy?
Une dépendance, c'est finalement le fait que le code dépend d'un autre code qui lui-même, parfois, indirectement dépend du point de départ. Donc on a des cycles, c'est très difficile en fait. À commencer à tester. C'est pour ça que briser ce genre de dépendance nous permet d'isoler et d'introduire un premier test.
Indépendance, ça peut être une base de données, un service, des problèmes de données?
Oui, une base de données. En fait, tout ce qui ne nous permet pas de garantir une exécution stable. C'est-à-dire que si je lance une première fois, j'ai un résultat, et une seconde fois, j'ai un second résultat, Le test, ça ne va pas. Donc, il faut se rendre indépendant des dates, des threads, des appels statiques, plein de choses.
Donc, là, pareil, il y a plein de techniques. Il y en a quelques-unes qui sont affichées là. On aurait pu en faire en live coding, mais sur des techniques un peu avancées pour vraiment, même quand le code nous paraît intestable, variable statique, dépendance à une base de données dont on n'est pas le maître, etc. Sachez juste qu'il y a toujours des solutions. Pour ceux qui s'intéressent, on pourra en discuter après. Mais il y a toujours des solutions techniques pour se libérer de ces chaînes.
Alors, comment ça en musique dans la vraie vie? Ce sont des techniques, etc. La stratégie, ça va être quoi? On va retenir trois stratégies.
On a classé trois contextes, trois approches qui symbolisent à peu près les cas les plus classiques.
Ce qui nous prendra quelques heures, ce qui nous prendra quelques jours et ce qui nous prendra quelques mois. On va partir sur ça. Ce qui nous prendra quelques heures.
Oui, alors quelques heures et une caractéristique, c'est qu'on est seul. C'est-à-dire qu'on n'a pas ce qu'on appelle l'expert du domaine avec nous. Donc le code, on ne le comprend pas bien. Et donc on va avoir recours à une technique qui est le Golden Master. Thomas, tu peux peut-être nous expliquer le Golden Master.
C'est une technique que j'aime bien. Golden Master, c'est quoi? C'est je prends du code Legacy. Je vais le cloner pour avoir une nouvelle version. Ça va être ma version de travail. Avant de toucher à quoi que ce soit, ce que je veux, c'est obtenir une version de travail qui ait le même comportement. Je vais considérer ces deux portions de code, ces deux éléments du système comme des boîtes noires. Je vais créer un test qui va, si j'envoie ces inputs-là dans les deux boîtes noires, je dois avoir les mêmes résultats dans les deux cas. C'est-à-dire que j'envoie un input dans le code legacy, j'ai une sortie. J'envoie ce même input dans ma nouvelle boîte noire et je dois vérifier que j'ai la même sortie ça permet Une fois qu'on a ce test-là, on va pouvoir refactorer, on va pouvoir restructurer, améliorer le code, la nouvelle copie, on va dire, c'est sur quoi on va travailler, tout en garantissant qu'on respecte le contrat, le comportement legacy. Donc on ne prend pas de risque, à chaque fois on avance avec sûreté, et c'est ce harnais de test qui nous permet de le faire. C'est d'autant plus génial qu'il n'est pas nécessaire de comprendre le comportement. Au départ? Au départ, oui. L'objectif, ça va être de ressaisir et de comprendre un peu ce que fait ce code pour se le réapproprier. Mais dès le début, on peut avancer de manière sûre, même si on n'a pas tout compris. Donc c'est un bon point de départ.
L'autre élément, c'est sur une application. Donc là, on a plus que quelques heures.
Là, ce n'est pas un fragment, c'est un ensemble de composants. Donc, on est dans une phase d'exploration en largeur. C'est-à-dire qu'on va essayer de comprendre globalement la cinématique globale. On ne va pas forcément aller dans le détail parce que ce qu'on veut, c'est... Vu qu'on ne connaît pas forcément bien le fonctionnement, puisque le code n'est pas très bien écrit, on l'a dit, il est parfois menteur, et cette fois-ci, on va avoir un expert du domaine, un ou plusieurs. On va établir des conversations avec lui. On va être un peu... Lui, il est aveugle, et nous, on est ses yeux, et on va lui dire, voilà, ça parle de ça, est-ce que ça t'évoque quelque chose? Est-ce que ça te rappelle quelque chose? Et à ce moment-là, il va donner des fonctionnalités et on va essayer, au regard de ce qu'il va nous dire, de retrouver ces fonctionnalités. Ce qui va nous permettre, une fois qu'on a compris, de poser le premier test.
Alors retranscrire ce qu'on a compris ensemble à travers ce travail d'exploration, à travers un test.
Voilà, et toujours pareil, on va éliminer, une fois qu'on a posé le test, on va éliminer le code mail. Comme on a le test qui nous garantit le comportement, on n'est plus en sécurité.
Donc là, on l'a fait sur une application. Ça vous parle, là, ce qu'on vient de dire, le type de stratégie sur une application? L'exploration et puis pour... On va écrire des tests. Oui, je vois quelques têtes qui hoche. Donc, OK. Alors, la troisième?
C'est sur un département, un SI, par exemple. Là, c'est beaucoup plus large. On n'est pas du tout dans les mêmes considérations en termes de temps. Mais ça peut être effectivement une bonne posture si, effectivement, on sait qu'on va être frappé par une nouvelle fonctionnalité qui va toucher l'ensemble du SI. Et donc, il va falloir effectivement retravailler le code en amont. Donc on va appliquer la même chose que dans une application au niveau de chacune des équipes et on va reporter quotidiennement les modifications qu'on a faites de manière...
On travaille en parallèle, chaque équipe travaille en parallèle.
Mais on va essayer d'homogéniser les informations entre toutes les équipes. Ça peut prendre un petit peu de temps, mais ça va être l'occasion d'avoir des conversations, d'avoir des idées et donc d'améliorer le travail de chacun. Parce que les équipes se connaissent, mais ne travaillent pas quotidiennement ensemble.
Donc on travaille en parallèle et on fait des rétrospectives régulièrement pour partager ce qu'on a compris et ce que l'autre a compris et se resynchroniser. Ok, alors on peut aussi...
Alors ça c'est quelque chose qu'on a pu faire à plusieurs dans une grande banque rouge et noire. Les chefs de projet étaient relativement reconnaissants des nouvelles compétences des développeurs.
Vous les aviez coachés ?
Oui, on les avait coachés, etc. Ils avaient les compétences de refactoring même avancées. Et ils ont eu l'idée de gamifier, au niveau de plusieurs équipes, un refactoring réel, où finalement toute la journée, les gens allaient travailler sur du refactoring avec des points divers. Les métriques n'étaient pas forcément équivalentes suivant les équipes. Et on a vu des équipes le faire, mais avec un vrai bonheur. C'est-à-dire que là, on était sur du code legacy, le management était heureux, les développeurs étaient heureux.
Enfin, une situation qu'on n'aurait jamais pu imaginer.
C'est comme une kermesse d'école, mais toute la journée, tout le monde bosse pour essayer de nettoyer un maximum la cour d'or et créer.
Donc c'est possible. On peut faire du legacy en étant... On est heureux.
Ça a été compliqué de convaincre le...
Non, en fait, c'est venu d'eux. C'est le management qui nous a demandé. C'est même pas nous.
C'est ça qui est original. Alors, si c'est vraiment la merde, si vraiment les experts se sont barrés, ils sont tous partis, on n'a pas de test, le métier n'est pas dispo, Bon, alors là, il y a plusieurs stratégies possibles. En général, les gens, ce qu'ils aiment bien faire, c'est ça. C'est tout faire péter. Alors vous ne le voyez pas, c'est la fin de Fight Club, où ils sont deux à regarder la ville qui explose.
Les banques explosées.
Donc, alors ça, c'est une solution quelque part de facilité. Et moi, c'est une sorte d'anti-pattern que j'observais à travers les années. C'est-à-dire que j'ai vu plein de gens faire ça. Et se rendre compte au bout de un an, un an et demi, que le code qui leur paraissait un peu chelou, le code legacy d'avant, en fait ils faisaient des trucs qui étaient quand même pas si con que ça. Et qu'ils sont amenés à refaire la même chose, à refaire le même travail de compréhension, sauf qu'ils se sont fait plaisir avec des nouvelles stacks technologiques, ils ont cramé un peu plus de fuel du business pour y arriver, ils s'en foutent, c'est mieux pour le CV. Moins pour la valeur métier. Mais voilà, donc ça c'est franchement, moi je le vois de plus en plus comme un anti-pattern, de tout refaire from scratch. Et une autre stratégie qui vient du domaine de Raven Design et d'Eric Evans en particulier, ça s'appelle le bubble context. Le bubble context c'est un peu une bulle d'innovation, une bulle de code propre dans un océan de legacy. Alors là vous ne le voyez pas du tout, mais il y a une sorte de contexte legacy qui est un peu bizarre. Et en fait, le bubble context c'est quoi? On va faire du code... De manière propre, on va faire du TDD, on va créer des tests, on va avoir une sémantique qui sera la plus fidèle possible par rapport au métier, tout ça dans une sorte de membrane. Pourquoi une membrane? C'est pour pas que le code legacy vienne polluer les modèles de données, la terminologie foireuse, qu'elle vienne polluer cette nouvelle portion de code qui sera à l'intérieur du système legacy. Alors c'est un intérêt, c'est que ça permet de reprendre un peu de fierté, un peu de confiance, un peu de plaisir au quotidien, quand on est sur une application legacy, parfois pour le moral ça mine, donc là ça veut dire qu'on peut se reprendre en main, sur l'ajout d'une nouvelle fonctionnalité par exemple, et on travaille avec des... d'aujourd'hui, pas des standards d'il y a 10 ans, si l'application a 10 ans, etc. Donc ça, pour le moral, c'est bon et c'est assez efficace. Reste à savoir sur quoi vous allez le faire, sur une nouvelle valeur, sur... Enfin voilà, ça, ça reste des discussions à avoir, mais sachez que ça existe et que ça marche plutôt pas mal. Alors oui, pour passer du code propre au code dégueulasse, on a une sorte de sas de décompression qu'on appelle un anti-corruption layer. Et donc, il va être comme un sas de décompression qui va traduire le modèle foireux au nouveau modèle pour vous, pour éviter que le nouveau modèle soit pollué, le nouveau code soit pollué. Donc voilà, bubble, contexte. Temps de conclure. Premier point, le legacy, c'est vous, c'est nous, c'est nous tous. Ce n'est pas les autres. Ce n'est pas ceux qui étaient là avant. Puisque, à moins d'une coïncidence, de vivre encore et encore les mêmes situations, quelque part, il faut qu'on se réveille un peu.
Oui, effectivement, il faut s'intéresser au métier, il faut donner du sens. C'est même une posture de tout instant, c'est-à-dire comprendre la motivation de chaque chose, de manière à créer au sein de chacun une représentation mentale qui va pouvoir s'aligner avec le métier. C'est effectivement essentiel.
Se comprendre, c'est la base, mais honnêtement, moi, je le vois très peu. Et puis, s'entraîner avant de partir à l'assaut. Bruno a parlé de Code Cata. Il y a tout un tas de techniques, les techniques pour briser les dépendances. Michael Fizer s'en parle dans son bouquin sur Working Effective, Lee with Legacy Coach, je crois. Il y a des techniques. Ne soyez pas désespérés, même si quelqu'un vous dit non, mais dans notre cas, ce n'est pas possible d'écrire des tests, ce n'est pas possible de changer. Ce n'est pas vrai. Donc, voilà. Et puis, c'est important, c'est de reprendre le contrôle et d'arrêter de subir. Moi, je ne veux plus travailler dans des équipes où on se trouve des excuses pour passer notre temps à subir, à jeindre, à se tirer dans les pattes et à ne pas trouver du bonheur, en tout cas du plaisir, à travailler ensemble. Donc voilà. Rejoignez-nous, rejoignez le Legacy Club, ceux qui ont envie de reprendre un peu le contrôle sur leur carrière et sur leur quotidien. Alors au début on est parti sur l'image Fight Club, c'était un peu vendeur et machin, mais en fait c'est pas vraiment ça qui est le plus représentatif de ce dont on vous a parlé. Si je devais retenir un truc, alors vous le voyez encore moins que le Fight Club, c'est le Breakfast Club pour les... vieux de la vieille qui ont déjà dû voir ce film. Ceux qui ne l'ont pas vu, c'est quoi? C'est un film où des adolescents se font coller un samedi après-midi. Ils ne partagent rien. Il y a la gosse de riche, le rebelle, l'ado sportif. Ils ont tous un peu des archétypes. Donc au début, ils se rentrent un peu dedans de manière assez virulente. On leur laisse un peu les clés du collège ou de la fac pendant le samedi. Et ils vont se rendre compte à travers cette journée qu'ils partagent plus de souffrance et ils ont plus de choses en commun que ce qu'ils imaginaient au début de la journée.
Ça ressemblerait plus à ça un Legacy Club pour nous. Un endroit où on partage des retours d'expérience, on se refile des bonnes astuces pour arrêter de souffrir et reprendre un peu le contrôle des situations et des projets sur lesquels on bosse. Je crois qu'il ne nous reste plus qu'à vous remercier. Le Pojo et Clipplose. Merci beaucoup.
Merci à vous.

Transcription