Note de lecture : The Pragmatic Programmer 20th anniversary edt., par David Thomas & Andrew Hunt

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 de lecture : The Unicorn Project, par Gene Kim

Note : 7 ; Une intrigue passionnante pour illustrer les « 5 idéaux » de l’auteur.

Gene Kim est co-auteur de plusieurs ouvrages gravitant autour du devops, dont « The Phoenix Project », un texte romancé s’inscrivant dans la continuité de « The Goal » D’Eli Goldratt. Cette fois, il vole en solo de nouveau sur un texte romancé dont l’intrigue s’entrelace avec celle de The Phoenix Project.

La prose occupe un peu plus de 330 pages d’un texte rythmé sur 19 chapitres, mais ceux-ci servent surtout à rythmer l’histoire. Ce sont plutôt les 3 parties qui sont le découpage important. Nous avons droit à une vingtaine de protagonistes dans cette histoire, mais tous n’ont pas la même importance. Nous suivrons surtout Maxine Chambers, « placardisée » au projet Phoenix en servant de bouc émissaire pour un grave problème survenu alors qu’elle était en vacances. Kurt Reznick à la tête de la « Rebellion team » est aussi un personnage majeur, tandis que Sarah Moulton joue le rôle de la méchante. Nous retrouvons aussi épisodiquement Erik Reid du livre précédent, dans un rôle assez curieux. A titre personnel, j’ai bien aimé la présentation « Star Trek » des protagonistes.

Le début est assez lent. Nous assistons surtout durant les 4 premiers chapitres aux affres de Maxine arrivant au sein du Phoenix Project, paralysée par une organisation silotée et procédurière. Ce n’est qu’au chapitre 5 que nous découvrons la Rebellion Team. De manière générale, cette première partie développe largement les dysfonctionnements qui peuvent être observées dans ce type d’organisation. Le paysage dressé, ou la vision d’horreur devrais-je dire, l’est avec beaucoup de détails et de réalisme, mais on n’y apprend rien. Cette première partie introduit toutefois dans ses dernières pages, les « 5 idéaux » qui forment la colonne vertébrale du texte.

Lire la suite

Note de lecture : Rupture Douce saison 03, par Laurent Sarrazin edt.

Note : 4 ; Une consistance du contenu en progrès.

Mes attentes pour ce nouvel opus ne se situaient pas très haut, je dois dire. Et oui, de nouveau je dois constater une certaine disparité entre les textes. Tous ne sont pas bien écrits, et tous ne traitent pas de sujets qui résonnent en moi. On y croise aussi plus de fautes d’orthographes que l’on ne s’y attendrait. Malgré tout cela, dans ce volume de près de 400 pages, il se trouve bien plus de textes sur lesquels je me suis arrêté (et où j’ai appris quelque chose) que je m’y serais attendu. Plutôt que de passer en revue l’ensemble, je vais évoquer ceux-ci.

Le chacal et la girafe d’Éric Bezancon est une simple et bonne introduction de Marshall Rosenberg. Ce n’est probablement pas une prose d’anthologie, mais il explique simplement en quelques pages les étapes OSBD. De quoi se sentir mieux armer au bout de quelques pages, puis de souhaiter s’attaquer à l’excellent « les mots sont des fenêtres » écrit par le maître. Mon ami Vincent Daviet a commis un très bon mariage entre théâtre d’improvisation et agilité. Outre qu’il introduit brillamment les préceptes de cette pratique il nous aide à appréhender les fils qui la relie à l’agilité. Bien joué. Là aussi on pourra poursuivre le plaisir par la lecture de « improving agile team » non cité ici car c’est une référence que j’avais partagée avec Vincent postérieurement à l’écriture de son texte.

J’ai adoré le récit de Nicolas Deverge sur sa mise en œuvre du Lean Startup : le vécu, cela sonne toujours mieux et l’histoire est racontée avec talent. Succès et ratages (dont il ne se cache pas) nous apprenent tous deux des choses. Un texte qui change de ceux qui vantent combien l’auteur est grand et fort… La regrettée Bernadette Lecerf-Thomas nous livre une introduction aux neuro-sciences. Je ne suis pas sûr que ce soit le meilleurs texte que l’on puisse trouver, mais je le considère un peu comme un bonus. Et la aussi, le rapport volume / information est des plus favorables.

Lire la suite

Note de lecture : Refactoring, Improving the design of existing code 2nd edt., par Martin Fowler with Kent Beck

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 de lecture : Secure by Design, par Dan Bergh Johnsson, Daniel Deogun & Daniel Sawano

Note : 6 ; Où il apparait que l’on parle plus de DDD que de sécurité, mais que les deux parviennent à être indissociables…

J’avais initialement classé cet ouvrage dans ma (très pauvre) section « sécurité ». Il m’est très vite apparu que ce n’était pas sa place. C’est bien de conception dont va nous parler cet ouvrage, et même de DDD en grande partie. C’est donc un cocktail assez inhabituel et intéressant, au sens positif.

L’objet n’est pas léger, avec ses 360 pages. Nous verrons que ce n’est pas son meilleur aspect, hélas. Le tout compte 14 chapitres divisés en 3 parties. La première s’intitule sobrement introduction et contient les deux premiers chapitres, soit 45 pages. « Why design matters for security ? » est le chapitre qui ouvre le bal. L’approche évoquée par ce livre est la sécurité de l’intérieur, au niveau du code lui-même, un propos que les auteurs illustrent fort bien avec quelques histoires, que ce soit avec une histoire de braquage de banque avec le « billion Lauga » torché en 2 coups de cuiller à XML. Un chapitre très plaisant. Le second chapitre est un interlude pour nous illustrer les conséquences d’une modélisation un peu légère, ou comment obtenir un livre gratuit en commandant dans le même panier un « Hamlet » et… un « anti-Hamlet ». Une histoire hélas inspirée d’un fait réel.

La seconde partie « fondamentaux » couvre la majeure partie de l’ouvrage, avec 9 chapitres sur près de 250 pages. J’ai dit que le DDD était une pierre angulaire de l’approche, le chapitre 3 qui ouvre cette partie est une introduction au sujet. C’est bien écrit, mais un peu verbeux, car il faut compter 37 pages. Ne ratez pas l’explication du « tomber pour tourner » sur les virages pris à vélo ! Au sein du DDD, ce sont surtout les value objects qui retienne l’attention des auteurs. En l’occurrence deux aspects qui leur sont rattachés : construire des value objects immutables (bonjour Scala) et le « fail fast », c’est-à-dire des objets rejetés à la construction s’ils ne satisfont pas les conditions d’entrée (bonjour Bertrand Meyer). Ce chapitre est l’un des points forts du livre. Le chapitre 5 va un cran plus loin, avec les « domain primitives » qui sont un sur-ensemble des value objects. On voit ici comment construire ces primitives de manière sécure, en s’appuyant entre autres sur les invariants. Moins fort que le chapitre précédent, le texte reste quand même intéressant.

Lire la suite

Note de lecture : Java by Comparison, par Simon Harrer, Jörg Lenhard & Linus Dietz

Note : 6 ; Craftsmanship, niveau junior

Le code de qualité, il faut bien commencer à l’écrire un jour. Et ce jour, ce peut être sur les bancs de l’université. C’est ce qui a motivé en premier lieu l’écriture de ce texte. Contrairement aux classiques du Craftsmanship qui s’adressent au développeur aguerri, celui-ci s’adresse au débutant et la progression des chapitres reflète cela.

C’est un texte assez court, qui n’excède pas 165 pages et compte 9 chapitres au long desquels sont distillés 70 exemples, toujours présentés de la même façon : une page avec le code « avant » auquel fait face le code « après » sur la page en vis-à-vis, agrémenté de quelques explications, mais le tout contenu dans ces deux pages. Le premier chapitre adresse des basiques de clarté du code, sur une vingtaine de pages, soit 8 exemples, qui vont des formulations booléennes à la notion de symétrie du code. Tout cela reste très simple, mais nécessaire à couvrir pour le débutant. On remarquera toutefois une approche « opiniated » qui persistera tout au long du livre, mais cela me semble normal.

On passe la seconde avec le second chapitre. Cela continue sur des questions de clarté, par exemple avec les énumérations, mais aussi de code sain, notamment à propos des itérations. Tout ceci est couvert en 8 exemples également. Alerte maximum pour le chapitre 3 dédié aux commentaires ! Ce sont même 10 exemples qui figurent ici. Mais, oh soulagement, les 4 premiers nous suggèrent d’éliminer les commentaires redondants. Finalement on fait dans le bon sens.

Lire la suite

Note de lecture : Software Design X-Rays, par Adam Tornhill

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