Réduire sa dette technique
Introduction
Dans cet article, nous allons nous attarder à analyser les bonnes pratiques à adopter afin de réduire au maximum la dette technique lors des différentes phases d’un projet. Cependant, nous partons du principe qu’une dette technique, tout comme peut l’être une dette financière, n’a pas forcément que de mauvais aspects.
Un code est comme un être humain, il vieillit et peut rapidement se trouver en marge lors de l’apparition de nouveaux critères et nouvelles méthodologies de programmation. Ainsi, sur quelque projet que ce soit, le code finira par se détériorer avec le temps. Ce problème peut être limité s’il est pris en compte lors de l’élaboration de chaque phase du projet. L’intérêt principal ? Réduire le temps de développement et la fréquence d’apparition de bugs. Avant toute chose, il est important de préciser que vous avez obligatoirement une dette technique à partir du moment où vous faites appel à du code pour la programmation.
DEFINITIONS
Abordons maintenant la définition même de la dette technique. Si la définition Wikipédia est très claire sur le sujet, nous allons vous donner la nôtre. Créé par Ward Cunningham en 1992, le terme de dette technique n’est ni plus ni moins qu’une métaphorisation de l’agglomération de problèmes techniques résultant de l’évolution d’un code source plus ou moins maintenable. La dette technique se traduit par des bugs, des retards dus à des implémentations risquées où à un manque de test en amont du projet.
Par ailleurs, la dette technique peut aussi être obtenue avec un résultat satisfaisant. Je m’explique, un projet peut être mené à bien et remplir l’ensemble des fonctionnalités nécessaires à l’entreprise tout en possédant un code qui ne pourra être maintenu à cause d’une base trop “sale” dû à un manquement au niveau des tests.
Il serait pourtant plus juste de classifier la dette technique comme étant pluriel et dire les dettes techniques. Plus encore, il est important de déterminer qu’il existe deux types de dettes techniques : les volontaires et les involontaires. Et, oui, il est possible d’accroître une partie de sa propre dette technique de façon délibérée. Explication :
- Si une dette technique est involontaire, on dit qu’elle est naturelle. Ainsi, elle dépend indirectement d’une décision prise par un développeur. Bien souvent, cette dette résulte d’un composant mal implémenté ou en constante évolution sans qu’un suivi ne soit assuré. Autre gimmick de la dette technique involontaire, une non-remise en cause du modèle initial ou des patterns usités. Enfin, comme dans tout projet, un vieillissement des technologies est à prendre en compte, de même que l’évolution interne des équipes qui fait évoluer le niveau technique et donc le niveau de suivi des différentes composantes.
- La dette volontaire est compréhensible mais risquée puisqu’elle accroît forcément la somme globale des problèmes du projet. Celle-ci se traduit par la prise de décision orientée vers une deadline courte. De même que les mises à jour souvent repoussées par les équipes techniques, chacune des parties prenantes doit prendre des décisions unilatérales qui vont entraîner un potentiel freinage sur d’autres parties et ainsi faire perdre du temps à tout le monde. Le choix est pourtant obligatoire pour avancer de façon régulière.
e
Un problème, pour qui ?
Mais à qui cela pose véritablement problème ? À pas mal de monde finalement. Si l’aspect financier impacte forcément le Product Owner, un ralentissement de la production va directement interagir avec les équipes marketing et de communications ainsi que sur les clients qui, potentiellement, peuvent être en attente d’un service. Premiers touchés, les développeurs sont à la fois coupables et victimes des dettes techniques en se retrouvant tantôt frustrés, tantôt accusés de créer des bugs et autres problèmes (notamment sécuritaires).
Bonnes pratiques et méthodologie
Quelles sont les pratiques à adopter afin de maitriser – car il est impossible de ne pas en avoir du tout – sa dette technique en amont tant qu’en aval du projet, c’est la question que chaque chef de projet doit se poser avant de lancer ses équipes sur les phases techniques. Ainsi, il existe plusieurs méthodologies de travail permettant de limiter la dette technique tout au long du processus de programmation et de le rendre inévitablement plus maintenable sur la durée.
La première de ces méthodologies est d’avoir conscience que les dettes techniques – car oui il en existe à tous les niveaux et non une seule – sont forcément présentes et qu’il ne sera pas évident, voire impossible, de toutes les traiter. Il va donc falloir focus sur les éléments les plus importants. Reste donc à déterminer comment et où détecter les dettes techniques et ses composantes. C’est relativement simple car elles se concentrent généralement en deux points principaux : l’obsolescence des bibliothèques et du code source dues à une programmation souvent réalisée en accélérée à cause des pressions temporelles exercées par les leaders du projet. Une fois la prise de conscience acquise, il est envisageable de budgéter la dette technique ou du moins d’inclure les coûts (humains, techniques, temporels) dans les estimations de départ. Ces dernières peuvent même être estimées lors d’une partie de Planning Poker Scrum. Puis, pensez à toujours matérialiser votre dette technique de façon physique et visible par l’ensemble des acteurs du projet. Pour cela, vous pouvez notamment l’associer au backlog et ainsi traiter quotidiennement les différentes parties du code à améliorer.
Ensuite, il vous faut prioriser les fonctionnalités afin d’apporter les modifications nécessaires rapidement sur les composants entraînant une évolution de la valeur du projet ou de l’entreprise qui dirige. Définir les priorités peut être fait durant une partie de Planning Poker Scrum. Après priorisation, l’essentiel résidera dans le fait de temporiser et de canaliser la dette technique afin qu’elle ne prenne pas la majorité de la place dans le travail des différentes équipes.
Pour réaliser continuellement une veille sur les dettes techniques, il est important de mettre en place des réunions spécifiques qui tournent autour de quelques questions telles que :
- “Avez-vous repéré de la dette technique ?
- Expliquez ce qui vous pose problème dans le code ?
- Avez-vous besoin de plus de temps pour rendre ce code maintenable ?
- Etc.”
Du même fait, il est facile de repérer une dette technique potentielle en écoutant les réactions. Si vous entendez des choses comme :
- “Ne touche pas à ce code, seul … sait le gérer”,
- “Oui mais je ne peux pas faire ça car telle chose a été mal pensée”,
- “Tu peux directement copier-coller ce morceau de code”,
Réagissez avant de vous retrouver vous-même bloqué et demander une réunion au besoin.
Penser aux tests automatisés c’est l’assurance d’une dette technique moins élevée. L’instauration de tests unitaires, du TDD et du BDD sont essentiels pour garder une mainmise sur le contrôle de la dette technique. Si votre ensemble de tests est efficace, il doit vous permettre de couvrir 90% de la programmation, si cette couverture descend sous les 70%, il est grand temps de vous concerter avec vos collègues et d’adopter une méthodologie adaptée à votre problématique de dette. Passer du temps sur les tests vous en fera gagner sur le refactoring (qui sera nécessaire) et vous assurera surtout de la viabilité de votre code plutôt que de vous auto-persuader de la maintenabilité de celui-ci après que vous l’ayez refactorer plusieurs fois sans prendre soin de le tester.
Il existe ainsi plusieurs façons de mesurer la dette technique de manière automatisée. Hormis l’instauration des tests automatisés comme cité ci-avant, il existe des instruments à même de vous donner une première image de votre dette technique, parmi ceux-ci, on peut citer Sonar et son évolution SonarJ par exemple. Cet outil vous permet notamment d’assurer aux développeurs le suivi des bonnes pratiques au niveau des classes et autres éléments de méthodes. SonarJ (Java) vous permet aussi de vérifier le cycle de vos tests et ainsi vérifier la validité des cycles de programmation. En surveillant ainsi l’ensemble des KPI’s (indicateurs de performance), vous pourrez rassurer votre équipe en expliquant le positif des modifications apportées et surtout intégrer les nouvelles données à votre plan d’action et, si besoin, prioriser de nouveaux les fonctionnalités.
Résumons : Il est important de réaliser des tests et une supervision de l’ensemble du projet de manière itérative pour visualiser et estimer au mieux la dette technique. Si la veille et la communication est respectée grâce aux différents outils explicités, le plan d’action doit être réalisé en fonction et ainsi rendre le code plus propre et maintenable pour l’avenir.
Est-ce vraiment négatif de cumuler des dettes techniques ?
Si le terme de “dette” fait forcément penser à quelque chose de négatif, ce n’est pas toujours le cas. Premièrement, et nous l’avons cité précédemment, une dette technique peut-être en partie intentionnelle et dépendra du projet en création et des choix du Product Owner et de l’équipe technique.
Par ailleurs, il faut une nouvelle fois rappeler que la dette technique est aussi un moyen d’adopter, dès le début, les bonnes pratiques et les meilleures méthodologies afin de produire le code le plus propre et maintenable possible. Par ailleurs, un bon suivi de la dette technique apportera une connaissance approfondie du projet dans sa globalité par l’ensemble des acteurs du projet et donc une montée en compétences de chacun. Elle peut aussi permettre de resserrer les rangs autour d’une problématique commune et renforcer la communication afin que chacun puisse régler les problèmes d’un autre développeur.
Comment rembourser sa dette technique ?
Si elle présente de nombreux avantages, cette méthode ne peut fonctionner que dans les groupes motivés et surtout respectueux. La répétition des tâches et la rapidité d’exécution des tests et des rendus livrables fait que la pression peut parfois faire craquer certains des collaborateurs. Aussi, l’importance d’une cohésion de groupe et d’une solidarité à tous niveaux est primordial à l’aboutissement du projet.
La dette technique et l’Extreme Programming
Les deux concepts de dette technique et d’Extreme Programming sont souvent liés du fait de leur apport sur la gestion d’un projet. En effet, tandis que l’Extreme Programming oriente les équipes vers les bonnes pratiques en poussant les principes les plus simples à l’extrême.
Si aujourd’hui ces deux notions sont fréquemment exprimées en même temps, c’est que l’Extreme Programming peut permettre de drastiquement réduire la dette technique. Si tant est que vous ayez fait l’effort de prioriser les fonctionnalités et d’instaurer une batterie de tests, l’Extreme Programming vous permet d’encadrer au mieux les bonnes pratiques et surtout de pousser au maximum l’exemplarité du comportement professionnel des développeurs.
Conclusion
S’il est communément admis qu’avoir une dette technique est obligatoire, il existe cependant de nombreuses méthodologies, plateformes et outils permettant de la limiter au maximum ou, du moins, de réduire les impacts sur les fonctionnalités considérées comme les plus importantes pour l’user story. Il est primordial de ne jamais laisser la dette technique de côté au risque de se retrouver avec un code inmaintenable très rapidement. Par ailleurs, considérer la dette technique est le meilleur moyen d’acquérir les bonnes pratiques de développement qui vous permettront par la suite de gagner en vitesse et en efficacité lors de l’implémentation (testée) des fonctionnalités possédant le plus grand intérêt.