Ward Cunningham, le père du wiki, résume ainsi la notion de dette technique :

  • Négliger la conception, c’est comme emprunter de l’argent.
  • Refactorer, c’est comme rembourser la dette principale.
  • Développer moins rapidement à cause de la complexité, c’est comme payer des intérêts.

Laisser s’accumuler la dette technique pour répondre rapidement à un besoin fonctionnel est une pratique assez courante dans le développement logiciel.

Malheureusement, la dette qui s’accumule épuise les ressources projets, et démotive les équipes. Lorsque la dette s’est effectivement accumulée, le travail d’un architecte est alors d’investir pour rembourser la dette principale (à plus ou moins long terme), et pour éviter que le système ne s’écroule sous la dette, et sous les intérêts.

C’est ce que nous avons eu l’opportunité de réaliser, en accompagnant un de nos clients sur une application existante.

Une application existante et une nouvelle fonction

Un client demande une nouvelle fonction, similaire à une fonction existante. Saisissant l’opportunité commerciale, et après s’être assuré des moyens nécessaires, les commerciaux répondent favorablement à la demande du client, et annoncent que la nouvelle fonction sera livrée à une échéance fixée.

En dehors de la deadline imposée, les contraintes à respecter sont :

  • L’ergonomie de la nouvelle fonction doit être identique à celle de la fonction existante.
  • Toute nouvelle fonctionnalité introduite dans la nouvelle fonction doit être également portée sur la fonction existante.

Il ne reste plus qu’à développer la nouvelle fonction dans le temps imparti.

Une application endettée techniquement

Après une étude technique de la solution existante, le constat est le suivant :

  • La solution existante est développée dans une technologie en voie d’obsolescence. Les technologies utilisées sont Struts, Tiles, JSP, JDBC, et des procédures stockées. L’application a également recours à des bibliothèques et des frameworks maisons.
  • La solution existante est difficile à maintenir, essentiellement en raison d’une conception amplement perfectible.

Le développement de l’application est réalisé en offshore, et revu plus tard par l’équipe interne pour des ajouts de fonctionnalités. Cette approche rend plus difficile encore la maintenance.

Il a été tenté d’introduire par deux fois la nouvelle fonction. Mais, les tentatives ont été avortées. En effet, elles ne parvenaient pas à respecter les contraintes projets : coûts trop élevés, fonctionnalités ne correspondant pas aux besoins, etc.

Comment s’y prendre ?

Devons-nous nous engager dans une troisième tentative en gardant le même socle technique et les mêmes pratiques ? Ou bien, devons-nous repartir sur des bases nouvelles ? Si nous optons pour la deuxième solution, quoique tentante, comment s’assurer de la compatibilité des deux fonctions ? Comment s’assurer que les développeurs ont la compétence pour réaliser et maintenir l’application ?

L’approche retenue consiste à investir dans la méthode, les outils et la formation, afin de ne pas subir la dette technique accumulée. Pour redonner confiance à l’équipe projet, nous adoptons une méthodologie agile. La méthode en cascade est habituellement la méthodologie de l’entreprise. Ainsi, nous construisons une étroite collaboration entre les experts métiers et les développeurs, pendant tout le cycle de vie du projet.

Le projet est découpé en plusieurs lots :

  • Investissement (lot 1)
    • Mettre en place l’environnement
    • Implémenter la nouvelle fonction avec le nouveau socle technique, en se limitant aux fonctionnalités de l’ancienne fonction
  • Remboursement de la dette principale (lot 2)
    • Porter l’ancienne fonction sur le nouveau socle
  • Retour sur investissement (lot 3)
    • Rajouter des nouvelles fonctionnalités sur les deux fonctions
    • Livrer le produit

Sur le plan de l’outillage, nous mettons en place un système d’intégration continue et une plateforme virtuelle d’intégration et de tests. Par ailleurs, nous définissons un socle technique en intégrant des frameworks et outils open source.

Une plateforme d’intégration continue

Inexistante jusqu’alors, la plateforme d’intégration continue permet d’automatiser la compilation et l’exécution des tests pour signaler au plus tôt les anomalies. Les technologies retenues sont :

  • Bamboo, comme serveur d’intégration continue,
  • JIRA, comme système de suivi des bugs, utilisé avec Mylyn, un plug-in Eclipse,
  • Subversion, comme gestionnaire de code source,
  • et Ivy, comme gestionnaire de dépendances.

Une plateforme virtualisée d’intégration et de test

Les tests d’intégration se font en environnement de développement, sur une architecture technique incompatible avec la plateforme de production. Une plateforme de pré-production existe bien. Elle est cependant rarement disponible, car réservée à la qualification fonctionnelle.

Nous mettons alors en place une plateforme d’intégration et de test, virtualisée à l’aide de VMWare ESX. Cette nouvelle plateforme permet de tester l’application dans des conditions très proches de la production, ceci à tout moment, et en totale isolation.

En bonus, la mise en place de la plateforme virtualisée permet de monter en compétence les développeurs sur l’infrastructure de production, comprenant notamment divers firewalls et load-balancers.

Nouveau socle technique

La mise en place d’un nouveau socle technique s’accompagne du coaching des développeurs, et de la mise en place d’un wiki, afin partager les bonnes pratiques.

Les principales technologies retenues sont :

  • les frameworks Spring et Spring Web MVC,
  • la bibliothèque de mapping objet / relationnel iBATIS,
  • le framework de tests unitaire JUnit,
  • la bibliothèque mock EasyMock.

Un ensemble d’outils complète le tableau :

  • mesure de métriques logicielles avec Checkstyle et FindBugs notamment,
  • couverture de code avec Clover.

Au final…

Au final, nous livrons dans les temps, et conformément aux attentes clients.

Ajourd’hui, l’investissement porte ses fruits bien au-delà du projet :

  • La méthodologie agile fait partie des standards de l’entreprise. La méthodologie historique subsiste, selon les spécificités du projet.
  • Initialement limité à un projet, le référentiel de composants, basé sur Ivy, devient un référentiel d’entreprise, contenant différents composants communs développés en interne. Il gère les dépendances entre composants, y compris pour les composants externes.
  • La plateforme d’intégration continue et la plateforme virtualisée sont maintenant utilisées par plusieurs autres projets. La mise en place d’autres plateformes similaires est en cours d’étude.