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.
Continuer à lire « Note de lecture : Software Design X-Rays, par Adam Tornhill »



