Note : 8 ; Le changement dans la continuité

La lecture de la première édition fut une réelle révélation pour moi. C’était à l’époque, la prémices de ma découverte de l’agilité. Aujourd’hui ce texte symbolise plutôt le craftsmanship, mais la différence entre les deux a-t-elle tant de sens ? Guère pour moi, en tout cas.

Beaucoup de choses ont changé dans le détail du contenu, d’une part parce que certaines idées des auteurs ont évolué (ce qu’ils soulignent régulièrement dans le texte même) et d’autre part car à la fois le contexte technologique et les pratiques ont progressé. Je pense, sur ce dernier point, aux pratiques de test.

Cette édition 20ème anniversaire a pris un léger embonpoint : 283 pages contre 259 pour l’édition précédente, passant de 8 à 9 chapitres. Dans votre bibliothèque, la couverture dure de ce nouvel opus va le faire passer dans la catégorie de standing supérieur. Les fameux « tips » qui parsèment le livre passent quant à eux de 77 à 97 ! Le premier chapitre s’intitule toujours « a pragmatic philosophy » et compte 25 pages couvrant 7 sujets. Il couvre en peu de pages un ensemble de comportements : prendre ses responsabilités, ne pas laisser les choses se dégrader et entretenir son portefeuille de connaissances. Une belle introduction.

Lire la suite →

Note : 8 ; Petit dépoussiérage d’un sujet toujours aussi important !

Pas moins de 20 ans ont séparé les deux éditions de cet ouvrage ! Le refactoring, c’est un peu la clé à molette de l’architecture émergente. Et ce livre en est le manuel officiel. Autant dire que c’est un ouvrage majeur du monde agile en général et du craftsmanship en particulier.

Cette seconde édition semble moins imposante que la première. En fait, elle compte approximativement le même nombre de pages, à savoir un peu plus de 400 hors annexes. Question de papier… Petite nouveauté toutefois : il existe une version en ligne qui est la version de référence et qui inclut la totalité des refactorings. La version papier en est donc un sous-ensemble. Toutefois l’ouvrage contient le code d’activation de cette version en ligne qui n’est pas en libre accès ! Autre petite différence, l’impression en 4 couleurs, privilège accordé à un grand classique, j’imagine…

Le livre totalise 12 chapitres, dont les 6 derniers constituent le catalogue à proprement parler. Autant prévenir tout de suite, les exemples sont en JavaScript, ce qui est franchement une mauvaise nouvelle pour moi. L’auteur nous a promis des exemples sans idiomes spécifiques, ce qui est vrai à quelques exceptions près.
Le premier chapitre est un teasing du livre, un exemple. Il met en œuvre des refactorings successifs en identifiant à chaque étape les « smells » résiduels. Il le fait avec la pédagogie à laquelle il nous a habitué. Et il est vrai que le JavaScript ne gêne guère. Un plaisir. On rentre dans le dur au chapitre 2, avec 35 pages consacrés aux principes du refactoring. On y explique quoi, quand et surtout pourquoi refactorer. La pratique y est inscrite au sein des pratiques d’XP et surtout comme partie intégrante du design émergent. J’y retrouve tout ce qui m’avait emballé il y a un peu plus de 20 ans. Cela avait été une révélation pour moi, avant même que je découvre l’agilité. Ne ratez pas ce chapitre.

Lire la suite →

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.

Lire la suite →

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.

Lire la suite →