Note de lecture : The Mikado Method, par Ola Ellnestam & Daniel Brolund

Note : 2 ; Que de remplissage !

Les auteurs ont découvert un bon truc pour refactorer du code legacy. Une technique à la fois simple et pratique, donc réellement bonne. Et ils ont voulu en faire un livre. Seulement voilà, parce qu’elle est simple, cette technique tient en 20 pages, guère plus !

2 parties totalisant 7 chapitres sur 140 pages constituent le corps de l’ouvrage. La première partie « The basics of the Mikado Method » se satisfait de 4 chapitres avec 65 pages environ. On ouvre le bal avec « meet the Mikado method ». En fait, tout est dit, ou presque, dans ce premier chapitre d’une quinzaine de pages. La démarche en fait très simple (c’est sa qualité première) est décortiquée pas à pas. La seule chose qui manque est un exemple. C’est ce que l’on escompte avec le chapitre 2 « hello, Mikado Method ». L’exemple est hélas un peu simpliste, mais la vingtaine de pages illustre un peu tout, y compris le « revert » à l’aide d’un petit exemple en Java. L’utilisation du gestionnaire de version, partie intégrante de l’approche, fait partie du lot. Il y a déjà pas mal de répétitions avec le chapitre précédant, mais cela reste intéressant.

Le chapitre 3, « goals, graphs and guidelines » est là pour nous donner un peu de recul sur ce qu’est un bon objectif de Mikado. C’est très abstrait et ne nous emmène pas très loin. Au chapitre 4, les auteurs explorent des variations de l’approche Mikado avec « Organizing your work ». En l’occurrence ils déclinent l’approche Mikado en isolation, en pair et en équipe. L’aspect « équipe » rappelle un peu le « Mob Programming », mais il ne m’apparait pas évident que la mise en œuvre ait été sérieusement expérimentée… Cela conclut la première partie du livre.

Lire la suite

Publicités

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