La dette technique est un concept développé en 1992 par Ward Cunningham. Elle décrit le coût futur lié à des choix techniques ou de conception faits dans le présent pour accélérer la livraison d'un projet.
Elle a pour effet d’augmenter de façon croissante le temps de développement de nouvelles fonctionnalités, voire d'empêcher leur ajout.
Les effets de la dette sont délétères et extrêmement coûteux sur le long terme.
Nous allons nous concentrer sur JavaScript, le langage le plus répandu dans le web.
JavaScript et la dette technique
Par sa conception et sa permissivité, JavaScript est très sensible à la génération de dette.
L’évolutivité rapide représente aussi un facteur aggravant. Par exemple, l’introduction des Promises puis de async/await a rendu obsolète le fonctionnement des callbacks et facilité considérablement la gestion de l’asynchrone.
Néanmoins, tout le code utilisant les callbacks devient obsolète et donc il devient de la dette technique.
Et jusqu’à présent, rien n’indique que la conception est mauvaise, si en plus on ajoute des erreurs et des développements trop rapides.
Étape 1 pour solder la dette technique : le nettoyage
Pour comprendre cette étape, il faut imaginer une maison trop encombrée dont on veut changer la configuration des pièces.
Avant de réfléchir, il faut faire place nette. Ici c’est pareil. L’avantage numéro 1 est l’amélioration de la lisibilité.
Lisez le code de façon très précise et repérez le code mort. Une fois découvert, supprimer le.
Si vous doutez de la pertinence d’un code, vous pouvez utiliser un système de monitoring de type Sentry pour savoir si sur un ou deux mois d’utilisation normal, ce code est appelé. Si ce n’est pas le cas, vous pouvez le supprimer.
À ce stade, vous pouvez aussi implémenter des bonnes pratiques de type early return, factorisation et dédoublement de code.
Dans les cas de forte présence de dette, les gains ici peuvent représenter jusqu’à 20 ou 30% de la base de code.
Étape 2 pour solder la dette technique : la cartographie
En partant du principe que le besoin client est bien identifié, il faut cartographier techniquement l’application.
C’est-à-dire, construire un schéma de flux qui note tous les appels de fonctions. Même si celui-ci devient vite complexe à lire, il donne une idée du fonctionnement interne d’une fonctionnalité.
Cette carte sera utilisée pour le gros du travail de l’étape 3.
Étape 3 pour solder la dette technique : la refactorisation
Vous avez un code un peu plus lisible, vous avez une carte de celui-ci. À présent, utilisez cette carte pour refactoriser des flux de fonctionnement.
Par exemple, sur un processus de changement de mot de passe : réécrivez l’ensemble de la fonctionnalité en vous basant sur des bonnes pratiques (design pattern, lint et tests).
Remplacez les fonctions partagées en gardant leur signature.
C’est l’étape la plus longue, elle implique de reconstruire ce qui a été fait.
Elle permet de rembourser la dette de façon progressive, en réduisant les coûts de maintenance du code, en réduisant les bugs et donc en améliorant le produit aux yeux des clients.
Si vous avez des besoins pour résoudre la dette technique, nos experts peuvent vous aider.
