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 ».
La seconde partie, longue d’un peu plus de 40 pages sur 5 chapitre, adresse spécifiquement la façon de travailler en TDD sur un projet réel. Cette partie évoque la question du style des tests, comment ils doivent être conçu pour être lisibles et tester des comportements. Mon sujet préféré dans cette partie a trait à l’architecture agile : les auteurs y développent l’architecture hexagonale (Cockburn) ou en oignon (Martin). Cette partie s’étend jusqu’à l’évocation du test logiciel avec les parties tierces (en utilisant des mock), mais il reste léger là-dessus.
La troisième partie occupe la majeure partie du livre. Il compte en effet 150 pages découpées en 11 chapitres, au long desquelles nous allons construire un « auction sniper » ! On ne commence pas par le plus facile, d’ailleurs. Car s’il y a bien un choix discutable, c’est bien de s’être fixé sur une application Swing ! On passe donc les 3 premiers chapitres à faire passer notre premier test ! Par contre, malgré la « glue Swing », on a bel et bien un premier test au sein d’un design simplifié au maximum où la logique métier côtoie l’IHM et les aspects techniques de communication. Et on a aussi une « todo liste » qui nous guidera au long des chapitres suivants ! Les chapitres suivant font progressivement émerger le design, en utilisant les tests comme signal d’alerte de confusion et en s’appliquant à ce que ces refactorings n’aient pas d’effets de bord sur les autres tests. On y introduit aussi les fonctionnalité de JMock. Ou plutôt nous laisse-t-on deviner comment ça marche (les annexes comprennent un tutorial JMock). Les règles de design telles que la gestion du NULL, la gestion des types métier sont introduits progressivement en faisant émerger le design. Au fur et à mesure, le système s’étoffe aussi de nouvelles fonctionnalités. Régulièrement, en plus du code, les auteurs nous livrent des morceaux de modélisation « à main levée ». Toute cette saga ne se lit pas avec la même fluidité d’un bout à l’autre et globalement elle demande pas mal d’attention et de concentration. Mais c’est un sacré exercice riche d’enseignements.
La 4ème partie couvre une cinquantaine de pages sur 5 chapitres. On y aborde des sujets récurrents de tout développements logiciels et souvent éludés en terme de design. Pas de ça ici : les auteurs proposent des positions et des idées qui font honneur au mouvement craftmanship » ! Le sujets abordés sont le logging, les diagnostiques, la lisibilité des tests, la construction de cas de tests avec des structures de données complexes. Entre autre choses. Bref, une partie que j’ai particulièrement appréciée.
La dernière partie occupe 3 chapitres sur 50 pages environ et se focalise sur des sujets avancés en terme de tests unitaires : la persistance, le multithreading et l’asynchronisme. Je le voie plutôt comme du matériel complémentaire, pas réellement nécessaire au propos, mais évidemment intéressant.
Le craftmanship ne recèle pas de tant de titres de qualité. Celui-ci se démarque par son focus sur le design d’application et non sur une vue zoomée de code, comme c’est trop souvent le cas. Le livre est resté longtemps à prendre la poussière sur mes étagères, c’est bien dommage ! N’en faites pas autant.

Référence complète : Growing Object-Oriented Software, Guided by tests – Steve Freeman & Nat Pryce – Addison Wesley / Signature series 2010 – ISBN : 978 0 321 50362 6