Note : 3 ; Une expérience vécue solide pour l’auteur, mais un peu léger voir naïf pour un livre !

Dans l’ensemble, l’auteur s’est contenté d’évoquer ses quelques expériences (surtout une en fait) de travail sur du code Legacy. Certes, l’expérience est assez solide, mais présente aussi d’importantes lacunes dont je parlerai, je pense surtout aux tests.

L’ouvrage en lui-même n’est pas un jour sans fin : il compte 200 pages, réparties en 3 parties qui totalisent 10 chapitres. La première partie « getting started » comprend 2 chapitres qui comptent pour 45 pages. Au premier d’entre-eux, « understanding the challenges of legacy projects », on fait le point sur une douzaines de pages sur les problèmes rencontrés sur du legacy. Des problèmes que l’on connaît fort bien, ce ne sont donc pas des découvertes, le sujet est même traité un peu façon « tarte à la crème » !

Avec une trentaine de pages, le second chapitre « finding your starting point » est plus conséquent. La stratégie apparaît quand même étonnante et même peu pertinente : on y évoque de l’exploratory refactoring (donc du refactoring sans filet ) et l’usage des outils de métrique comme PMD. Mais point encore de tests qui justement me semble le bon point de départ !

Le livre ne commence pas bien de mon point de vue. La seconde partie « Refactoring to improve the codebase » est la plus volumineuse du livre, avec 4 chapitres et une centaine de pages ! Elle débute par le chapitre 3 « preparing to refactor » qui en compte une vingtaine. Hélas ici aussi peu de matière utile : tout d’abord les « profils de programmeurs » assez naïf et pu utile au propos et la stratégie refactor versus rewrite dont on ne peut pas dire qu’elle révèle un grand scoop. Passons notre chemin.

Le chapitre 4 « refactoring » nous offre un peu plus de matière utile au fil de ses 35 pages. Je note par exemple l’expiry date dans le commentaire qui a au moins le mérite d’être original. Le propos sur les tests est plutôt un peu confus voir mal informé, mais il a au moins le mérite d’être là. Mais franchement, il y a matière à progrès !

Le chapitre 5 « re-architecting » propose la 2nd option de traitement du legacy (après le refactoring du chapitre 4). Il lui est consacré 25 pages. Ca part un peu dans tous les sens. L’auteur y évoque que pour séparer une application en modules il faut isoler des interfaces (sans blague ?). Puis on vire vers l’outillage de build et de gestion des dépendances pour finir sur le SOA et vaguement sur le microservice. Tout cela ne méritera pas un Pulitzer.

Enfin le chapitre 6 conclut cette seconde partie avec le « big rewrite » et un focus particulier sur la base de données. Un peu moins de 20 pages forment ce chapitre. Curieusement, je l’ai trouvé assez bien éclairé avec des considérations assez justes et un exposé pas mauvais du tout des stratégies de transition possibles.

La dernière partie du livre occupe 60 pages avec 4 chapitre également. Elle s’ouvre avec le chapitre 7 « automating the developpement environnement », où l’auteur nous expose purement et simplement ce qu’il a fait sur son projet UAD. En l’occurrence il s’agit de l’utilisation de Vagrant pour automatiser l’usage de machines virtuelles. Un point de vue bien fermé à l’heure de l’émergence de Docker. Il aurait mieux valu s’intéresser aux stratégies possible plutôt que de s’enfermer dans une solution et de nous asséner les lignes de code de configuration de Vagrant…

Le chapitre 8 « extending automation » poursuit sur une quinzaine de pages le propos sur les environnements de staging, test et production. C’est l’occasion d’une petite introduction à Ansible, pas trop mal faite je dois dire. Mais l’auteur rate d’exposer le concept du « deployment pipeline », même s’il évoque Jenkins…
Le chapitre « modernizing the development » donne à l’auteur une nouvelle occasion de s’adonner à sa marotte : les outils de build. Il nous parle ici de Fabric, un outil Python dont je ne comprends pas trop comment il s’insère dans l’écosystème déjà riche qui nous est présenté. Mais c’est un nouvel outil que je ne connaissais pas. Donc, c’est toujours intéressant.

Le livre se referme sur le chapitre 10 « stop writing legacy code ». Il se veut la conclusion du livre en évoquant comment ne pas tomber dans le legacy, grâce à la documentation ( !) et à la communication. Bref, encore un propos pas vraiment révolutionnaire.

Si le sujet du Legacy est important et finalement assez riche, cet ouvrage ne met pas la barre très haut ! Il y a quelques petites choses à picorer à droite et à gauche, mais baser tout un texte sur la base d’une paire d’expérience au Guardian est franchement léger ! Un livre à éviter.

Référence complète : Re-Engineering Legacy Software – Chris Birchall – Manning 2016 – ISBN : 978 1 61729 250 7