Comme chaque semaine, nous vous proposons un résumé d’un chapitre de l’excellent livre de Sandro Mancuso Software Craftsmanship – Professionalism Pragmatism Pride. Cette semaine nous vous proposons le résumé du chapitre 7 traitant des bonnes pratiques permettant de contrôler la qualité technique de votre projet.
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é :
- Software Development
- Agile
- Software Craftsmanship
- The Software Craftsmanship Attitude
- Heroes, Goodwill and Professionalism
- Working Software
Technical Practices
L’agilité, quelle que soit son implémentation, permet de maintenir un suivi régulier des fonctionnalités métiers de l’application et plus largement de la bonne marche du projet. Cependant, quelles méthodes avons-nous pour nous assurer que l’application est développée de la bonne manière ? La réponse réside dans les pratiques techniques du software craftsmanship qui complètent les méthodes agiles.
Malgré les différents contextes que nous pouvons rencontrer d’une structure à l’autre, toutes les entreprises ont en commun le souci de la rentabilité, du respect des délais et de la satisfaction du client.
Pour rappel, les premières pratiques à l’origine de l’extreme programming (XP) ont été introduites en 1996 dans le cadre de projets critiques qui se sont avérés être des succès. Depuis le sommet Agile de 2001, l’XP est considérée comme partie intégrante de l’agilité. Cependant, elle a été oubliée au cours de l’ère de la transformation agile. Le software crafsmanship nous permet aujourd’hui de remettre ces pratiques au goût du jour.
Il ne suffit pas d’adopter ces pratiques pour garantir le succès d’un projet. Il faut les appliquer régulièrement pour pouvoir en mesurer les effets à long terme et déterminer ce qu’il faut ajuster. Pour cela, ces pratiques doivent être fondées sur des valeurs partagées par tous les membres de l’équipe. Ainsi, lorsque l’on essaie d’introduire ces pratiques dans un projet, il vaut mieux se concentrer sur leurs bienfaits plutôt que sur les pratiques elles-mêmes.
Parmi ces pratiques, en voici quelques-unes qui permettent de contrôler fréquemment la qualité technique du projet sans avoir nécessairement besoin de l’aval d’un manager pour les adopter:
Le test automatisé
Cette pratique permet de s’assurer en quelques minutes qu’une modification du code source n’entraine pas de régressions. Ceci permet d’économiser des jours, sinon des semaines, de QA et de ne pas accumuler de code sur des bases malsaines pendant cette durée. De plus, ces gains deviennent plus importants à mesure que le projet grossit.
Test First et Test-Driven Development (TDD)
Ecrire les tests avant l’implémentation permet de se concentrer sur les fonctionnalités et les responsabilités des classes, fonctions et modules qui les implémentent tout en écrivant les tests automatisés.
Bien que le TDD dérive de la pratique Test First, il ne s’agit pas d’une pratique visant à assurer la couverture de test du projet mais plutôt d’une pratique de conception. En effet, il est difficile d’écrire du code complexe lorsqu’on pratique le TDD parce qu’on écrit juste assez de code pour passer les tests et aussi parce qu’un code complexe ou mal conçu est immédiatement mis en évidence lorsqu’il devient difficilement testable. Ainsi, la maintenabilité du projet est contrôlée bien plus rapidement et fréquemment qu’avec une revue de conception. Cette dernière demeure une bonne pratique dont on ne doit pas se dispenser lorsque son sujet est clairement défini (performance, interfaces avec d’autres systèmes, etc…).
L’intégration continue
Combinée avec le TDD, cette pratique permet de vérifier rapidement et à moindre coût que les changements apportés par les membres d’une équipe, quelle que soit sa taille, restent cohérents et n’entrent pas en collision. À chaque fois qu’un développeur pousse un changement sur le dépôt de code, tous les tests issus du TDD sont exécutés pour vérifier qu’aucune régression n’a été introduite. Pour être efficace, cette pratique doit être combinée avec celle du "Stop & Fix". C’est à dire que tous les membres de l’équipe doivent corriger en priorité les erreurs remontées par l’intégration continue avant de reprendre leurs tâches en cours.
La combinaison de toutes les pratiques pré-citées rend redondante une équipe de QA. Ce qui nous permet d’affecter les meilleurs testeurs à l’écriture de tests automatisés ou de tests d’acceptances auprès du product-owner.
Le Pair-Programming
Bien que la revue de code garantisse la qualité du code et la transmission de bonnes pratiques au sein d’une équipe, son application peut se révéler chronophage et coûteuse (surtout si la revue met tardivement en évidence le besoin d’un refactoring).
Le Pair-Programming permet de garder sous contrôle la qualité d’un code lu à quatre yeux. Là encore, le retour sur cette qualité est immédiat. Pour être encore plus efficace, il est important de permuter régulièrement les équipes et ainsi, maintenir une compréhension collective du système et améliorer les compétences des développeurs.
Le Refactoring
D’une façon générale, un développeur n’aime pas travailler sur une base de code peu compréhensible. De peur d’introduire des régressions, celui-ci va dupliquer du code ou ajouter des hacks, rendant la situation encore pire.
Le refactoring nous permet de réduire ces risques à coût maitrisé si il est pratiqué régulièrement.
Bien qu’il peut être tentant de refactorer entièrement une vieille application legacy, il est moins coûteux et plus pragmatique de ne refactorer que le code fraîchement ajouté. En effet, dans la mesure où la partie legacy du code fonctionne et ne nécessite donc pas d’être modifiée, il est inutile de perdre du temps à essayer de l’améliorer.
Bien que nous ayons décrit les bienfaits de toutes ces pratiques, il est toujours possible de voir des développeurs ou des décideurs ne pas les adopter. Il peut s’agir alors de décisions responsables tant qu’elles restent justifiables.
Par ailleurs, une des plus grandes qualités que peut avoir un craftsman est le pragmatisme. En effet, les pratiques et les méthodologies apparaissent et évoluent constamment. Celles que nous venons de décrire et que nous appliquons aujourd’hui pourraient se révéler obsolète demain. Il ne faut les appliquer systématiquement si elles ne sont pas nécessaires ou si nous avons de meilleurs alternatives. En fait, il faut constamment se demander s’il n’existe pas des pratiques plus efficaces ou plus adaptées et la meilleure façon de comparer ces pratiques est de comparer leurs valeurs ajoutées sur le projet.