Note 8 ; De nouvelles perspectives sur l’analyse du code en utilisant une machine à remonter le temps !

J’avais entendu parler de ce livre, en bien… mais j’avais aussi entendu quelques réserves à son égard. C’est sans doute ce qui a retardé sa lecture, et c’est bien dommage ! A part son titre surprenant, le livre n’est remarquable de prime abord que par son impression en couleur. A titre personnel, j’ajoute aussi la préface par Michael Feathers.

Le volume compte moins de 190 pages, annexes comprises. Il n’en est pas moins découpé en 15 chapitres dont 14 sont rassemblés en 3 parties. Le chapitre d’introduction ne servant guère qu’à expliquer la démarche générale du livre.

La première partie « evolving software » regroupe 5 chapitres sur un peu plus de 50 pages. Le premier chapitre « code as crime scene » donne le ton dans tous les sens du terme. D’abord par le titre qui reprends celui du livre, mais aussi en ouvrant sur l’histoire de Jack l’éventreur et des informations extrapolées des lieux de ses méfaits. De la même manière l’auteur identifie les « hot spots » de logiciels par les endroits ayant subi le plus de changements, en exploitant la gestion de version. L’exploitation de la dimension temporelle sera un dénominateur commun de beaucoup des analyses qui nous seront proposées.

Les chapitres 5 nous propose une analyse plus empreinte de classicisme : l’identification des suspects par les noms, qu’ils soient trop vagues ou qu’ils incluent préfixes ou suffixes à surveiller. Le calcul de complexité est un classique de ce type d’analyse et c’est le thème du chapitre 6. Mais plutôt que d’entrer dans des heuristiques complexes, l’auteur opère par repérage de l’indentation, sans même se soucier du langage. Une idée qu’il ne sort pas de nulle part, car étayée par des travaux de recherche ! Là aussi un dénominateur commun à de nombreuses analyses proposées.

La seconde partie « dissect your architecture » comprends 4 chapitres sur 50 pages. Il s’ouvre sur le chapitre 7 qui nous fait découvrir le « couplage temporel », ou l’art de repérer des couples de classes bougeant ensemble au fil du temps ! Bien entendu la gestion de version est de nouveau mise à contribution. Le chapitre 8 est plus difficile à dire, car il analyse l’évolution au fil du temps des couplages temporels entre modules. Même dit comme cela c’est compliqué, mais pourtant très astucieux pour analyser la dégénérescence d’un système.

Construire un filet de sécurité, c’est éminemment utile pour remettre du legacy sous contrôle. Pour de légitimes raisons l’auteur estime que la simple métrique de couverture n’est pas pertinente, mais le propos manque de direction et même d’éléments tangibles, bien que l’ensemble soit riche d’enseignement. Enfin au chapitre 9, c’est de beauté dont il est question ! Épaulé par des études, l’auteur nous apprends que la beauté c’est « l’absence de mocheté » ou pour le code, l’absence de surprise. C’est en analysant les dépendances hors cadre architectural (toujours via le couplage temporel) que l’auteur identifie ces (mauvaises) surprises. Malin.

La troisième partie a trait aux éléments sociaux du code. C’est inattendu. Cette partie occupe 5 chapitres sur un peu plus de 60 pages. Le chapitre 11 qui débute cette partie évoque les biais sociaux et entre autres la « pluralistic ignorance » qui n’est autre que le syndrome du mouton de panurge. D’une part l’auteur nous suggère des comportements de questionnements, mais aussi d’analyser les commentaires des commits. Malgré leur nature erratique, ils sont à même de donner des indications.

On va plus loin au chapitre 12 avec les métriques organisationnelles : qui commite après qui dans la gestion de version ? C’est une version « par auteur » du couplage temporel. Lorsque l’on connait la « distance organisationnelle », on tient des clés pour ajuster celle-ci ! Brillant. Cela devient pointu au chapitre 1 » avec la construction de carte des connaissances. L’idée est ici d’avoir une information pertinente du ownership des classes par contributeur, non seulement par commit, mais surtout par contribution. Ni trop (avec un owner unique), ni trop peu, avec un ownership complètement dilué ! Cette information peut ensuite être mappée sur l’organisation et sur les « hot spots » !

Au chapitre 14, l’auteur nous fait découvrir le « code churn », ou comment notre gestion de version nous montre si la dynamique d’équipe exhibe une convergence, une « death march » ou un effet rush de fin d’itération : la fréquence et l’ampleur des changements peut nous montrer cela. L’ouvrage se referme sur un récapitulatif : comment mettre en œuvre progressivement les idées développées ici ?

Non seulement les idées développées ici sont originales, elles nous emmènent vers des manières inusitées de regarder notre code, mais l’ensemble est bien écrit et clairement expliqué. L’auteur fait d’intéressants parallèles avec des histoires, principalement de criminologies pour tracer le parallèle sur la manière de réfléchir. Enfin il nous illustre graphiquement ces analyses de manière tout à fait attrayante (d’où l’impression en couleur). Bref, un ouvrage à ne pas rater.

Référence complète : Your Code as a Crime Scene – Adam Tornhill – Pragmatic Bookshelf 2015 – ISBN: 978 1 68050 038 7