Afin de procéder à une estimation du coût de refactoring de notre application Legacy, je vais utiliser le plugin SQALE de SonarQube, employé habituellement pour mesurer la Dette Technique.
Nous avons déjà présenté ce plugin avec une application Legacy PL/SQL. Rappelons donc simplement que le plugin SQALE est basé sur le modèle SQALE de la qualité, et j’ajouterai également, sur une méthode permettant d’adapter le modèle en l’alignant avec les différents objectifs métiers, la technologie utilisée pour l’application, ou le contexte applicatif.
SQALE et les applications Legacy
Aujourd’hui, toute application de plus de 3 ans est considérée comme ‘Legacy’, surtout si elle ne dispose pas d’une couverture de tests unitaires. Dans ce cas, ‘Edit and Pray’ ou encore ‘Modifie à tes risques’, comme l’explique Michael Feathers dans son livre « Working Effectively with Legacy Code ».
Or, on comprend bien que nous n’allons pas utiliser le modèle SQALE de la même manière pour une application J2EE de 3 ans, notre application World 1.1a en C d’il ya 20 ans, ou une application Cobol encore plus ancienne, et/ou qui est passée entre les mains de plusieurs équipes différentes, éventuellement en offshore.
Il faut également prendre en compte le type d’application : ici nous avons un logiciel bureautique vendu par un éditeur de software, ce n’est pas du tout la même chose qu’une application J2EE développée en interne pour répondre à des besoins métier, ou une application basée sur un progiciel comme SAP. Par exemple, notre application est écrite en C et n’utilise pas de bases de données : les facteurs ‘performance’ et ‘sécurité’ n’auront pas du tout le même poids que pour une application de gestion classique.
SQALE et le suivi de la dette technique
Autre élément à prendre en compte : comme l’explique Freddy Mallet de SonarQube dans cette vidéo (en français) : « la dette technique, c’est pour éviter de se réveiller au bout de 5 ans avec un code avec lequel on ne peut plus rien faire sans que cela coûte un bras ». Ou encore, comme expliqué dans cet article : « inutile de commencer à éponger le sol tant que vous n’avez pas réparé la fuite d’eau ».
Une des principales utilisations du plugin SQALE consiste à suivre et contrôler la dette technique au fil des versions, afin d’éviter qu’elle ne s’accroisse au-delà d’un seuil où elle commence à devenir insupportable et trop coûteuse.
Dans notre cas, nous n’avons qu’une seule et unique version, donc je vais à nouveau signaler que notre utilisation du plugin SQALE est particulière à notre objectif d’évaluation d’un effort de refactoring, sans que nous ayons personnalisé le modèle, et en procédant directement à partir des résultats ‘out of the box’.
Dans le cadre de cet article, je présente ces résultats simplement afin d’illustrer la démarche pour estimer le coût de refactoring d’une application Legacy. Estimation ‘a priori’, avant même d’aller consulter l’équipe de projet ou le management, mais avec quelques pistes préalables pour ce faire.
SQALE dans le dashboard SonarQube
Je me suis constitué mon propre dashboard dans SonarQube, avec un widget pour afficher les données suivantes du plugin SQALE :
Figure 1 – Données SQALE sur la Dette Technique de notre application Legacy
1 238.7 jours pour résorber la dette technique. A raison de 18.5 jours travaillés par mois, cela représente 69.4 mois ou, pour une équipe de 5 personnes, 13.9 mois/hommes.
Donc il faut pratiquement 14 mois à notre équipe de projet pour venir à bout de cette dette technique. Inutile d’imaginer que ce soit acceptable pour le management : cela signifie stopper toute évolution, interdire toute nouvelle version pendant plus d’un an. Aucun client, aucun utilisateur ne consentirait à une telle décision.
Cela dit, notre objectif n’est pas de supprimer 100% de cette dette, mais de fournir un effort de réduction de celle-ci afin que le poids de la dette soit acceptable, et que la réduction correspondante des coûts de maintenance soit supérieure au coût de refactoring. En effet, la décision d’effectuer ou non un refactoring se base habituellement sur un ROI, une espérance de gain ou en l’espèce, de réduction de coûts de maintenabilité.
Est-il possible d’envisager un effort raisonnable, avec des actions de refactoring limitées mais précises, pour un retour sur investissement optimal ? C’est ce que je vais regarder avec les autre données configurées dans mon widget.
Tout d’abord, je vois que le ‘SQALE Rating’ est égal à B. Celui-ci montre le poids de la dette technique par rapport à l’ensemble de l’application. Un autre widget SQALE du portail de SonarQube me donne la distribution de la dette technique sur les différents fichiers.
Figure 2 – Distribution du SQALE Rating par fichier
Nous avons 12 fichiers avec une dette technique très importante, et si je liste ces fichiers, je vais retrouver certains programmes déjà identifiés auparavant comme les plus complexes, les plus volumineux en nombre de lignes de code (LOC) et/ou avec des fonctions elles-mêmes très complexes et de grande taille.
Figure 3 – Highest SQALE remediation costs
Autre manière de vérifier la distribution de la dette technique sur l’ensemble des fichiers de l’application : le Bubble Chart. J’ai la possibilité de choisir quelles métriques je souhaite croiser :
- la dette technique en nombre de jours sur l’axe Y (ordonnées) ;
- le nombre de lignes de code pour l’axe X (abcisse) ;
- la Complexité Cyclomatique pour la taille de la bulle.
Figure 4 – Technical Debt x Cyclomatic Complexity x Lines of Code
On peut voir sur cette figure, le fichier ‘fltexp.c’ avec la dette technique maximale pour un programme – 23 jours de refactoring – répartie sur 2 600 lignes de code et 740 points de Complexité Cyclomatique.
Certains vont encore me dire que le nombre de lignes de code (LOC) n’est pas une mesure fiable de la taille d’une application, mais après avoir joué avec différentes combinaisons de métriques, celle-ci reste encore la plus corrélée avec la dette technique, et donc un facteur à prendre en compte pour comprendre cette dernière.
Par exemple, dans le Bubble Chart suivant, j’ai choisi la Complexité Cyclomatique (CC) par fonction comme mesure de la taille de la bulle.
Figure 5 – Technical Debt x Cyclomatic Complexity/Function x Lines of Code 
Le fichier ‘RTFOUT.C’ dont nous avons tant parlé précédemment, possède la fonction la plus complexe avec 355 points de CC, mais compte également une autre fonction avec seulement 2 points de CC. La complexité moyenne pour ce fichier sera donc de (355 + 2) / 2 = 178.5 points de CC, comme affiché au-dessus du graphique.
J’ai également affiché (copié-collé) dans cette figure les mesures pour le fichier ‘fltexp.c’ dont nous avons vu précédemment (figure 3 antérieure) qu’il possédait la dette technique la plus élevée et 740 points de CC, mais répartis sur un plus grand nombre de fonctions, puisque la CC moyenne par fonction est d’environ 16 points.
Même s’il est intéressant, je pense que ce graphique reste moins utile que le précédent, plus significatif et représentatif de l’effort de refactoring à consentir sur chaque programme et sur l’ensemble de l’application. Mais nous pouvons voir que nous disposons dans SonarQube de nombre d’outils et de widgets afin d’imaginer et investiguer différentes pistes d’action.
Avec ces différents widgets du portail SonarQube, je connais :
- Les fichiers qui présentent la dette technique la plus élevée : sans aucune surprise, les fichiers les plus lourds et les plus complexes de notre application, tels que nous les avions identifiés auparavant.
- L’effort de refactoring afin de supprimer la dette technique pour chacun de ces fichiers.
Mais encore, une fois, cet effort est trop important pour être envisagé tel quel, et pas forcément nécessaire puisque nous ne souhaitons pas la suppression totale de la dette technique, sinon un refactoring basé sur des actions avec un coût de réduction de la dette le plus bas possible, pour un maximum d’avantages.
Notre prochaine post sera consacré à la présentation des ces différentes actions et une estimation de leur coût.
A très bientôt.
Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.