Qu’est-ce que la dette technique, et comment pouvons-nous la réduire ?
Imaginons que vous souhaitiez prendre l’avantage sur vos concurrents en ajoutant des fonctionnalités avant eux, que vous êtes pressé par la date de publication et que votre client exige les nouvelles fonctionnalités ici et maintenant.
Que faites-vous ?
Eh bien, vous pourriez commencer à travailler vite et mal :
- Vous « oubliez » de passer à la nouvelle version du compilateur.
- Vous ne suivez pas les directives de l’interface utilisateur.
Vous avez promis d’ajouter de nombreuses fonctionnalités au client dans un court laps de temps et vous manquez de temps : vous ajoutez quelque chose de nouveau et tout semble parfait… jusqu’à ce que ce ne le soit plus. Après la sortie du produit, vous commencez à recevoir des retours d’utilisateurs insatisfaits : ils ont trouvé des bogues. Le client, lui, ne comprend pas ce qui se passe.
Pour chaque € gagné en prenant des raccourcis pour sortir le produit rapidement, les intérêts sur cette dette pourraient coûter 4€ ! Prenez donc garde à ne pas contracter une dette technique trop importante.
La dette technique, qu’est-ce que c’est ?
La dette technique est une métaphore expliquant la situation dans laquelle vous avez deux choix pour ajouter une fonctionnalité :
- la bonne solution : à long terme, et qui demande beaucoup de temps
- une solution rapide mais désordonnée et imprévisible.
Lorsque vous choisissez la facilité, vous avez une dette technique, qui se traduit par des problèmes de code, des bogues et des difficultés dans l’ajout de futures fonctionnalités.
Pourquoi cela se produit-il ?
Voici une liste des causes possibles du problème :
- Des développeurs peu qualifiés, qui choisissent des solutions à court terme
- La concurrence et la pression du marché : l’équipe veut devancer la concurrence, surprendre les utilisateurs et mettre de nouvelles technologies sur le marché.
- La pression du budget et du temps, car le client veut tout, tout de suite.
- Ignorer les conséquences ou l’existence même de la DT (cela arrive surtout aux développeurs inexpérimentés).
Évidemment, vous devez considérer l’embauche de développeurs expérimentés, comme il s’en trouve chez Codeur.com .
La dette technique est-elle une si mauvaise chose ?
Pas tout le temps. Il existe différents types de dette technique – dans certains cas, elle peut même être une bonne chose.
Tout d’abord, lorsque vous êtes un nouveau venu, vous devez impressionner les utilisateurs avec vos fonctionnalités et vos idées. Parfois, vous devez le faire rapidement, avant que votre concurrent ne le fasse. Ainsi, passer du temps sur une solution à long terme n’est pas la meilleure option.
Deuxièmement, la dette technique fait parfois partie de la croissance de votre entreprise : vous lancez de nouvelles fonctionnalités et de nouveaux produits qui plaisent, et font connaître votre entreprise.
Comment gérer la dette technique avec la méthode Agile
Il est temps d’aborder la question : que faire si vous avez une dette technique ?
Voici quelques conseils.
Ayez une stratégie technique initiale claire
Avant de commencer le développement, il est important de réfléchir à tous les détails techniques critiques :
- Quelles décisions clés devez-vous prendre ?
- Que faudra-t-il ajouter à l’avenir ?
- De quelles fonctionnalités s’agit-il ?
- Disposez-vous d’un critère d’acceptation clair pour toutes les fonctionnalités du produit ?
En réglant ces questions avant de mettre en œuvre la solution, vous disposez d’une feuille de route plus claire.
Attribuez le projet à un architecte
Dans une équipe agile, l’architecte est chargé de guider les équipiers dans les décisions techniques importantes. En outre, il forme et encadre les membres dans la conception du produit, afin d’éviter la dette technique. Enfin, il garde un œil sur la dette technique et prend des mesures immédiates pour y remédier le cas échéant.
Refactorisez la dette
Le refactoring ne doit pas être confondu avec une réécriture complète du code. Il s’agit plutôt de le restructurer sans modifier la fonctionnalité du produit. Parmi les avantages, citons le fait de rendre les noms plus significatifs, de réduire la complexité en ajoutant des méthodes et de supprimer le code en double.
Ces changements sont généralement mineurs et devraient faire partie du développement quotidien.
Automatiser les tests
Exécutez régulièrement des tests complets. Ce faisant, vous pouvez identifier les défauts qui ont été injectés dans le code, ce qui vous permet de corriger le code ou d’apporter des modifications à un stade précoce.
Il est également conseillé d’automatiser les processus de test pour réduire les erreurs humaines et éliminer les sources supplémentaires de dette technique.
Réécrivez le code si nécessaire
Parfois, il peut être nécessaire de réécrire le code au niveau d’un module ou du paquet. S’agit-il d’une manœuvre dangereuse ? Oui. Mais est-ce que cela peut aider votre équipe à réduire la dette technique ? Oui aussi.
Il s’agit tout de même d’une décision un peu radicale, que vous ne devez prendre qu’après avoir correctement évalué la situation dans laquelle vous vous trouvez.
Vous n’avez pas suffisamment de force de travail pour résorber votre dette technique ? Trouvez des renforts gratuitement sur Codeur.com !
