Note de lecture : Working Effectively with Legacy Code, par Michael C. Feathers

Note : 9 ; Le refactoring repensé pour le legacy. Book of the year 2018 !

Appréhender la remise sous contrôle du code legacy est à mon avis une discipline à part entière. C’est en partie de l’architecture, tout en empruntant au refactoring avec une démarche de tests bien à elle. Entre autres choses. Mais peu d’ouvrages sont dédiés à la question, il faut dire que celle-ci n’est pas la plus sexy qui soit. Le livre de Michael Feathers se tient au sommet de cet édifice depuis plus d’une douzaine d’années et pour de bonnes raisons.

Michael Feathers nous propose une approche dans la ligne de l’approche extrême programming, en s’appuyant sur une vision code adossé à des tests unitaires. D’ailleurs sa définition du code legacy s’en inspire directement : du code legacy, c’est du code sans tests !

Avec 420 pages, ce n’est pas un petit volume que nous avons entre les mains. Il se découpe en 3 parties. La première d’entre-elle « the mechanics of change » est aussi la plus courte avec une cinquantaine de pages en 5 chapitres. Il s’agit bien d’une introduction assez exhaustive à l’approche que propose l’auteur et que j’appelle le « inside out ». Elle répond aux questions suivantes :

Lire la suite

Note de lecture : Re-Engineering Legacy Software, par Chris Birchall

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 !

Lire la suite

Note de lecture : Growing Object-Oriented Software Guided by Tests, par Steve Freeman & Nat Pryce

Note : 8 ; Craftmanship en grandeur réelle

Quand on évoque le craftmanship, on montre des exemples de code, sinon cela n’a pas de sens ! Généralement, il s’agit de 2 ou 3 classes qui se battent en duel que l’on refactore afin d’améliorer les abstractions, éviter les duplications de code et tout et tout… Ce livre-là est différent, car il va faire du design émergent en TDD une réalité en l’appliquant sur la construction d’un logiciel complet, le tout suivi pas à pas ! Pour mener à bien sa mission, le texte compte un peu moins de 330 pages hors annexes, le tout découper en 5 parties très inégales. Je ne vais pas vous compter par le menu les 27 chapitres de l’ouvrage, mais plutôt les 5 parties.

La première partie est introductive (comme on peut s’en douter). Elle ne compte que 3 chapitres sur 25 pages. Il s’agit avant tout de considérations générales, mais non dénuées d’intérêt. On y évoque des principes nouveaux ou anciens comme le cycle ATDD imbriqué dans le cycle TDD, les cartes CRC ou le « tell, don’t ask ».

Lire la suite

Meetup Craftsmanship de Février

Déjà mon deuxième meetup Craftsmanship ! La formule reste inchangée mais le contenu se renouvelle : 3 lightning talk et une partie atelier ! C’est Cyrille qui ouvre le bal.

La progressivité dans le code, par Cyrille Martraire

Cyrille nous invite à prendre conscience de la notion de « progressivité » lors de nos refactorings. Certains remaniements se font en douceur… jusqu’à se heurter à des remaniements qui s’avèrent plus brutaux !

image

Lire la suite