Les lecteurs assidus de notre blog en ont maintenant l’habitude : cet article résume un nouveau chapitre de l’excellent livre de Sandro Mancuso Software Craftsmanship – Professionalism Pragmatism Pride. Le chapitre 6 décrit la vision partielle du manifeste agile à propos du déroulement d’un projet. Il nous montre que ce qu’il est vraiment important de faire pour que votre projet soit un succès d’un point de vue 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é :
- Software Development
- Agile
- Software Craftsmanship
- The Software Craftsmanship Attitude
- Heroes, Goodwill and Professionalism
Working Software
Certaines sociétés mettent en place des structures très rigides, et essaient de contrôler les personnes et les processus afin de se donner l’impression de maîtriser les projets informatiques. En réalité ce qui permet de juger de la réussite d’un projet est bien le code qui a été déployé en production.
Le code en production est effectivement la mesure la plus tangible de l’avancée d’un projet, comme le déclare le manifeste agile. Mais le code compliqué et trop couplé qu’on rencontre trop souvent sur le terrain est bien du code de production. Le code qui n’est pas testé automatiquement et qui doit subir de nombreux tests manuels est également du code de production.
Ce code de production est-il suffisamment bien écrit pour permettre les évolutions rapides et sans régression, ou bien la qualité ne serait-elle pas une exigence qui aurait été oubliée au cours du temps ?
Il est facile de faire un parallèle entre l’activité de développement et le jardinage: il faut entretenir son jardin et ne pas se contenter de planter toujours plus, sans quoi de mauvaises herbes vont apparaître; les plantes seront trop nombreuses et ne pourront plus pousser.
Au début d’un projet, les fonctionnalités sont rapidement livrées. Mais plus le projet avance et plus ce rythme a tendance à diminuer. On entend souvent dire qu’au moment du développement, on n’a pas assez de temps pour travailler correctement. Or ce défaut de qualité se paiera extrêmement cher par la suite.
Lorsque le projet ralentit et lorsque ce ralentissement empêche le métier d’obtenir ce qu’il demande, il faut absolument prendre les mesures adéquates. Il est inacceptable de refuser des évolutions à cause d’une mauvaise qualité de code.
Si les développeurs du projet ne sont pas des craftsmen sensibilisés, sensibles à la qualité et à la conception juste, le projet échouera de manière prévisible.
La dette technique se creuse dès le premier jour d’un développement, même sur une fonctionnalité complètement nouvelle ne se basant pas sur le code existant du projet. On pourra aboutir à de la dette en utilisant un vocabulaire qui ne reflète pas les spécifications, en écrivant du code non testé, ou encore en écrivant du code qui ne sera pas utilisé.
Les développeurs ont la fâcheuse tendance à vouloir aller toujours trop vite pour livrer leurs fonctionnalités. Assez souvent, cet d’état d’esprit, qui part d’une volonté louable d’efficacité, conduit à une dette technique importante.
Histoire vécue : un développeur travaillait sur une application complexe (70 modules, des dépendances circulaires, des conteneurs Java EE lourds, de nombreuses files de messages). Il avait un bug urgent à corriger et passait le plus clair de son temps à rajouter des logs de debug, à déployer dans son environnement de test et essayer de comprendre ce que son propre code faisait une fois compilé, packagé, et déployé. Finalement, l’anomalie provenait d’erreurs logiques dans le code qu’un test unitaire aurait instantanément détecté.
Ce temps gaspillé est la conséquence de l’absence d’automatisation des tâches répétitives. Un testeur humain déroulant un plan de test est un non-sens, les bugs remontés par une équipe de testeurs devraient être le plus souvent improbables ; toute anomalie est le reflet d’oublis des développeurs.
Il ne faut jamais rendre l’écriture des tests optionnelle. C’est la responsabilité de l’équipe d’écrire un code de qualité qui fonctionne et il n’y a qu’avec des tests automatisés que l’on atteint cet objectif.
Une équipe de développeurs est responsable de livrer un logiciel de qualité suffisamment bien écrit, pour pouvoir réaliser facilement les adaptations demandées par le métier. La manière dont on remplit cet objectif passe par l’automatisation massive de toutes les tâches répétitives. Malgré l’impression que cette automatisation prendra du temps, il se trouve que ce temps sera toujours récupéré sur le long terme.
Même si tous les développeurs préfèrent démarrer un projet de zéro plutôt que de reprendre un projet existant, ils auront peu de chance d’être dans un projet de la première catégorie.
Il est inutile de se plaindre : il faut changer les choses. Le code existant est comme un gigantesque puzzle: on commence par les coins, on assemble dans sa tête les pièces, on les regroupe par couleurs. Petit à petit, les composants se distinguent les uns des autres. Puis on commence à les améliorer, puis l’amélioration va de plus en plus vite car les responsabilités sont de mieux en mieux isolées et faiblement couplées. On se retrouve à la fin à prendre du plaisir à améliorer les choses, à supprimer du code inutile ou le remplacer par un framework.
Quel que soit le type de projet : vieux de trois ans ou tout nouveau, ce qui fait la différence sur le long terme, c’est de savoir que le client obtient ce qu’il demande, et que l’on soit sûr d’avoir pris du plaisir à lui avoir fourni.