Comprendre et gérer la dette technique

Table des matières

Comprendre et gérer la dette technique

Ce n’est certainement pas le sujet qui préoccupe lorsque l’on débute. En fait, un débutant n’a pas encore connaissance de la dette technique.

Pourtant il me paraît judicieux de vous en parler surtout si vous êtes un débutant.

Même si vous ne pourrez pas appliquer tout ce que je compte vous dire. Le simple fait de savoir ce que c’est et d’en être conscient est déjà pas mal.

Vous l’aurez en tête et vous prendrez de meilleures décisions pour l’avenir dans votre code.

Source : https://www.commitstrip.com/fr/2016/07/12/the-last-technical-debt/ 🔗

Mais c’est quoi au juste la dette technique ?

Ce terme a été inventé en 1992 par l’inventeur de concept de wiki, Ward Cunningham. Il s’est inspiré du concept de dette dans le domaine des finances pour l’appliquer au domaine logiciel.

Bon OK je ne vous aide pas avec ça ! Alors on va exprimer ça dans notre langage.

La dette technique c’est le fait d’ajouter de la complexité à un projet engendré par des décisions techniques qui entraînent la livraison d’un logiciel de faible qualité.

Et là vous vous dîtes que lorsque l’on écrit du code pas propre ? Mouais en partie, mais pas uniquement sinon ce serait trop facile. Tout va se jouer autour du projet de développement en lui-même donc pas uniquement sur le code.

Le choix des technologies, de l’infrastructure de l’application, mais aussi la gestion de projet vont provoquer plus ou moins de la dette technique.

Explorons un peu le sujet pour comprendre les facettes.

Les principaux type de dettes techniques

Avant d’aborder ces types, vous devez savoir qu’il n’existe aucun, et je dis bien aucun, projet de développement sans dette technique. Vous devez être assuré sur le sujet, vous aurez forcément de la dette technique et il est impossible de la réduire à zéro.

Le seul moment où la dette technique est égale à 0, c’est lorsque vous n’avez pas encore écrit une seule ligne de code.

Revenons sur notre sujet. Il existe 2 types de dettes techniques que je vais vous illustrer.

La dette technique involontaire

Comme son nom l’indique, elle est involontaire. La plupart du temps vous n’avez pas conscience de cette dette technique ce qui la rend très difficile à la percevoir.

Elle peut donc se manifester sous diverses formes et vous n’en êtes pas totalement maître puisque vous ne l’avez pas forcément provoqué vous comme votre équipe

Mais qu’est-ce qui la provoque au juste ? Il y a plusieurs facteurs à cela, mais principalement c’est votre projet en lui-même et tout ce qui gravite autour.

Si vous devez par exemple reprendre un projet existant ou tout simplement cohabiter avec lui, c’est de la dette technique involontaire.

Avoir un chef de projet au-dessus de vous qui prend et vous impose des décisions techniques peut vraisemblablement provoquer de la dette technique

Plus vous allez développer des fonctionnalités plus votre application va grossir, mais surtout se complexifier.

L’impact de cet avancement dans votre projet va vraisemblablement vous ralentir et rendre de plus en plus difficile la maintenance de votre projet.

Rencontrer des difficultés et allonger les temps pour la maintenance de votre application, c’est de la dette technique involontaire.

Et les 2 causes directes à cela qui sont aussi très liées ce sont l’équipe en charge du projet et leurs connaissances.

Je m’explique.

La plupart du temps une équipe de développeurs en charge d’un projet est très hétérogène. Il y a des experts, des juniors et parfois même des stagiaires.

Tout le monde n’a pas les mêmes connaissances techniques ni même les compétences au début d’un projet. Et la logique veut que la qualité de l’application en sortie soit nécessairement affectée.

Alors évidemment, de mauvais choix techniques en termes de code et d’infrastructure vont se manifester dès le début du projet sans que vous vous en rendiez compte.

Et donc naturellement plus vous allez avancer, plus vous allez faire de nouveaux choix techniques et plus le projet va se complexifier de plus en plus.

On peut donc résumer la dette technique involontaire comme un manque de connaissance technique et d’expérience d’une équipe de développeurs.

C’est donc naturel, car comme dit le dicton c’est en forgeant que l’on devient forgeron !

La dette technique volontaire

Alors celle-là est plus problématique, car vous allez volontairement en créer et elle est facilement identifiable.

J’ai besoin urgemment de cette petite fonctionnalité dans les jours à venir.

Il me faut un truc rapide et pas cher

On en produit très souvent lorsque l’on réalise de la nouvelle feature. Le client peut être un facteur de cette dette technique, car il peut exercer une pression sur votre équipe en alliant le pas cher et très rapidement.

Et bien entendu cela marche aussi avec les demandes de toutes dernières minutes.

Mais même si c’est souvent le cas, il n’y a pas que ce facteur-là qui entre en jeu. Le fait de mal évaluer le temps et le coût ou de mal gérer le projet va vous créer de la dette technique.

Car votre équipe va se précipiter vers la fin du projet pour tenir son engagement. Et en général, elle fera l’impasse sur les bonnes pratiques et prendra de nombreux raccourcis pour atteindre l’objectif.

Le respect des bonnes pratiques devient la plupart du temps un lointain souvenir. Même si c’est légitime et que cela paraît justifier cela va vous créer drastiquement de la dette technique à côté de tous les autres problèmes que vous pourriez subir par la situation.

Comment éviter la dette technique ?

Comme je vous l’ai dit au début, il faut tout d’abord prendre conscience que cela existe et que vous allez en créer. Vous n’y échapperez pas !

Puis vous devez la comprendre (comme je vous l’ai expliqué) pour pouvoir mieux la canaliser et éviter au maximum de la dette volontaire.

Pour éviter au maximum la dette technique, il faut que chacune des parties prenantes de votre projet soit totalement maîtrisée.

Que ce soit dans l’aspect technique du projet comme dans son management.

Mieux communiquer, être réaliste et n’ayez pas peur de dire non ou de trouver le juste milieu entre ce que veut le client et ce que vous pouvez produire.

Il faut savoir cadrer la pression et les timings pour ne pas vous laisser bouffer par votre client, car n’oubliez pas que vous êtes l’expert.

Mais comment l’éviter lorsque l’on est débutant et qu’on ne se sent pas légitime. Malheureusement, je n’ai pas de recette miracle et cela dépendra dans quel contexte vous allez évoluer.

Mais ce que vous pouvez faire d’un point de vue personnel c’est de vous perfectionner sur les bonnes pratiques en matière de codes et d’architectures applicatives.

Je vous conseille d’ailleurs de commencer par le Clean Code.

Une dernière chose, sensibiliser votre équipe sur la dette technique ainsi que sur l’application et le respect des bonnes pratiques.

Rembourser la dette technique intelligemment

C’est une notion que je n’ai pas abordée jusque là, mais que vous devez quand même comprendre. Quand vous créez de la dette technique, le principe veut que vous deviez la rembourser à un moment.

Mais vous ne devez pas la rembourser n’importe comment. Il faut une stratégie efficace pour réaliser cette opération intelligemment.

Tout d’abord, comprenez qu’il vous est impossible de rembourser totalement la dette technique parce que vous en aurez tout le temps et que vous allez nécessairement en recréer.

Mais il est par contre très intelligent de se focaliser sur certaines parties applicatives pour en améliorer le code ou l’architecture tout simplement.

Si vous voyez qu’une partie de l’application peut être fondamentalement améliorée, mais surtout qu’elle risque de changer et d’évoluer par la suite alors vous pouvez rembourser cette dette.

Dans le cas contraire si vous voyez une partie de code obscure dans l’application, mais qui n’a pas changé depuis plusieurs mois ou année, alors ça ne sert à rien de rembourser la dette technique (si tout marche comme convenu bien entendu).

Epilogue

J’ai vraiment survolé le sujet pour que cela soit accessible aux débutants et que vous en preniez conscience.

Vous devez comprendre que le respect des bonnes pratiques et la bonne maîtrise de votre projet peuvent fondamentalement faire la différence et éviter au mieux de la dette technique volontaire.

Voyez cela comme votre pire ennemi, car il pourra jouer énormément sur votre motivation et votre moral dans votre travail de tous les jours.

Car pour l’avoir vécu moi-même il n’y a rien de pire que de devoir se lever le matin en sachant que l’on doit travailler sur du code sale pour en recréer en plus par dessus.