Les trois questions à se poser avant de faire évoluer un logiciel, un kata avec “Gilded Roses”
Faire évoluer un logiciel n’est pas chose facile. Il faut gérer l’existant tout en ajoutant les nouvelles fonctionnalités souhaitées par les utilisateurs. La mission d’un développeur est alors non seulement d’assumer le travail antérieur, mais aussi d’apporter les évolutions attendues…. tout en maintenant une qualité de service entre le logiciel existant et le logiciel futur. Voici, à travers un petit kata du cas “Gilded Roses”, les trois questions à se poser avant de se lancer.
Les utilisateurs de logiciels sont des gens exigeants et ils ont bien raison. Ils veulent que les anciennes fonctionnalités de leur logiciel soient maintenues tout en leur en fournissant de nouvelles. C’est le sujet de ce kata avec le cas “Gilded Roses”. La méthode me paraît y être fondamentale. Elle passe, selon moi, par trois questions à se poser afin de déterminer si l’état actuel d’un code permet l’ajout d’une fonctionnalité sans risques de régression.
Existe-t-il des tests unitaires et sont-ils suffisamment “couvrant” ?
Dans le cas contraire, il est nécessaire de les ajouter. Ils vont permettre de garantir que les modifications apportées au code source ne changent pas le comportement des autres fonctionnalités.
Existe-t-il des tests d’intégrations de la chaîne globale faisant intervenir les fonctionnalités sur lesquelles nous travaillons ?
Bien qu’ils soient très utiles, s’ils n’existent pas, il peut être compliqué de les créer avec une couverture pertinente. Il faut alors s’interroger sur la pertinence d’une tâche dédiée en dehors du développement courant. Si des tests existent il faudra alors penser à les compléter après l'ajout d’une nouvelle fonctionnalité.
L’état du code source permet-il l’ajout d’une nouvelle fonctionnalité ?
C’est le coeur du problème dans le cas du “Gilded Rose” un rapide coup d’oeil au code source fourni pour ce kata (pour les sources voir les liens en référence) nous indique qu’il va falloir le retravailler complètement si l’on veut pouvoir ajouter une fonctionnalité. C’est précisément sur ce point que je trouve ce kata pertinent. En effet, le code que l’on trouve est constitué d’une seule méthode particulièrement redondante et riche en “if” imbriqués. De plus, la moindre modification du code source peut casser les précédentes fonctionnalités. Il faut donc pas mal de patience pour arriver à ses fins.
L’important dans cette étape est de faire de petites modifications (dit “baby step”) que l’on teste immédiatement pour vérifier le plus souvent possible que rien n’est cassé. Pour détecter les points à retravailler, on peut s’aider des codes smells, mais le bon sens devrait aussi vite nous guider vers une solution plus acceptable, plus maintenable.
Savoir quand arrêter le “refactoring” est point délicat, car il dépend du temps qui a été alloué au développement et de la personne qui modifie le code source. Un intérêt des katas est de pouvoir faire des expériences. Ce que je recommande c’est de commencer par faire le kata en arrêtant le “refactoring” dès que l’on pense pouvoir ajouter une nouvelle fonctionnalité. On pourra toujours par la suite le refaire en poussant le “refactoring” à des niveaux considérés comme extrêmes. C’est une fois terminé que l’on se demandera si le jeu en valait il la chandelle. C’est une des meilleures façons de profiter de ce genre d’exercice. Je vous recommande de le faire à plusieurs. Cela permet d’échanger à propos des différentes étapes requises, de ce qui est important et de ce qui ne l’est pas, d’apprécier quand il faut s'arrêter …
Finalement, on peut ajouter la fonctionnalité demandée, compléter les tests et savourer sa victoire ;). Personnellement j’ai beaucoup aimé ce kata. Je l’ai même fait plusieurs fois avec des langages différents. A chaque fois j’ai découvert de nouvelles choses. Par ailleurs c’est certainement un des plus commenté sur le net et il est toujours passionnant de voir la variété des points de vue sur tel ou tel point.
Ressources sur ce kata : vous retrouverez l’énoncé de ce kata, et de beaucoup d’autres, sur le GitHub d’Emily Bache ici. Elle propose par ailleurs sur le site Pluralsight un exposé très clair de ce que sont les katas. Vous pouvez également lire son livre disponible sur leanpub. Vous trouverez une implémentation possible de ce kata sur le github de Sandro Mancuso. Enfin, sachez que le Web regorge de vidéos sur ce sujet.
Ressources sur le refactoring : vous trouverez des références intéressantes sur le site de Martin Fowler. Son livre, Refactoring : improving the design of existing code, même s’il commence un peu à dater, est un très bon point de départ pour se familiariser avec ces méthodes.