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

Publicités

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

Agile Playground #16

L’Agile Playground ne se repose jamais … ou si peu ! Après une rencontre organisée mi-Juillet, on reprend nos bonnes habitudes dès mi-Septembre. Pierrick fait office de grand orchestrateur aujourd’hui. Et il nous propose un mode d’organisation inspiré de l’open-space, avec 2 catégories de propositions :

  • Les jeux que l’on souhaite proposer.
  • Les jeux auxquels on souhaiterait participer.

Le formule marche bien, nous recueillons quelques propositions, largement assez pour animer la soirée, pas trop pour ne pas être obligé de rentrer dans une gestion compliquée ! Voilà dejà une formule que l’on pourra rééditer !

image

Pour cette reprise nous étions un peu plus d’une trentaine de personnes, à vue d’oeil. Comme on dit lors des open-space : les personnes qui sont là sont les bonnes personnes !

image

Le « software ball » que propose Pierrick m’intrigue, ne serait-ce que par son nom : allons-y !

Le Software Ball

Le principe de ce jeu est simple et curieux et finalement pas si facile à saisir ! Les participants sont invités à se lancer une balle selon un schéma défini par le maître de jeu (nous ferons 5 itérations en complexifiant ce schéma). Pour exécuter cela, il faut « programmer » chaque participant avec des instructions en français à suivre très précisément. Elles sont inscrites sur des post-it que l’on colle sur soi.

A chaque itération, nous gagnons 10 points, moins le nombre d’instructions nécessaire pour programmer tout le dispositif (les instructions sont les verbes des phrases). C’est là que ça se gâte, n’est-ce pas ? Ce n’est pas fini ! On a droit au copier-coller et c’est gratuit ! Si 2 participants (ou plus) ont les mêmes instructions, on ne décompte que les instructions d’un seul participant. De même, si l’on garde des instructions entre 2 itérations, c’est aussi gratuit !

image

Bref, c’est quand même compliqué, vous pouvez toujours faire un tour sur le site du Software Ball. Pas mal de perte de temps au début : nous essayons un peu vainement de « bien » conceptualiser la chose avant de commencer. En fait, il est plus simple de se lancer et d’expérimenter sur le tas : nous nous lançons donc à deux pour commencer. Rapidement, après une paire d’itération, nous nous rendons compte que notre implémentation initiale génère des coûts exponentiels, car toute la complexité est sur le rôle du « lanceur-dispatcheur » qu’il faut réimplémenter à chaque fois ! Peitit moment de reflexion.

image

Nous galérons un peu pour passer du mode « push » au mode « pull » où les recepteurs appellent la balle et où il n’y a plus d’intelligence sur le dispatcheur. En effet, les règles stipulent de l’on ne peut pas faire de réutilisation partielle d’implémentation. Nous finissons par trouver le contournement !

Ce jeu a pour but de mettre le doigt sur des pratiques de Craftsmanship. En cela il est tout à fait original ! Il nous permet de reflechir à la réutilisation, au moment adéquat pour changer de stratégie et c’est franchement pas mal. Par contre il est frustrant sur le peu de libertés qu’il nous laisse pour faire des choix de cinématiques de circulation de balle. Je pense aussi qu’il devrait permettre la réutilisation partielle. En synthèse, voici le résultat du débrief.

image

Bref, j’ai bien envie de l’essayer, mais en hackant légèrement les règles !

La balle supersonique

Petite originalité de cette édition : un jeu frugal durant le buffet de fin ! Nous avons pu expérimenter une balle supersonique. Enfin, l’ayant déjà joué à Agile Game France, j’ai passé mon tour !

image

Mention spéciale à Julien qui l’a animé en n’ayant expérimenté la chose qu’une seule fois à Agile France. Il a d’ailleurs un peu hacké les règles en permettant de tenir la balle pendant qu’elle circule ! Je pense ne pas le suivre dans cette voie. Mais il bon d’essayer des choses. Voici de que cela donne

See you later

Toutes les bonnes choses ont une fin. Je coupe court à l’un de mes moments préférés : le buffet et la discussion qui terminent la soirée. Rendez-vous le mois prochain !

image