Note : 4 ; Beaucoup de verbiage et peu d’illustration

Une nouvelle déconvenue, je dois bien l’avouer. Non pas que le style de l’auteur soit mauvais, il est plutôt tonique avec de bonnes qualités de « story telling ». Non pas qu’il n’ait rien à dire, bien au contraire : il transparait du texte une maîtrise, une compréhension et une solide vision de son sujet. Non, l’auteur échoue à développer convenablement son sujet, à l’appuyer sur de solides exemples. Au lieu de cela, il semble préférer discourir en se servant du texte comme une tribune. Pourtant le contenu est au coin de la rue, il ne demande qu’à se révéler : ce sont les 9 principes qui constituent l’essence de l’ouvrage.

L’ouvrage, justement n’est pas excessivement volumineux, avec ses 230 pages. Mais attention : il s’agit exclusivement de texte ! Il est découpé en 2 parties très inégales, la première servant d’introduction avec 3 chapitres sur 40 pages, la seconde développant les 9 pratiques sur le reste du livre.

La première partie s’ouvre sur le triste constant du code legacy et de ses causes : une industrie d’amateurs comme le dit l’auteur. Rien de vraiment neuf, mais c’est bien écrit et guère ennuyeux. Le second s’attaque sur une douzaine de pages au fameux CHAOS report, mais de façon critique, ce qui est assez original, et pertinent en l’occurrence. Mais c’est aussi pour dire qu’il partage les conclusions, mais pas l’analyse. Enfin cette 1ère partie se referme sur un petit chapitre introductif à la seconde partie (les 9 pratiques) et comme quoi notre focus sur l’agile nous a fait perdre de vue la nécessité de solides pratiques de conception (ou d’ingénierie) qui en forment les fondations. Je suis bien d’accord.

La seconde partie s’ouvre sur un chapitre introductif sur les 9 pratiques. Il ne dit pas grand-chose. Passons donc au plat de résistance !

1. Dites quoi, pourquoi et pour qui, avant le comment. Ici il est question de user stories et de PO, et d’avoir des conversations sur la finalité plutôt que de se transformer en machines à faire.
2. Construire en petits lots. Tout d’abord parce que cela permet d’établir une cadence, ensuite parce que « plus petit c’est mieux » : plus facile à comprendre, plus facile à estimer, plus facile à implémenter, plus facile à tester. Et surtout cela raccourcis la boucle de feedback. Je ne saurais être plus d’accord !
3. Intégrer continuellement. Une intégration continue, c’est le vrai « battement de cœur » d’un projet agile. Le passage au vert d’une fonctionnalité dans l’intégration continue, c’est la véritable définition de terminé de celle-ci. On oublie aujourd’hui que la première grande victoire de l’agilité fut intégration continue, qui en son temps élimina les phases d’intégration des projets !
4. Collaborer. Ici c’est essentiellement de pair programming qu’il est question. Fort bien. Dommage que l’auteur oublie les autres axes de collaboration…
5. Écrire du code CLEAN. C’est un hommage à Robert Martin. Je ne saurais objecter, mais de fait ce chapitre n’est jamais qu’un petit résumé des écrits d’uncle Bob. Sans les remplacer.
6. Écrire le test en premier. Bien sûr, c’est une ode au TDD, mais pas seulement, car l’auteur y évoque aussi les ATs et les tests QA. Cette position entre les tests TDD et les autres tests est une originalité du texte. Il n’y en a pas tant que cela.
7. Spécifier les comportements avec des tests. Ce principe se confond presque au précédent. Il précise en quelque sorte comment mettre en œuvre le principe précédent. Et ô stupeur, nous avons des extraits de code pour illustrer cela. Sorti de cela, ce principe n’apporte pas grand-chose.
8. Implémenter la conception en dernier. C’est une manière intéressante de dire qu’il faut faire de la conception émergente ! Hélas cela est bien mal développé. J’ai l’impression de retrouver une bonne partie des éléments du principe n° 5…
9. Refactorer le code legacy. Il s’agit là aussi d’une ouverture vers les textes et techniques pour adresser le legacy : Mikado Method, Strangler application ainsi que le fameux « Working Effectively with Legacy Code ».

Le chapitre 14 conclut l’ouvrage : apprendre de notre legacy. C’est encore l’occasion d’en repasser une couche à propos du TDD.

Voilà un ouvrage bien frustrant et que je ne saurais recommander, car il contient beaucoup de déclarations d’intention, d’idées pertinentes, mais peu de matière concrète. C’est en cela qu’il est frustrant. Car entre les lignes, on perçoit l’expérience et les idées de l’auteur si seulement…

Référence complète : Beyond Legacy Code – David Scott Bernstein – The Pragmatic Bookshelf 2015 – ISBN: 978 1 68050 079 0