Chapitre 15 du livre de Sandro Mancuso sur le Software Craftsmanship

Comme chaque semaine, nous vous proposons un résumé d’un chapitre de l’excellent livre de Sandro Mancuso Software Craftsmanship – Professionalism Pragmatism Pride. Nous vous proposons cette semaine le résumé du chapitre 15 décrivant le comportement d’un Software Craftsman.

Si vous êtes intéressés par la vision d’un craftsman sur son logiciel vous pouvez retrouver Sandro dans le catalogue de formation de Xebia Training.

Déjà publié :

Pragmatic Craftsmanship

N’importe quelle personne s’attend par défaut à ce qu’on lui fournisse un logiciel de qualité. Même si elle a fait le choix d’avoir ce logiciel rapidement ou à bas coût, même si les développeurs l’ont averti sur les compromis qu’il faudrait faire, la qualité reste implicite.

Si on prend en compte cet état de fait, alors on se doit, en tant que software craftsman, de livrer un logiciel de qualité rapidement et à bas coût.

Le mythe de la qualité chère et chronophage

Une équipe de software craftsmen crée de la valeur dès la première itération, met en production aussi souvent que souhaité et est guidée par les tests.
Si l’on critique souvent la lenteur du pair programming ou du TDD, c’est parce qu’ils sont mis en œuvre par des personnes qui ne le pratiquent pas depuis longtemps. Quant aux développeurs expérimentés qui n’utiliseraient pas les techniques d’extreme programming (XP), il se peut qu’ils soient aussi rapides que des software craftsmen sur de petits projets mais sur des projets plus longs et complexes, il n’y a juste aucune comparaison possible.
On peut donc se focaliser sur le problème suivant : comment réduire le temps d’apprentissage d’XP ?

A-t-on besoin de tout piloter par les tests ?

Il faut se méfier lorsqu’on emploie les termes « toujours » ou « jamais ». Souvent les gens qui disent « jamais » sont ceux qui ne se focalisent que sur la rapidité de livraison d’une fonctionnalité sans se soucier du manque de qualité et d’extensibilité du code qu’ils laissent derrière eux.
Le débat sur le TDD est stérile : quand on le pratique depuis longtemps, il ne vous ralentit pas.

Refactoring

Il est contre productif de refactorer sans but. Toutefois, il est parfois nécessaire de refactorer avant d’ajouter une nouvelle fonctionnalité et durant l’implémentation avec le cycle du TDD red-green-refactor. Quoi qu’il en soit, la règle du boy scout doit systématiquement s’appliquer.

La méthode « unique » pour développer un logiciel

Le software craftsman se doit de s’améliorer et de se remettre en question constamment. Au début de sa carrière, il n’aura pas d’autre choix que de suivre les conseils de ses pairs. Toutefois, il devra toujours exercer un œil critique sur ses pratiques et être ouvert à d’autres. Aujourd’hui, on considère que le TDD et toutes les pratiques XP sont les meilleures mais il y a toujours des moyens de mieux faire pour s’adapter à son contexte.

Aider le métier

Il arrive régulierement que le métier hésite entre plusieurs solutions, voir qu’il ne semblent ne pas savoir ce qu’il veut. Notre devoir est d’aider le métier à concrétiser ses idées, aussi imprécises soient-elles. Les petits incréments livrés sur le logiciel pourront bénéficier au plus tôt des retours des utilisateurs.
Expérience vécue : sur un projet complexe et dont le périmètre évoluait sans cesse, l’équipe décide d’implémenter les écrans en lecture seule avec des données montées en mémoire. La cinématique et les actions utilisateurs sont donc simplement et rapidement mises à dispositions – tout en pratiquant le TDD et le pair programming. Au fur et à mesure que les cas d’utilisation se stabilisent, la persistance et les composants non-fonctionnels sont craftés.

Les projets de développement ne doivent pas être centrés sur les développeurs

La responsabilité d’un software craftsman, c’est de faire en sorte que le projet puisse être maintenu sans lui du jour au lendemain. L’humilité et le partage de connaissances sont des valeurs centrales.

Bon vs Mauvais

La différence entre le bon et le mauvais développeur, c’est la manière dont il parvient à répondre au problème. N’importe quel développeur sait résoudre un problème métier mais le plus compliqué reste de le faire d’un manière simple, maintenable, testable et avec le moins de code possible.

Règles de la conception simple

Des 4 règles édictées par Kent Beck, on peut ne retenir que l’essentiel (si on fait du TDD, les deux autres sont implicitement respectées) :

minimiser la duplication
maximiser la lisibilité

Un code où les design patterns sont appliqués de manière systématique est simplement trop complexe pour la tâche qu’il doit réaliser. On ne cherche pas à écrire un code qui pourra être changé dans le futur si un jour on le souhaite : on cherche à écrire un code qui satisfasse notre besoin immédiat.

C’est le refactoring permanent du code qui permet de dégager les patterns au bon moment. Il est inefficace de penser à la liste des patterns que l’on va introduire dans le logiciel sans qu’on en ai vraiment ressenti le besoin.

Craftsmanship et pragmatisme

Le pragmatisme est l’une des valeurs fondamentales du craftsmanship. Quelque soit la nature du projet, il est important de fournir le code le plus simple et le plus évolutif possible.