Christophe Nowicki

Je viens de finir une analyse de code pour un client. J’aime beaucoup ce type de missions, car elles permettent de remettre en perspective mon travail et de mieux analyser les différentes implications de l’organisation sur le développement.

J’essaye dans ce type de mission d’identifier quels sont les points d’organisation qui transparaissent dans l’analyse de code.

Dans plusieurs cas, j’ai pu retrouver des similitudes. Ces similitudes peuvent être regroupées sous le terme de “dette technique”.

Dans cette article, je vais essayer de définir le concept, vous présenter les symptômes, les origines, les conséquences et les solutions envisageables.

Définition de la dette technique

Lorsque vous ajoutez une fonctionnalité à un logiciel, vous avez deux
possiblités :

• Faire le plus rapide possible, c’est à dire en utilisant la
  technique la plus facile, la plus rapide et négliger la conception
• Prendre le temps de réaliser proprement la fonctionnalité, créer une architecture, spécifier les besoin fonctionnels, techniques, faire des tests, etc.

On peut établir une métaphore financière avec la mise en place d’une solution à court terme telle qu’évoquée dans le premier cas de figure en parlant de dette technique.

Vous empruntez du temps sur l’avenir. Comme dans le cas d’un crédit. Mais le coût de cet emprunt n’est pas nul.
Plus vous développez rapidement et mal et plus la dette grandit, les intérêts se cumulent.
Et le projet peut faire faillite sous le coût de la dette.

Symptômes

Voici des exemples de situations réellement vécues au sein d’entreprises :

• Absence de documentation sur la structure du projet : où se trouve le code source? dans quel répertoire se trouve la documentation du projet, où sont les fichiers CSS, etc.
• Aucun test unitaire ou fonctionnel ;
• “Lorsque je change une ligne dans le module A, cela casse le fonctionnement du module B”
• “Ne touche pas à cette partie du code, nous ne savons pas ce qu’elle fait exactement, mais dieu merci cela fonctionne encore” ;
• Nous venons de perdre un disque dur sur le serveur de production, où sont les sauvegardes?
• J’ai l’impression d’avoir déjà corrigé ce bug plusieurs fois, étrange….
• Code sans aucun commentaire ou avec des commentaire trop anciens ;
• La connaissance du projet dépend d’une seule personne ;
• Je vais mettre un commentaire TODO ou FIXME et je corrigerai le problème plus tard ;
• Nous ne pouvons pas mettre à jour les composants du serveur, cela va casser le code ;
• Nous n’avons pas le temps de faire cela, ce n’est pas une urgence vitale ;
• Nous ne pouvons pas mettre à jour le code, personne ne comprend cette partie du code …
• La personne responsable du module est partie en vacances …

Vous avez aussi entendu ou vécu ce genre de situation ?
Alors appelez le 81212 et dites ‘Thermomètre’ ;-)

Les origines

Qui est responsable de ces problèmes. La réponse est assez simple, car chaque intervenant du projet est responsable :

• le chef de projet qui néglige la conception, planifie mal
  l’exécution des tâches ou ne transmet par correctement les demandes des clients ;
• le client qui s’introduit dans la conception technique du
  logiciel et qui impose brutalement son point de vue ;
• le développeur qui ne sait pas dire “non”, qui surestime ses
  capacité ou bien qui ne joue pas collectivement dans une équipe ;
• les utilisateurs avides de fonctionnalités et volatiles dans leur
  demandes ;

Les conséquences

Les conséquences de la dette technique sont les suivantes :

• Augmentation du temps de développement ;
• Impossibilité de prévoir et d’anticiper les coûts d’entretien ;
• Difficulté pour faire rentrer un nouveau développeur dans l’équipe ;
• Faillite

Solutions

Technique

La solution technique miracle permettant de vous sortir du bourbier n’existe pas.

Ceux qui vous disent qu’il suffit de refaire le logiciel avec une autre
technologie / technique ont sûrement quelque chose à vous vendre ;-)

Infrastructure

Il faut absolument mettre en place une infrastructure pour chaque
développement quelle que soit la taille du projet.

• Un logiciel de suivi de bugs : comme Request Tracker, Trac, Mantis, etc…
• Un système de suivi de version tel que Subversion, Git ou Mercurial ;
• Un système de sauvegarde ;
• L’automatisation des tâches à l’aide d’un système de compilation automatique ;
• Des tests unitaires et fonctionnels automatisés ;

Refactorisation

La refactorisation est une forme de paiement des intérêts de la dette.
En effet, elle permet de faire une pause dans le développement et de “nettoyer” le code.

Méthodes de développements

Je ne vais pas lancer une querelle de clocher, je ne vais pas non plus vous dire que telle ou telle méthode de développement est la meilleure.

Il existe un bon nombre de méthodes de développement.

Chaque méthode présente ses avantages et ses inconvénients.

Par contre, une chose est sûre, les équipes de développement qui appliquent une méthode de développement rencontrent moins souvent ce type de problème.

Un peu de provocation

Je ne résiste pas ;-)
Est-ce que la dette technique est mauvaise dans tous les cas ?
Comme dans le cas d’une patate chaude cela dépend de qui paiera les intérêts.
Il est possible de faire un prêt ninja avec les intérêts de la dette.

Cela fonctionne dans le cas d’un marché ou “the-winner-takes-all”.
Par exemple, dans le cas d’une start-up innovante dont le seul but est de revendre le logiciel.

La dette technique permet de partir plus vite au soleil ;-)

Références

• La conférence d’Andy Lester au YAPC::NA 2006 : Get out of Technical Debt Now! ;
• Un commentaire sur LinuxFR d’un ancien développeur du site voyages-sncf.com ;