Le demi-cercle (épisode 25 -- Fusions et Confusions)

One of my most productive days was throwing away 1000 lines of code. Ken Thompson

Tu sais qu'il s'agit d'un rêve. Tu arpentes les couloirs interminables et richement décorés de cet hôtel particulier, à la poursuite d'un majordome en costume rouge et gris, qui te devance d'une dizaine de mètres. Le plancher vernis craque bruyamment sous tes pas. Tu veux rattraper le majordome et lui parler, mais tu crains qu'il ne remarque ta présence et fasse demi-tour dans ta direction. Le majordome poursuit son chemin à pas de géants, couloir après couloir. Dans ta course c’est à peine si tu as le temps de remarquer les tentures, les scènes de chasses encadrées de bois doré, les lustres ancien régime. Le majordome s’arrête enfin, ouvre une porte sur sa droite, et entre. Tu le poursuis jusqu’à l’entrée d’une large pièce carrée, au milieu de laquelle se tient un homme derrière un bureau Louis XV. Le majordome s'approche de ce dernier et de sa main gantée de blanc lui tend un plateau d'argent en disant d'une voix basse :

- Voici le coupable, Monsieur le Gouverneur.

Frustré de ne pouvoir distinguer quoi que ce soit d’intéressant, tu te juches sur un guéridon qui se trouve à ta droite. Le Gouverneur observe silencieusement le contenu du plateau : un fusible ordinaire, pas plus grand qu'un filtre de cigarette, et noirci par le feu. Tu perds l'équilibre.

- Ouaaaaah ! - Ah, tu te réveilles enfin. Il est sept heures trente, pour info. Ton smartphone n'a pas sonné. Plus de batteries. - Je l'avais pourtant branché sur le secteur… - OK. Il faut que je file. À ce soir!

—

Tu te précipites dans l'ascenseur. Tu viens de manquer à ta résolution de prendre les escaliers chaque matin, mais c'est pour la bonne cause, puisque tu es en retard. Inutile d'accumuler les retards.

Tu entres dans le bureau et tu lances à la cantonnade : - J'arrive, désolé pour le retard, mon réveil n'a pas sonné.

Jéremie dit, les yeux rivés sur son écran : - Pas d'inquiétude, on n'a pas commencé. Audrey est partie voir si Maria se joint à nous.

Audrey revient et dit : - Elle ne peut pas, mais elle m'a laissé quelques infos à transmettre.

Farid lance une commande sur son poste de travail et annonce : - C'est bon pour moi, on peut commencer.

Jérémie connecte son PC au projecteur. Il dit : - Je vous préviens, je n'ai pas fait de slides, je me suis juste contenté de rassembler quelques infos dans un fichier texte.

Le mur du fond s'affiche tout en noir à l'exception d'une frise de petits caractères vert pomme. Farid demande : - Jérémie, peux-tu augmenter la taille de la police, s'il te plaît c'est illisible. - OK.

Tout en ajustant l'affichage du fichier revue d'itération.txt, Jérémie énonce d'un ton neutre les faits marquants de ces quatre dernières semaines :

- Douze stories "done", contre quinze stories engagées en début de mois. - Pas de défaut en recette détecté à ce jour (mais les tests sont toujours en cours, Claudia doit les terminer d'ici la fin de la semaine). - Augmentation de 25% des commits de refactoring sur l'ensemble de la base de code. - Augmentation de 35% du volume de code de tests sur la partie du code que nous avons modifiée pour réaliser les stories. Audrey prend la parole : - De son côté, Maria confirme que les stories qui passent les tests répondent correctement aux besoins, et qu'il n'y aura vraisemblablement pas de modification de dernière minute à faire. Elle tient également à souligner la réactivité dont nous avons fait preuve face au problème rencontré en production jeudi dernier. C'est pour un client important, et il a apprécié notre intervention, au point qu'il en a parlé sur Twitter.

Jérémie commente : - Eh bien voilà une nouvelle instance du syndrôme de Stockholm. Le client nous remercie d'avoir pris ses données en otages pendant deux heures, et nous embrasse sur les deux joues.

Audrey : - C'est peut-être un client compréhensif. Peut-être qu'il est lui-même développeur ou qu'il y a quelqu'un dans sa famille qui travaille comme développeur.

Tu interviens : - Ou bien il compare cette expérience à celle d'un autre incident, sur un logiciel pire que le nôtre.

Farid fait remarquer : - En tout état de cause, c'est toujours bon à prendre. Et puis ça montre dans quel sens on peut améliorer les choses.

Audrey reprend : - Au fait, Maria voulait savoir ce qu'il en est pour l'approche mob programming. Elle et Jean-Bernard n'en ont pas reparlé, mais ça l'intéresserait d'avoir une synthèse de la part de l'équipe, au cas où le sujet reviendrait sur le tapis en CoPil.

Jérémie fait remonter le curseur au sommet de l'éditeur, et répond : - À vrai dire, je ne pense pas que le terme de « mob » programming soit très approprié, ni très représentatif. - Ce n’est pas la question, dit Audrey. - Tu as raison.

Tu remarques : - En tout cas si on en croit ce que proclame ce compte-rendu d'itération, je pense qu'on peut se féliciter d'avoir essayé l'approche. Qu’est-ce que vous en dites ?

Au milieu du mur s’affiche un rectangle bleu contenant le message : Remplacer Lampe (#74)

Farid s’esclaffe : - Le projecteur est pas d’accord. Voilà ce qu’il en dit.

Tu dis : - J’espère qu’on a des lampes de rechange, ou bien qu’on peut en obtenir une rapidement.

Tu lances ton navigateur à la recherche de la page interne qui concerne le remplacement de matériel.

Jérémie insère en haut de son document des retours à la ligne afin que le texte s’affiche en dessous du rectangle bleu. Il murmure : - Ou bien on peut utiliser tout l’espace restant, c’est à dire entre les lignes 1 à 12 et 18 à 30…

Audrey s’impatiente : - Bon. On a fini la rétro ? Parce que j’ai une réunion qui commence dans 10 minutes.

Farid demande : - À propos des pourcentages sur les refactorings et le code de test, est-ce qu’on a les chiffres des mois précédents, pour comparer ?

Jérémie répond : - On a seulement les chiffres du mois dernier. Avant cette période, chacun faisait ses commits à une fréquence différente, et on ne signalait pas les actions de refactoring dans le compte-rendu. Pour ce qui est des tests unitaires, on pourrait faire l’exercice sur les mois antérieurs, mais le volume de code de test était pratiquement négligeable à cette époque. Par exemple, si tu regardes la version mise en production il y a un an…

Jérémie sélectionne la version dans le gestionnaire de source et l’installe sur son poste. Sur le mur s’affiche la première page d’un fichier nommé CoreBusinessLayeredManager.

La pièce n'est pas au même niveau que le reste du bâtiment, elle ne communique plus avec celui-ci. C'est une sorte d'étage intermédiaire sans doute aussi large qu'un hangar, plongé dans une obscurité quasi-totale. Des cloisons d'une hauteur variable, et qui doivent probablement partir des murs, divisent l'espace de manière arbitraire et désordonnée. Les compartiments ainsi formés sont vides, si on fait exception des câbles — des dizaines de câbles — qui chevauchent nonchalamment les cloisons, formant ainsi une toile qui s’étale sur toute la surface du hangar, à mi-hauteur. Dans certains compartiment, on trouve des câbles encore, posés à même le sol, ou bien toujours enroulés sur leur bobine.

Tu te demandes, sans toutefois poser la question à voix haute, ce qui a pu motiver la création de la classe qui s'affiche sur le mur, ainsi que les principes qui ont guidé sa conception.

Un espace inutile, mis au point fébrilement sur les conseils d'un architecte incompris, auquel on a fini par assigner un sens, parce qu'il se trouvait là, sur le chemin.

Jérémie observe : - Le code de cette classe par exemple, n'est exécuté par aucun test unitaire. Je le sais parce que j'ai fait tourner les outils de calcul de la couverture des tests. Mais même sans calcul de couverture, rien qu'en comptant le nombre de tests présents dans la classe de tests correspondante… - C'est à dire, dans ce cas, zéro, interrompt Audrey. - …Exactement reprend Jérémie, on peut mesurer avec une précision plus que suffisante la fiabilité du code en question.

Farid demande : - À quoi servirait d'écrire des tests unitaires sur cette classe ? Elle ne fait que passe-plat. Tu demandes : - À quoi servait d'écrire la classe elle-même ?

Farid te regarde, interloqué : - A passer les plats, bien sûr.

Bien sûr.

Jérémie rebondit sur la question de Farid : - C'est le problème avec ce genre de mesure. Elle ne te dit que ce qui a été compté. Elle ne te dit pas si ce que tu as compté est justifié, pertinent ou superflu, voire carrément faux.

Tu aimerais bien revenir plus en détail sur cette classe. Tu demandes : - Pourquoi écrivez-vous des tests unitaires sur le code que vous écrivez, en général ?

Audrey prend la balle au vol : - En ce qui me concerne, j'écris des tests unitaires pour m'assurer que le code fait bien ce que je pense qu'il doit faire. - Autrement dit, c'est une façon d'exprimer ton intention. - Exactement. - Quelle est l'intention du code qui a été écrit dans cette classe ?

Le groupe reste coi.

Jérémie tente une réponse : - C'est sûr que cette classe n'est plus raccord avec le reste du design…

Farid interrompt : - Mais maintenant qu'elle est ici, et qu'elle est utilisée, et qu'on voit qu'elle n'a aucun test, c'est comme si elle faisait baisser la moyenne. Est-ce que ça veut dire qu'on devrait écrire des tests inutiles, juste pour avoir de bon chiffres ?

Audrey se lève et se dirige vers la porte en disant : - Bien sûr que non. On est là pour produire un logiciel qui marche, pas pour produire de bons chiffres. Faut que j'y aille. - Alors qu'est-ce qu'on fait de ce code ? On ne peut pas le supprimer quand même !

Jérémy dit d'un ton calme : - Je ne sais pas exactement ce que fait le code, mais je suis sûr que si on le retire sans rien faire d'autre, alors l'application ne tourne plus.

Farid conclut : - Donc, dans le doute, je propose qu'on le garde tel quel. On écrira des tests plus tard, si on a le temps. Audrey, avant de partir, tu en dis quoi ?

Audrey se retourne et regarde un instant le code qui s'étale autour du rectangle bleu sur le mur. Elle conclut : - Est-ce qu'on est sûr que le code fait exactement ce qu'il devrait faire ? Non. Est-ce qu'on sait exactement ce que le code devrait faire ? Non plus. Mais pour une raison obscure, on ne peut plus s'en passer. C'est l'histoire du projet. A plus!

(à suivre) Episodes Précédents : 1 -- Si le code pouvait parler 2 -- Voir / Avancer 3 -- Communication Breakdown 4 -- Driver / Navigator 5 -- Brown Bag Lunch 6 -- Conseils à emporter 7 -- Crise / Opportunité 8 -- Le Cinquième Étage 9 -- Que faire ? 10 -- Soit... Soit... 11 -- Boîtes et Flêches 12 -- Le prochain Copil 13 -- La Faille 14 -- Poussière 15 -- L'hypothèse et la Règle 16 - Déplacements 17 -- Jouer et ranger 18 -- Arrangements 19 -- Mise au point 20 -- Expérimentation 21 -- Échantillons 22 -- Non-conclusions 23 -- Non-décisions 24 -- Épisode neigeux