[{"data":1,"prerenderedAt":115},["ShallowReactive",2],{"blog:fr:how-we-agree-on-a-shape":3},{"id":4,"title":5,"author":6,"body":7,"date":101,"description":102,"extension":103,"meta":104,"navigation":105,"path":106,"publishAt":101,"seo":107,"stem":108,"tags":109,"__hash__":114},"blog_fr\u002Fblog\u002Fhow-we-agree-on-a-shape\u002Ffr.md","Comment nous nous accordons sur une forme avant de la construire","Aptli",{"type":8,"value":9,"toc":91},"minimark",[10,15,19,22,26,29,32,36,39,42,45,49,52,55,59,62,65,69],[11,12,14],"h2",{"id":13},"où-nous-en-étions-restés","Où nous en étions restés",[16,17,18],"p",{},"Il y a quelques semaines, nous avons écrit sur la façon dont notre frontend obtient les mêmes patrons de conception qu'un développeur Java reconnaîtrait, à partir de tables et de composables, avec presque aucune classe nulle part. La conversation à ce sujet ne s'est pas arrêtée à la publication. Au sein de l'équipe, elle s'est poursuivie, parce que ce texte touchait à quelque chose de plus grand qu'un seul patron : nous avions un nom pour chacune de ces formes, et tout le monde savait déjà ce que ce nom signifiait avant même que la conversation ne commence.",[16,20,21],{},"Cette habitude mérite une explication qui lui est propre, indépendante de toute règle spécifique. Il y a quelque temps, quelqu’un a estimé que nommer une forme et la noter par écrit en valait la peine, et l’équipe a continué à le faire depuis lors.",[11,23,25],{"id":24},"ce-quun-tutoriel-vous-apprend","Ce qu'un tutoriel vous apprend",[16,27,28],{},"Les bibliothèques de composants sont une vraie commodité. On en importe une, et un sélecteur de date ou un menu déroulant qui fonctionne arrive déjà construit, éprouvé par bien plus d'usage qu'une seule équipe ne pourrait lui en donner. Un extrait de code fait gagner les dix minutes qu'il faut pour se rappeler la syntaxe exacte de quelque chose fait assez rarement pour être oublié. Un tutoriel est souvent le moyen le plus rapide d'apprendre réellement une technique, parce qu'il parcourt le raisonnement derrière elle.",[16,30,31],{},"Tout cela est utile, et s'adresse à une seule personne, qui apprend une technique, en une seule séance. Une équipe se pose une deuxième question : à quoi un groupe de personnes, dont la plupart n'ont pas écrit le code d'origine, devrait-il se référer la prochaine fois qu'une décision de ce type se présentera ? La réponse à cette question revient à l'équipe.",[11,33,35],{"id":34},"la-pratique-concrète","La pratique concrète",[16,37,38],{},"Voici à peu près comment cela se passe chez nous. Quelqu'un remarque que la même forme de problème se présente pour la deuxième ou la troisième fois, généralement en relisant une pull request qui la résout un peu différemment que la dernière fois. Cette personne donne un nom à la forme dans la conversation, dans le commentaire de revue lui-même. Si le nom survit à quelques usages de plus, il est consigné par écrit : ce qu'est la forme, quand elle s'applique, et un court exemple déjà présent dans le code.",[16,40,41],{},"La liste écrite est volontairement succincte et recense les modèles utilisés par l'équipe. Elle a pour but de permettre qu'une décision de conception puisse se résumer à une simple phrase. Lorsqu'une personne écrit « faites-en un registre » lors d'une revue, tous ceux qui lisent ce commentaire savent déjà de quel modèle il s'agit, sans qu'il soit nécessaire de recourir à un schéma ou à une réunion.",[16,43,44],{},"Elle s'avère également très utile lors de la première semaine d'un nouvel ingénieur. En parcourant cette liste, celui-ci apprend les quelques modèles utilisés dans le code source, tels qu'ils sont décrits par l'équipe elle-même. Un guide de style explique comment mettre en forme une ligne de code. Cette liste, quant à elle, explique comment réfléchir à une décision avant même d'écrire la ligne de code.",[11,46,48],{"id":47},"pourquoi-nous-nous-en-donnons-la-peine","Pourquoi nous nous en donnons la peine",[16,50,51],{},"Donner un nom à une structure nécessite un échange, et le noter prend du temps à quelqu’un, temps qui devra être consacré à nouveau à mesure que la base de code évolue. L'avantage est celui que le livre que nous avons mentionné la dernière fois met directement en avant : un nom partagé permet de prendre rapidement une bonne décision et rend visible une mauvaise décision alors qu'elle n'est encore qu'une proposition, avant qu'elle ne se transforme en une demande de modification qui devra être annulée.",[16,53,54],{},"Le moteur de notifications que nous avons décrit la dernière fois, toujours à une quarantaine de lignes après chaque ajout, a tenu exactement pour cette raison. La forme avait un nom avant l'arrivée de la quatrième ou cinquième notification. En ajouter une ensuite n'a demandé aucune délibération.",[11,56,58],{"id":57},"la-part-humaine-dune-décision-architecturale","La part humaine d'une décision architecturale",[16,60,61],{},"Il s'agit avant tout d'une habitude qui permet à un groupe de personnes de se mettre d'accord sur certains points, bien plus qu'une pratique de programmation. Une équipe prend ses décisions, revue par revue et discussion par discussion, et la liste consigne ces décisions une fois qu'elles ont été prises. Chaque décision n'est prise qu'une seule fois.",[16,63,64],{},"Cela tient que le langage soit Java ou JavaScript, et que l'équipe compte cinq personnes ou cinquante. La forme dans le code suit la forme de la façon dont les personnes qui le construisent se parlent entre elles à ce sujet, et c'est cette seconde partie à laquelle nous consacrons l'attention la plus délibérée.",[11,66,68],{"id":67},"résumé","Résumé",[70,71,72,76,79,82,85,88],"ul",{},[73,74,75],"li",{},"Les bibliothèques de composants, les extraits de code et les tutoriels enseignent chacun une technique à une seule personne en une seule séance. Un vocabulaire partagé pour une forme de conception vit entre les personnes d'une équipe, et sert à tout le monde en même temps.",[73,77,78],{},"La pratique, concrètement : un nom proposé dans un commentaire de revue, éprouvé sur quelques cas réels de plus, puis consigné avec ce qu'il est, quand il s'applique, et un court exemple déjà présent dans le code.",[73,80,81],{},"La liste écrite reste courte volontairement. Elle existe pour qu'une décision de conception puisse tenir en une phrase.",[73,83,84],{},"Un nouveau développeur lit la liste dès sa première semaine. Il apprend les formes que le code utilise réellement, dans les mots de l'équipe, sans avoir à les assembler à partir d'ancien code.",[73,86,87],{},"Le gain est celui-là même que défend le livre derrière notre texte précédent : un nom partagé rend une bonne décision rapide, et une mauvaise décision visible pendant qu'elle n'est encore qu'une phrase.",[73,89,90],{},"C'est une habitude organisationnelle avant d'être une habitude de code. Une équipe se met d'accord sur les choses, une conversation à la fois, et la liste est l'endroit où ces accords sont conservés.",{"title":92,"searchDepth":93,"depth":93,"links":94},"",2,[95,96,97,98,99,100],{"id":13,"depth":93,"text":14},{"id":24,"depth":93,"text":25},{"id":34,"depth":93,"text":35},{"id":47,"depth":93,"text":48},{"id":57,"depth":93,"text":58},{"id":67,"depth":93,"text":68},"2026-09-16","Il y a quelques semaines, nous avons écrit sur la façon dont les patrons de conception apparaissent dans notre code sans classes. La conversation au sein de notre propre équipe ne s'est pas arrêtée à la publication. Voici l'habitude qui se cache derrière tout cela, et pourquoi nous la traitons comme un travail délibéré.","md",{},true,"\u002Fblog\u002Fhow-we-agree-on-a-shape\u002Ffr",{"title":5,"description":102},"blog\u002Fhow-we-agree-on-a-shape\u002Ffr",[110,111,112,113],"engineering","how-we-work","design-patterns","team-alignment","cpOxsoRgM9kSSHA19y_10mn8WNwkhonDvFTujjsNOLw",1791936520088]