Note : 5 ; De la difficulté d’écrire une suite à un livre qui sort du lot !

C’est vrai, « Your code as a crime scene » m’avait laissé pantois : utiliser le gestionnaire de version comme une machine à remonter dans le temps (ce qu’il est, en fait) nous avait fait découvrir de nouvelles façons de regarder le code, d’en tirer des informations et des enseignements. Ce volume se veut le prolongement de cette nouvelle manière de penser. Malheureusement, comme nous allons le voir, il tombe un peu court pour cela.

Le succès du volume précédant a donné un petit extra à cet opus-ci : il est imprimé en couleur. De fait, ses 210 pages (hors annexes) contiennent moult illustrations. La structure du livre compte 10 chapitres également répartis sur deux parties. La première d’entre-elle s’intitule « prioritize and react to technical debt » et couvre environ 90 pages. Elle s’ouvre sur un premier chapitre d’une douzaine de pages pour nous expliquer pourquoi la dette technique n’est en fait pas technique ! Le propos de l’auteur est de nous amener à comprendre que la dette technique est en fait de la dette organisationnelle et qu’il est nécessaire de se focaliser sur les parties de code qui ont le plus fort « taux d’intérêt ». L’idée est intéressante, mais le propos est loin d’être direct et bien que j’adhère au propos, je suis loin ici de la révélation.

Justement, le second chapitre nous conduit vers la notion de code à fort taux d’intérêt. Il nous en coûtera une vingtaine de pages. Cette notion, l’auteur la calcule en combinant la fréquence de changement avec la complexité du code. Certes le chapitre développe un peu cela, mais je n’y trouve rien d’extraordinaire. Le chapitre 3 développe une notion déjà abordée dans le livre précédant : les « co-changing files », ou couplages temporels entre fichiers n’ayant pas de dépendances ! Si l’auteur s’étend plus sur les causes et remèdes, je n’y trouve pas non plus d’effet de découverte.

Au chapitre 4, on parle de rembourser la dette technique. J’y découvre le principe de proximité. Sans être transcendant, c’est une bonne chose à savoir et appliquer. L’auteur s’étend beaucoup sur le « splinter pattern », mais pour moi il s’agit beaucoup de faire du neuf avec du vieux. Plus intéressant, le chapitre 5 nous parle de l’age du code, c’est-à-dire de sa stabilité de changement récent, si je puis dire. Les package devant prendre en compte ce facteur d’âge, afin de laisser en paix les packages stables !

La seconde partie se focalise sur les grandes bases de codes et les organisations larges. Elle compte 5 chapitres et totalise près de 120 pages. Le chapitre 6 ouvre le bal avec le « system tipping point ». Dans les grandes lignes, il s’agit d’appliquer le calcul de hot spot aux sous-systèmes, ces derniers étant identifiés comme des répertoires séparés dans le gestionnaire de versions. Cette fois encore, j’ai un peu de mal à m’enthousiasmer…

La loi de Conway revient à la mode, probablement grâce à la vague microservices. Dans ce chapitre 7, l’auteur nous propose d’aller « au-delà » ! Il y aborde les notions telles que « code diffusion » et propriété du code. A l’intersection entre management et qualité de code, ce chapitre se cherche un peu mais nous soumet quelques réflexions pertinentes, telles que la dilution des responsabilités. Le chapitre 8 s’inscrit en continuité en parlant de « vue sociale du code ». En fait, il s’agit d’analyser les couplages organisationnels en regard du style architectural : découpage en couche, par features ou segmenté en « bounded contexts » à la DDD. Le « team knowledge map » sauve à peine le propos.

Le sujet du chapitre 9 est réellement d’actualité, car il aborde les microservices, et plus précisément leur organisation en repos multiples. Malheureusement, même si de toute évidence l’auteur le fait réellement, la manière dont les analyse inter-repositories sont faites ne sont ni claires ni détaillées. C’est fort dommage, car c’est un point crucial. A plus haut niveau, le chapitre aborde les dépendances entre microservices (une analyse de la qualité de leur découpage, donc) et la manière dont les dépendances se traduisent en dépendances entre personnes ou équipes. C’est du bon. Enfin le chapitre 10 aborde la déviation de qualité de code au fil du temps pour en tirer des conclusions essentiellement sociologiques. Tout d’abord, l’auteur nous assène que l’entropie du code trouve son origine dans le premier commit. Ensuite, cette analyse nous permet d’identifier l’impact du départ de certains membres d’équipes. Tout cela illustré dans les repos de gros peojets tels que Scala.

Ce texte vise un propos de plus haut niveau que celui de « your code as a crime scene ». Les analyses sociologiques s’y taillent une belle part. Les nombreuses références aux travaux universitaires restent aussi une marque de fabrique de l’auteur, ce qui est très rare dans ce genre d’ouvrage. Toutefois le texte n’a pas la force du texte suscité. En fait, j’ai souvent eu du mal à garder mon attention de manière continue. Certainement ne l’ai-je pas lu dans les bonnes conditions, mais le fil du propos n’a probablement pas la qualité requise. Je n’ai pas non plus retrouvé le « waouh effect » du volume précédant et je soupçonne l’auteur d’avoir gardé des choses par devers lui pour vendre ses outils !

En tout état de cause, si vous n’avez pas lu « your code as crime scene », commencez par celui-là. S’il vous a emballé (et seulement là) vous pourrez envisager celui-ci comme un complément.

Référence complète : Software Design X-Rays – Adam Tornhill – Pragmatic Bookshelf 2018 – ISBN: 978 1 68050 272 5