Blog Arolla

Socrates 2022 – Ateliers

J’ai assisté à l’édition de la conférence SoCraTes de mars 2022. Les deux premiers jours sont consacrés à des sessions de discussions, live-codings, ensemble programming, ou encore présentations, toutes spontanément proposées par les participants même, le matin du jour où elles sont planifiées. Le 3e jour se tiennent des ateliers dans le même esprit d’organisation spontanée. J’ai eu l’occasion de participer à deux ateliers animés par Laurent Bossavit : « Design patterns, stop using them, start writing them » (les design patterns/patrons de conception, cessez de les utiliser, écrivez-en) et « writer’s review » (relecture de l'auteur) dont je souhaitais vous rendre compte.

Design patterns, stop using them, start writing them

Les design patterns/patrons de conception, cessez de les utiliser, écrivez-en

Cette session s’est ouverte sur une rétrospective des précurseurs ayant, par leur contribution, mené à l’émergence des design patterns. La pierre angulaire de ce réseau de novateurs est l’architecte du bâtiment Christopher Alexander, décédé le 17 mars 2022 alors que débutait SoCraTes. Dans les années 70, il a théorisé le concept de « pattern », que l’on peut traduire par « motif », « patron » ou encore « modèle », au travers de ses publications.

Ce qu’est un pattern

Un pattern est une solution a un problème dans un contexte donné. Il n’y a pas de solution qui marche dans tous les contextes. Une solution est même parfois une source de nouveaux problèmes. On peut dire qu’un pattern appliqué dans un mauvais contexte est un anti-pattern. Un pattern est répétable. Il doit exister au moins trois exemples d’application réussie du pattern pour le valider. Un pattern nait d’un processus heuristique. Il émerge peu à peu d’un système de forces contraires jusqu’à devenir une solution stable. Il possède une forme reconnaissable, une structure sous-jacente. On peut alors lui donner un nom et en user pour reconnaitre une situation problématique qu’il résout.

Les premiers patterns dans le champ de l’informatique

Ce concept inspira des programmeurs tels que Kent Beck, à l’origine de l’extreme programming (XP) et JUnit, et Ward Cunningham, le créateur du C2 wiki, qui proposèrent pour la 1ère fois un langage de pattern pour concevoir des interfaces graphiques, lors de la deuxième occurrence de la conférence OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) en 1987. Par la suite, l’initiative va s’enrichir de nombreuses propositions portées par une communauté de pionniers. Kent Beck et Grady Booch, initiateur de l’UML, lanceront les conférences PLoP (Pattern Languages of Programming) dédiées à ces langages. Le C2 wiki hébergera le dépôt du portland pattern repository qui regroupe lui aussi des propositions de formalisme de patterns. James Coplien proposera les C++ idioms. Norm Keith donnera naissance à la pratique agile de la rétrospective, un pattern pour l’amélioration continue. Linda Rising analysera les patterns de changements organisationnels. Richard Gabriel écrira Patterns of software : tales from the software community. Enfin, Eric Gamma, créateur d’Eclipse, publiera avec ses collègues du Gang Of Four, Richard Helm, Ralph Jonhson et John Vlissides, le livre de référence Design Patterns : Element of Reusable Object-Oriented Software en 1994, dont certains des patterns sont encore employés régulièrement de nos jours.

Le besoin d’écrire des patterns

Nous l’avons vu, un pattern s’applique à un contexte donné. Il ne faut donc pas chercher à en faire usage lorsque la situation ne s’y prête pas ou lorsqu’aucun problème n’a été rencontré. De plus, la plupart des design patterns connus ont été proposés dans les années 90 pour répondre aux problématiques fréquemment rencontrées à cette époque. Nous, les développeurs et développeuses évoluant dans le contexte actuel, ne sommes pas forcément confrontés aux mêmes défis. Nous pourrions avoir besoin de créer de nouveaux patterns. Sans même encore réussir dans cet exercice difficile, le simple fait d’envisager les patterns comme un outil à développer et non à utiliser, nous fait identifier les solutions heuristiques que nous utilisons au quotidien comme de potentiels candidats. Avec cet état d’esprit, nous pouvons repérer les problèmes insolubles récurrents et leur donner un nom pour en discuter entre nous, à attendant d’avoir trouvé le bon pattern.

Writer’s review

Relecture de l'auteur

Cette session a été l’occasion d’une expérience pratique de mise en application d’une méthode de revue d’article, la « fly-on-the-wall review ». L’objectif était de donner un feedback sur un texte rédigé par Christophe Thibaut (Octo) à propos du FishBowl Mob Programming, un pattern de facilitation de mob programming, qui a été expérimenté lors d’un précédent SoCraTes, et lors des meetups Dojo développement Paris. Nous étions quatre commentateurs.

Déroulement

Dans un premier temps, l’auteur se place sur un siège face à ses relecteurs. Il commence par décrire le contexte de sa proposition. Il entreprend ensuite la lecture de son texte à haute voix. Il poursuit sa lecture jusqu’au bout sans que les relecteurs n’interviennent ni ne réagissent. Ils sont autorisés à prendre des notes.

Sans un mot de plus, de sa part ni de la part de ses auditeurs, l’auteur retourne son siège pour leur tourner le dos. L’auteur ne s’exprime pas et ouvre grand ses oreilles. Il peut prendre des notes.

Commence alors la seconde phase. Les relecteurs entament une discussion en suivant les règles d’un plan en 3 parties. Tour à tour, ils résument le texte qu’ils viennent d’entendre en prenant garde à ne pas exprimer de jugement de valeur. Le tour de table suivant est uniquement dédié aux remarques positives sur la forme du texte. Puis, une fois que chacun a donné son opinion, viennent les remarques négatives selon le même procédé. Elles doivent toujours être accompagnées de suggestion d’amélioration. Jamais, ils ne s’adressent à l’auteur dont ils parlent comme d’un absent. Son nom est remplacé par le terme « L’auteur/L’autrice ». Ils ne débattent pas non plus entre eux, mais peuvent se faire référence lorsque c’est à leur tour de parler.

À la fin de cette phase, l’auteur est invité à se retourner. Il est autorisé à poser des questions pour obtenir des précisons sur ce qu’il vient d’entendre. Il ne se lance pas dans une défense ou une justification de ses choix. Il ne fait pas de commentaires sur ce qui n’a pas été compris. La session se conclut par les remerciements du groupe à l’auteur.

Bilan

Notre première constatation fut que nous avions oublié une partie du texte dont nous ne possédions pas de version écrite. Il était pourtant permis d’en avoir une. Cela a rendu nos remarques sur l’expression des idées de l’auteur plus évasives. Néanmoins, à mon avis, cela a peut-être permis de se faire une idée de ce qu’il reste du texte après une première lecture. Par exemple, nous avons pu deviner la structure du texte, son découpage en parties thématiques. Nous avons été capable de décrire l’essentiel du principe du FishBowl Mob Programming.

Respecter le protocole n’allait pas de soi. Parfois un membre du groupe pouvait dévier d’une règle et en être notifié par un autre. Nous devions nous contraindre à parler du bon sujet au bon moment. Cela peut être frustrant et donner des échanges qui manquent de spontanéité.

Néanmoins cette contrainte où chacun a un rôle à jouer en suivant les mêmes règles du jeu a sûrement contribué à réduire les frictions et à instaurer un cadre neutre. Cela était accentué par l’obligation de proposer une amélioration en cas de critiques. Elle évitait le recours aux jugements de valeur basés sur une préférence subjective et donnait à l’auteur des remarques constructives à mettre en pratique. Notre échange a notamment fait émerger l’idée d’accompagner le texte d’une image de mise en situation, en réponse au manque de clarté sur la description du déroulé du FishBowl Mob Programming que nous avions ressentie. Nous étions surement plus attentifs aux discours des autres. Les points de vue communs devenaient apparents en étant répétés par tous.

L’auteur a apprécié l’exercice et en a tiré un bilan positif. Nous avons pu nous exprimer librement sur sa création sans nous soucier de son regard ou de sa réaction. Libre à lui décider de suivre nos pistes, il aura toujours le dernier mot.

Plus de publications

Comments are closed.