Gérer votre dette technique – Convaincre votre gestionnaire
Comprendre, gérer et convaincre : découvrez les stratégies pour maîtriser la dette technique en développement logiciel.
Vous lui proposez de regarder les fichiers avec lui, voir s’il n’y a pas une façon plus rapide d’implémenter la fonctionnalité demandée. En regardant les fichiers vous constatez le problème. Le code est effectivement dur à lire et la logique d’affaire est éparpillée dans les différents fichiers. Il faudrait définitivement mettre de l’ordre là-dedans, mais il faut livrer pour vendredi et on est déjà mercredi. Vous trouvez une façon de contourner les problèmes en vous jurant d’ajouter la dette technique dans le backlog… La prochaine étape sera de convaincre votre gestionnaire commun de l’importance de prioriser cette tâche dans la prochaine itération.
Voici, dans une coquille de noix, les effets délétères de la dette technique. En effet, cette métaphore illustre l’idée que non seulement « pelleter les problèmes par en avant » ne résout pas le problème, mais encore que les problèmes s’accumulent de façon exponentielle, à la façon des intérêts d’une dette.
Y-a-t’il des moments où c’est judicieux de faire un emprunt technique? Comment gérer une dette technique connue? Comment prioriser la correction de la dette technique? Est-ce qu’il faut toujours la rembourser? Mais d’abord, définissons plus clairement ce qu’est la dette technique.
Bien comprendre la métaphore de la dette technique
La première fois que le concept de dette a été associé à des raccourcis dans le code, c’est par Ward Cunningham1, en 1992. Il décrivait que dans le but de produire rapidement une itération utilisable par l’utilisateur, produire du code immature était tout à fait acceptable, comme de faire un emprunt. Il était cependant important de repayer la dette à très court terme, sous peine de crouler sous les dettes et d’avoir un code impossible à maintenir.
De nos jours, le concept a évolué et il dépasse même le code en tant que tel. La dette technique2 peut être décrite en fonction de l’étape de la conception à laquelle le compromis a été effectué :
Comment prend t-on de la dette technique?
Rendons à César ce qui revient à César : Martin Fowler a fait une excellente analyse de la dette technique dans son blogue4. Il en est venu à la conclusion qu’on pouvait en arriver à 4 types de dettes techniques, qu’on peut représenter dans le tableau suivant :
|
Volontaire |
Involontaire |
|
|
Imprudente |
Ex : notre exemple d’introduction |
Ex : une équipe qui manque de connaissance |
|
Prudente |
On fait l’emprunt, pour le rembourser rapidement |
On veut bien faire, mais on trouve la meilleure solution après… |
Comme dans nos finances, une dette prudente peut permettre d’atteindre un objectif intermédiaire plus rapidement. Ce n’est donc pas mauvais en soi, l’idée c’est de rembourser rapidement!
Une dette involontaire est plus difficile à conceptualiser : en effet, quand on emprunte dans la vie courante, on est conscient de le faire, même si ce n’est pas toujours raisonnable. Toutefois, l’idée mérite qu’on s’y attarde.
Parfois l’équipe est trop junior pour être consciente qu’elle prend des décisions qui vont l’affecter à cours/moyen terme. C’est là toute l’importance de la formation et du partage de connaissance.
A contrario, une équipe compétente peut ne pas savoir la solution optimale, même si le produit livré est fonctionnel et apprécié du client. En effet, un développeur, tout expérimenté qu’il soit, va souvent voir son ancien code en se disant qu’il aurait fait mieux. C’est normal, presque chaque ligne de code est un apprentissage. On évolue constamment, et le marché avec nous.
Le remboursement, avec les intérêts
On veut rembourser le plus rapidement possible, mais ce n’est pas toujours facile ou même souhaitable. En effet, il y plusieurs facteurs qui peuvent entrer en ligne de compte.
L’exemple classique c’est le code spaghetti… qui fonctionne bien. À moins de le connaître complètement par cœur (et même là), il faut non seulement penser au temps passé à le corriger, mais également aux efforts pour vérifier la non-régression. Le tout en espérant ne pas avoir briser de fonctionnalités oubliées. En effet, rembourser une dette technique présente des coûts!
Oui, il existe une méthode « facile » pour mitiger ces risques5, mais elle implique elle-même pas mal de modifications. Aussi, ne sous-estimons pas l’importance d’une documentation complète et rigoureuse…
De toute façon, le problème reste entier. Est-ce le bon moment pour rembourser notre emprunt?
Une façon pragmatique de voir les choses, c’est en fait de se demander quel est l’impact de ne rien faire6. Parfois, il est très faible. Même si le code est objectivement dégueulasse, s’il n’y a plus de développement actif dessus, il y a plus de risque à payer la dette qu’à le laisser tel quel. Cependant, si le client demande une nouvelle fonctionnalité, il faudra prendre en compte la dette technique dans le projet.
Dans un projet actif, toutefois, il faudra évaluer la pertinence de chaque élément de dette par rapport aux corrections de bogue et les autres modifications. Pour ce faire, il faut penser que la vélocité des modifications est impactée par la dette technique. Au-delà de la méthode du cadet*, soit toujours laisser le code plus propre à la fin de son travail qu’au début, c’est de regarder à quel point ce code va se dégrader si on ne fait rien et à quel point ça nous nuit, toujours en tenant compte de l’impact de la modification sur le reste du cycle de développement.
Ces règles du pouce sont très utiles pour de la dette technique connue (souvent volontaire). Mais qu’en est-il de la dette inconnue – autre que de l’ignorer, évidemment? Le plus simple, c’est de parcourir l’entièreté du code d’un projet et analyser les points de friction, les classes trop couplées, les régions à problème et de les prioriser en fonction des critères de dégradation et de nuisance vue précédemment. De nos jours, il existe des méthodes automatisées pour détecter les zones à risques comme SonarQube, Coverity, Snyk Code, Cast ou encore CodeScene7. Les revues de code sont également des bons moments pour remarquer une dette technique existante.
En conclusion
1 The WyCash portfolio management system
5 https://www.kuriosit.ca/travailler-avec-le-legacy-code/
6 A Framework for Prioritizing Tech Debt – Max Countryman
7 How to Measure Technical Debt: Step by Step Guide
*L’autrice a été dans les cadets de l’air et non dans les scouts, c’est pourquoi elle renomme la règle de Uncle Bob. C’est exactement le même concept.