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 !
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 ».
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 !
Un nouveau Meetup, encore un ! Celui-ci est organisé par Xavier Detant et cette première édition se déroulait dans les locaux de Zenika !
Un beau succès pour cette première édition, car elle a rassemblé environ 30 personnes, c’est bien plus que ce que j’aurais parié. Et le groupe Meetup compte déjà 150 inscrits !
C’est dans les locaux de Zenika que s’est déroulé ce nouveau meetup Craftsmanship, en fait le premier pour moi ! Cyrille Martraire sera le maître de cérémonie, il introduit le déroulement de la soirée, à savoir : 2 lightning talks, 1 talk moins light et enfin le coeur de cette soirée, l’open-space
Les agilistes ne sont guère friands de normes et autres standards. Généralement, nous nous contentons de les ignorer. Néanmoins ils sont souvent utiles.
Beau programme pour cette rentrée du FKUG ! En effet, cette soirée hébergée par Wemanity proposait pas moins de 4 sessions sur 2 tracks. Nous serons donc hélas frustrés de 2 sessions !
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 !
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 !
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 !
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.
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.
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 !
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 !
