La dette technique
Lorsque l’on développe une fonctionnalité, un bout de code, un script, … il est rare de ne plus jamais en entendre parler. Evidement, si l’on code dans son coin pour apprendre un langage, cela peut être différent, encore que…
Faisons un saut dans le futur le temps d’un instant. Quelques jours, quelques mois ou bien quelques années plus tard, nous avons tous dû vivre ce fameux moment où… :
"What the fuck ?! Qu’est-ce que j’ai écris ?!"
Durant le laps de temps où vous avez laissé votre code de côté, vous avez très certainement évolué techniquement. Vous êtes censé vous améliorer. De fait, j’aime penser que le code d’aujourd’hui est meilleur que celui d’hier mais moins bien que celui de demain. On effectue alors une rétrospective de ce que l’on a écrit :
- Ce n’est plus la bonne façon de faire.
- L’architecture n’est pas évolutive. (Avez-vous pensé aux design patterns ?)
- La maintenance est compliquée car nous ne comprenons plus notre propre réflexion
- Vous retrouvez des copiés / collés de morceaux de votre code en pensant aller plus vite plutôt que de factoriser
- … Et certainement bien d’autres choses…
Vous avez du code, vous avez de la dette
C’est triste ? Mais pourtant, c’est la réalité. Il faut simplement en avoir conscience et avoir les connaissances nécessaires pour maîtriser cette dette.
Il y a plusieurs facteurs à la dette et le plus simple d’entre eux, selon moi, c’est celui du temps.
Faisons un bond en avant avec la version PHP 10 !
Comment ça, vous n’en avez pas entendu parler ? Moi non plus… Pourtant, il y a de forte chance qu’elle arrive un jour. Par rapport à cette version, votre code d’aujourd’hui est forcément moins adapté, il va falloir repasser sur les deprecated, les fonctions qui n’existent plus, les nouveaux concepts, … De fait, c’est un fait que vous subissez plus qu’un facteur que l’on pourrait maîtriser et c’est une dette que l’on appelle “non intentionnelle” / “non volontaire”.
La dette non intentionnelle, non volontaire
Celle que je viens de vous présenter en est une, mais on peut en trouver d’autres comme :
- La perte d’un des membres de l’équipe de développeur qui détenait la connaissance du métier ou de la technique d’une fonctionnalité
- Le manque de connaissances techniques
- La non utilisation des fondamentaux, de certains concepts
De manière général, nous pouvons caractériser cette dette d’un manque de connaissance (qui ne vient pas toujours de votre fait). Pourquoi ? Car si vous êtes au courant de tout ce qu’il faut, il n’y a alors pas de raison de vous fassiez des erreurs volontairement.
En plus du manque de connaissances que je viens de vous citer, j’ajouterais en causes potentielles tous les éléments dont vous n’êtes pas directement responsable, comme le choix de ne pas prendre le temps de refactoriser une partie de votre code ou d’une fonctionnalité qui évolue trop vite.
Quand je dis “directement responsable” cela concerne une variable dans le projet qui vous a été imposée et où vous n’avez pas eu le choix. Par exemple, celle-ci peut-être dû à votre hiérarchie, à un changement intempestif du client, ou bien à une variable externe à laquelle personne n’avait pensé.
En réalité, on retrouve énormément de composante lié au temps. Sur ce dernier exemple la dette serait potentiellement intentionnelle mais non volontaire.
La dette intentionnelle, volontaire
Celle-ci pourrait être mesurable. Vous avez pris la décision en votre âme et conscience d’effectuer une action qui provoquera de la dette et qui demandera obligatoirement une amélioration. Les raisons peuvent être multiple. Manque de temps, manque d’argent, manque de main d’oeuvre ?
Dans cette histoire de temps (eh oui, encore !), il faut savoir qu’un travail de qualité est forcément plus long à effectuer. De fait, pour pallier ces problématiques, il est souvent très facile de trancher dans le vif car nous préférons voir le projet livré dans les temps que de prendre du retard. A l’inverse, aimeriez-vous que l’on vous livre la construction de votre maison à l’heure même si on a oublié les tuiles, la pelouse, … ? Vous avez un toit, c’est bon non ? Tant que ça abrite. Soyez tout aussi intransigeant avec vos développements. Il existe des solutions qui ont fait leur preuve comme le principe SOLID.
On retrouvera quelques exemples de dette volontaire :
- Le fait de ne pas faire de tests (unitaires, fonctionnels, utilisateurs) de son application
- Le copié / collé qui tue
- Mettre de côté les fondamentaux
- Ne pas prendre le temps d’améliorer sa technicité
- Et bien d’autres…
Le mot de la fin
S’il y a une chose a retenir, c’est que vous avez forcément de la dette technique. L’important est d’en avoir conscience mais surtout de pouvoir la maîtriser. Ne pas rembourser, c’est prendre le risque de laisser notre crédit augmenter avec un taux d’intérêt considérable (plus de support, plus de temps développement d’une fonctionnalité qui devra s’articuler avec une architecture bancale, …). Quoiqu’il arrive, il vaut mieux rembourser ses dettes ou en tout cas, faire en sorte qu’elle n’augmente pas de manière exponentielle… alors adoptez la méthode Lannister.
