Le demi-cercle (épisode 6 -- Conseils à emporter)

It's all talk until the code runs. Ward Cunningham

Le serveur a rassemblé quatre petites tables et le groupe s'est installé. On commande à manger. On parle surtout de programmation dans ce groupe. Quelqu'un lance une discussion sur la signification du nombre 42. Tu t'engages sur ton sujet : - Alors hier midi, on a fait un mob avec l'équipe, dans la salle de réunion.

Oleg, qui se propose souvent de faciliter le Mob Programming, répond : - Ok! Comment ça s'est passé ? - Pas très bien, en fait.

Tu as retenu l'attention du groupe. Tu poursuis : - Je vous passe les discussions interminables à propos des noms des classes et des méthodes. Il faut savoir que notre application n'est pas vraiment ce qui pourrait s'appeler un modèle du genre… - Tu veux dire que c'est du n'importe quoi ? - Pas tout à fait, mais ça manque de cohérence, c'est sûr, vu que cette base de code est en fait la réunion de plusieurs systèmes. - Ah là là, c'est le pire qui puisse arriver…

La personne qui semble la plus âgée du groupe, Victor, lance : - Quel est le pire nom de variable que vous ayez croisé sur votre chemin ?

On hésite à répondre. Victor s'exclame : - Toto2 !

Rires.

- Celle-là tu l'encadres et tu la suspends dans le hall d'entrée de la boîte. - Non, tu laisses un petit commentaire dans le code : slash, slash on n'est pas au cirque ! - Et là, quelqu'un commente ton commentaire : slash, slash, je voudrais bien t'y voir ! - Slash, slash , crénom changez ce nom de variable et arrêtez ce thread pourri ! - Slash, slash, tu peux parler, toi ! - Slash, slash, "tu causes, tu causes, c'est tout ce que tu sais faire."

Tu reprends le fil de la conversation : - Voilà, ça ne donnait pas tout à fait ça, mais pas loin. S'il n'y avait que les noms ça irait encore, remarquez. - Raconte-nous, dit Oleg. - Les discussions de noms de variables, ce n'est rien à côté des discussions sur le design. - Ah. - Vingt-cinq minutes sur le sujet de l'injection de dépendances et les constructeurs, ça finit par peser, à quatre personnes. - En effet. - Comme dit ma responsable de projet, « vous cramez du gaz ». - Et vous en êtes arrivé où ? - Tu veux dire ? - À propos de l’injection de dépendances… - Pour ce qui est de l’injection de dépendances, nulle part. Ça n’avait pas tant d’importance, vu que le code sur lequel on discutait n’est jamais exécuté de toutes façons.

Quelqu’un intervient : - Ben voilà ! Ça met fin aux discussions. - Tu ne vas pas le croire, mais en fait non.

Oleg demande : - Comment avez-vous su que le code dont vous discutiez ne s'exécutait jamais ? - Oh très simplement : on a posé un break, on a lancé l'application et elle ne s'est pas arrêtée sur le break.

Un autre participant lance : - Breakpoint Driven Development !

Tu commences à te sentir mal à l'aise avec le ton de cette conversation. Ou bien c'est la fatigue. Tu conclus : - Bref. Ça n'a pas marché comme je l'espérais. Si vous avez des suggestions, je suis preneur.

Oleg intervient : - J'ai remarqué qu'en général, les discussions à propos du code sont bien plus efficaces lorsque le code a des tests. Dans ton cas, est-ce qu'il en avait ? - Non, malheureusement. Enfin, on teste l'application avant de la livrer, mais je pense que ce n'est pas à ce type de test que tu fais référence. - N'importe quel test, c'est mieux que rien du tout. Mais de préférence des tests automatisés, répétables, qui s'exécutent indépendamment des ressources extérieures. - Alors non, le code n'a pas ce type de tests pour le moment. L'intérêt que je voyais dans le fait de travailler à plusieurs était justement de réfléchir à la façon dont on pourrait commencer à écrire des tests…

Victor demande : - Oleg, pourquoi les discussions sur le code sont-elles plus efficaces lorsque le code a des tests ? - Parce qu'avec des tests, tu peux protéger ton code contre des régressions éventuelles, alors que sans test, tu risques à tout moment d'introduire un défaut. - OK, mais en quoi est-ce que cela rend la discussion plus efficace ? - J'y viens : sans test, tu ne peux donc pas améliorer le design, sauf à mettre l'application en risque. Tu peux avoir envie de changer le design, mais tu sais que ce changement n'aboutira pas tout de suite à du code opérationnel. Pas sans un effort considérable de test en aval. - C’est sûr. - Tu te retrouves donc avec ce que tu penses être une bonne idée mais tu ne peux pas la montrer à tes collègues immédiatement. Tu te sens forcé soit de les convaincre, soit de laisser tomber l'idée.

Quelqu’un ajoute : - Alors que si tu pouvais simplement refactorer le code en t'appuyant sur les tests, c'est le code qui parlerait à ta place. - Exactement, reprend Oleg. Lorsque les tests se font en aval du design et qu'ils sont de plus assez coûteux, alors on a tendance à attendre d’avoir regroupé un paquet d'idées avant de décider si on fait un changement ou non. Et ce n'est pas efficace. - Avec des tests, tu peux mettre en place ton idée d'amélioration. Si ton idée casse les tests, ou bien si elle n'est pas convaincante après tout, tu peux revenir en arrière rapidement. - Ce qui revient à dire que quand il a des tests, le code peut participer à la discussion. Sans test, le code ne participe pas à la conversation. - Exactement. La conversation devient abstraite, "en l'air". C'est ce qui rend les tests si utiles lors d'une discussion sur le design. - C'est à dire lors d'un refactoring. - Oui.

Tu fais signe que tu entends bien ces arguments : - Je vois. Mais ça ne va pas être simple. Pour poser des tests sur le code, il faudrait le refactorer justement. Mais refactorer du code qui n'a pas de test, c'est trop risqué. On ne sait pas dans quoi on s'embarque et combien de temps ça va prendre.

Oleg acquiesce. Puis il ajoute : - En parlant de temps, ton équipe et toi vous devriez essayer de time-boxer ce que vous faites durant la session. C'est un bon moyen de vérifier qu'on ne part pas dans une mission impossible, un débat stérile, ou un enchaînement de sous-problèmes. - Tu veux dire : décider à l'avance le temps que nous devons prendre pour chaque tâche ? - Plutôt, limiter le temps passé par le Driver au clavier, en instaurant une rotation. Toutes les 5 minutes par exemple. Et aussi faire tourner les rôles, de manière à changer l'angle d'attaque et surtout privilégier l'action. - Je ne suis pas sûr que tout le monde accepterait ce mode de fonctionnement. Tu me diras, c'est notre premier essai, je ne peux pas vraiment en juger.

Un des participants remarque : - Des développeurs qui ont travaillé seul sur leur code pendant des années voire des décennies ne peuvent pas constituer une excellente équipe en Mob Programming du jour au lendemain. Le contraire serait surprenant. Si tu veux que ce mode de développement marche pour vous, il faut lui donner un peu de temps.

Oleg ajoute : - Et surtout il faut le faciliter. Sans facilitation, il est difficile pour un groupe de réfléchir ensemble : certains parlent trop, d'autres pas assez… - Certains interviennent plus souvent, parce qu'ils ont plus de facilité à parler en groupe, ce qui fait que les autres — qui peuvent avoir une idée encore meilleure que l'idée proposée — attendent de pouvoir intervenir. - Ou bien ils renoncent carrément à dire leur idée.

Oleg compte sur ses doigts : - Il y a ceux qui parlent trop tard : ils pourraient contribuer plus tôt mais, pour une raison ou une autre, ils n'ont pas suffisamment confiance que leur idée sera entendue. Il y a ceux qui au contraire parlent trop "en avance" : ils détectent des problèmes potentiels dans l'évolution possible d'un design que les autres ne voient pas encore, et ils interviennent pour empêcher la solution de se mettre en place. Ce qui pousse les autres à insister. - Chez nous c'est souvent le cas; du coup il n'y a pas moyen de commencer avec quelque chose de simple ; tout de suite il y a des objections, et alors on se met à construire une usine à gaz afin de les prendre en compte.

Oleg continue son énumération : - Certains parlent "à côté", ils sont désengagés : ils critiquent les choix passés sans vraiment proposer d'alternative. - Ou bien ils s'occupent de quelque chose d'autre sur leur propre écran, tout en sortant des vannes.

La discussion va vers sa fin. Les visages s'éteignent progressivement. Ton énergie diminue.

- Bref, conclut Oleg, si tu veux que ton équipe s'auto-organise, il va falloir l'aider. - J'ai l'impression que le Mob Programming fonctionne plutôt avec des équipes où l'on s'entend bien. - Je pourrais dire exactement l'inverse, répond Oleg, à savoir que dans mon équipe on s'entend bien parce qu'on a beaucoup codé ensemble.

Il se fait tard. Tu te diriges vers le métro le plus proche. Tu remets à plus tard la décision d'essayer à nouveau ou non ce mode de fonctionnement avec ton équipe. Trop de variables.

(à suivre) Episodes Précédents : 1 -- Si le code pouvait parler 2 -- Voir / Avancer 3 -- Communication Breakdown 4 -- Driver / Navigator 5 -- Brown Bag Lunch