Comment maîtriser sa dette technique dans un projet

Difficulté : | 10' Publié il y a 2 mois
La dette technique, cet inévitable poids à se traîner le long des projets, lors de phases de maintenance ou d'évolution... Regardons ensemble comment la limiter.

La dette technique est inévitable.

Mais en fait, c'est quoi la dette technique ?

La dette technique est une métaphore du développement logiciel inventée par Ward Cunningham en 1992. Un non-respect de la conception, intentionnel ou non, induit des coûts supplémentaires dans le futur. C'est pourquoi l'on parle de dette. Cela sous entend qu'il vaut mieux rembourser cette dette un jour plutôt que de continuer à payer sans cesse des intérêts. (source Wikipedia).

On va pas se le cacher, il n'est pas possible de s'affranchir totalement de dette technique sur un projet. Il faut donc assumer que nos réalisations possède dès le départ une dette, qu'il faut vivre avec et faire le nécessaire pour la maîtriser.

La dette technique ? Non, LES detteS techniqueS !

En fait, si on regarde plus loin, la dette existe à tous les niveaux ! En frontend, en backend, dans les outils de déploiement, dans les solutions de tests, dans l'infrastructure serveur... même peut être dans la gestion de projet ! Tous les secteurs et tous les domaines peuvent être affectés !

Quand on parle de dette, c'est même plusieurs notions différentes qui peuvent en créer :

  • L'Obsolescence : utiliser de vieilles bibliothèques, de vieilles méthodes... tout ça devient un jour obsolète... C'est une des sources de dette technique. L'exemple le plus flagrant est d'utiliser par exemple, des technologies qui ne sont plus mises à jour depuis des années dans un projet tout juste créé.
  • Le Code de cochon : coder sans guidelines, sans bonnes pratiques, ne pas avoir d’homogénéité entre les projets et les autres développeurs...
  • L'Over engineering : vouloir faire un code de l'enfer capable d'être réutilisable à l'infini, et finalement faire une machine à gaz incompréhensible par personne et avec beaucoup d'abstraction, c'est aussi une source de dette technique par la suite !
  • Le Jeunisme technologique : en fait, c'est l'inverse de l'obsolescence. Partir sur des technos très jeunes , parfois instables et pas stabilisées... c'est courir le risque de tout voir couler au bout de quelques mois en découvrant que c'était (peut être) un mauvais choix. (techno abandonnée par les créateurs, par exemple...)

Dette technique : exemples, retours d'expérience (et un peu de troll aussi)

Ce projet est notre nouvelle référence technique !
— Mai 2016

Comment j'ai pu écrire ça ?!
— septembre 2016

Le magnifique code qui est produit aujourd'hui sera le monstrueux code de demain. Les technologies évoluent et les développeurs progressent ! C'est aussi pour ça que l'amélioration continue est utile : méthode SCRUM, méthode Kaizen...

Franchement, python c'est le langage parfait pour un api !
— 1er décembre 2016

Franchement, Golang, c'est le langage parfait pour un api !
— 15 décembre 2016

Et oui, chacun son avis sur le choix d'une techno ! Seulement, à un moment, il faut décider et d'une manière la plus collégiale possible.

Utiliser React pour faire une liste à puce c'est plus rapide !
— 1er décembre 2016

React pour faire ça ? VueJS, c'est mieux !!
— 15 décembre 2016

Les technos évoluent rapidement et ce qui était une référence il y a quelques mois n'est plus forcément vrai aujourd'hui ! Il est toujours important d'avoir du recul pour ne pas céder trop hâtivement aux chants des sirènes.

Le cas de l'upload

Qui ne s'est jamais dit : "je vais faire quelque chose de générique pour la prochaine fois" ? Et finalement, la fois suivante, vous repartez sur quelque chose de vierge, à jour techniquement, en repartant dans l'idée de pouvoir faire quelque chose de réutilisable.

C'est souvent le même combat pour les slideshows, les parties d'administration, les processus d'envois d'emails...

Quelques facteurs liés à la dette technique

  • Plus il y a de technos, plus la maintenance sera difficile. C'est évident. Varier les technos, c'est souvent varier les compétences. Dans 2 ans, les acteurs du projets ne seront peut être plus les mêmes, les problématiques non plus... Et on ne parle même pas des dépendances.
  • Code compréhensible = maintenance facile.
  • Pas de développeur unique par fonctionnalité/projet. En passant par des code reviews, du développement en pair programming, etc... on partage les compétences et expériences. On favorise ainsi la reprise d'un projet par d'autres développeurs facilement.
  • Apprendre de ses erreurs par des débriefs réguliers et des ateliers techniques
  • Normaliser les pratiques de développement.

Je ne code pas (que) pour moi, je code pour les autres. Il faut trouver le bon équilibre entre stabilité, fiabilité et nouveauté.

Aussi, mon client ne doit pas assumer mes expérimentations !

La bonne techno pour le bon besoin.

On en parlait plus haut, mais il est très important de bien comprendre ceci : on ne gagne pas un Tour de France avec un VTT, aussi performant soit-il. Un choix technique ne doit pas être arbitraire. Il doit être discuté et argumenté par une équipe technique. Même si, parfois, le client souhaite imposer sa stack technique.

On harmonise nos développements

La clarté doit primer sur les perfs et la qualité dans une moindre mesure. Ouuuula, des poils s'hérissent. On peut en discuter en commentaire en tout cas ;-) !

La standardisation du code, les code reviews, les ateliers techniques et une architecture de projet validée À PLUSIEURS. Des décisions prises à plusieurs sont plus responsabilisantes et permettent de limiter la dette technique.

En tout cas, c'est ce que nous travaillons constamment au sein de notre équipe pour les projets gérés à l'agence !

Les 6 règles d'or pour maîtriser sa dette technique

  • Je note la stack précise dans le README du projet pour mettre au courant les futurs collaborateurs
  • J'utilise uniquement des technos testées
  • Chaque choix technique doit être débattu dans l'équipe
  • Je ne renie pas les anciennes technos !!
  • Je commente efficace
  • Je pense à la vie "d'après" de mon projet

On mesure aussi la dette technique par la facilité de maintenance.

Cet article est valable aujourd'hui, mais qui sait ? Peut être que demain il ne sera plus, puisqu'il comporte lui même sa dose de dette technique potentielle. Et vous, quel avis ? Ce sujet est à débattre, et bien sûr, à améliorer ;-) !

Tags de l'article :

Cet article n'est pas taggué.

Commentaires