Si vous n'avez pas suivi le (micro-)feuilleton du moment sur Twitter, voici un résumé rapide.

Tout commence avec un tweet d'Emmanuel Lécharny :

Replacing a 5 lines method by a 140 lines one which is 15 times faster. Don't trust people who claim that less code is better.

La Javadoc officielle est très bien faite, mais la présentation des packages sous la forme d'une interminable liste alphabétique n'est pas très ergonomique. En pratique, on se sert surtout de java.lang, java.util et ses sous-packages, un peu de java.io... et rarement des autres. Alors pourquoi ne pas les mettre en avant ?

En attendant qu'Oracle se décide à intégrer des fonctions de recherche ou un système de favoris au doclet standard, j'ai fini par hacker manuellement la javadoc afin de faciliter l'accès aux packages qui m'intéressent.

Si ça marche, on n'y touche pas !

Sur les projets informatiques, la maintenance et la modernisation de l'existant sont rarement prioritaires par rapport à l'ajout de fonctionnalités. Au fil du temps, le code devient moins pertinent, moins performant, plus difficile à analyser et à maintenir.
La dette technique s'accumule progressivement et freine les nouveaux développements, allonge les délais de débogage, instille l'incertitude.

Arrive le moment où l'équipe grogne et parvient à décrocher un budget pour la réduction de la dette technique. Mais comment la mesurer ? Par quel bout commencer ? Comment optimiser le budget alloué ?

Voici une méthode simple et efficace qui devrait vous permettre de prendre conscience de l'état global du projet, et de faciliter l'identification et la priorisation des portions les plus atteintes par la dette technique.