{"id":2093,"date":"2014-10-07T09:20:39","date_gmt":"2014-10-07T08:20:39","guid":{"rendered":"http:\/\/qualilogy.com\/fr\/?p=2093"},"modified":"2014-10-17T11:55:12","modified_gmt":"2014-10-17T10:55:12","slug":"application-legacy-refactoring-plugin-sqale-1","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/application-legacy-refactoring-plugin-sqale-1\/","title":{"rendered":"Application Legacy – Refactoring avec le plugin SQALE (I)"},"content":{"rendered":"

\"Application<\/a>Afin de proc\u00e9der \u00e0 une estimation du co\u00fbt de refactoring de notre application Legacy, je vais utiliser le plugin SQALE de SonarQube, employ\u00e9 habituellement pour mesurer la Dette Technique.<\/p>\n

Nous avons d\u00e9j\u00e0 pr\u00e9sent\u00e9<\/a> ce plugin avec une application Legacy PL\/SQL. Rappelons donc simplement que le plugin SQALE est bas\u00e9 sur le mod\u00e8le SQALE de la qualit\u00e9<\/a>, et j\u2019ajouterai \u00e9galement, sur une m\u00e9thode permettant d\u2019adapter le mod\u00e8le en l\u2019alignant avec les diff\u00e9rents objectifs m\u00e9tiers, la technologie utilis\u00e9e pour l\u2019application, ou le contexte applicatif. <\/p>\n

SQALE et les applications Legacy<\/h2>\n

Aujourd\u2019hui, toute application de plus de 3 ans est consid\u00e9r\u00e9e comme \u2018Legacy\u2019, surtout si elle ne dispose pas d\u2019une couverture de tests unitaires. Dans ce cas, \u2018Edit and Pray\u2019<\/a> ou encore \u2018Modifie \u00e0 tes risques\u2019, comme l\u2019explique Michael Feathers dans son livre \u00ab Working Effectively with Legacy Code \u00bb.<\/p>\n

Or, on comprend bien que nous n\u2019allons pas utiliser le mod\u00e8le SQALE de la m\u00eame mani\u00e8re pour une application J2EE de 3 ans, notre application World 1.1a en C d\u2019il ya 20 ans, ou une application Cobol encore plus ancienne, et\/ou qui est pass\u00e9e entre les mains de plusieurs \u00e9quipes diff\u00e9rentes, \u00e9ventuellement en offshore.<\/p>\n

Il faut \u00e9galement prendre en compte le type d\u2019application : ici nous avons un logiciel bureautique vendu par un \u00e9diteur de software, ce n\u2019est pas du tout la m\u00eame chose qu\u2019une application J2EE d\u00e9velopp\u00e9e en interne pour r\u00e9pondre \u00e0 des besoins m\u00e9tier, ou une application bas\u00e9e sur un progiciel comme SAP. Par exemple, notre application est \u00e9crite en C et n\u2019utilise pas de bases de donn\u00e9es : les facteurs \u2018performance\u2019 et \u2018s\u00e9curit\u00e9\u2019 n\u2019auront pas du tout le m\u00eame poids que pour une application de gestion classique.<\/p>\n

SQALE et le suivi de la dette technique<\/h2>\n

Autre \u00e9l\u00e9ment \u00e0 prendre en compte : comme l\u2019explique Freddy Mallet de SonarQube dans cette vid\u00e9o<\/a> (en fran\u00e7ais) : \u00ab la dette technique,\u00a0 c\u2019est pour \u00e9viter de se r\u00e9veiller au bout de 5 ans avec un code avec lequel on ne peut plus rien faire sans que cela co\u00fbte un bras \u00bb. Ou encore, comme expliqu\u00e9 dans cet article<\/a> : \u00ab inutile de commencer \u00e0 \u00e9ponger le sol tant que vous n\u2019avez pas r\u00e9par\u00e9 la fuite d\u2019eau \u00bb.<\/p>\n

Une des principales utilisations du plugin SQALE consiste \u00e0 suivre et contr\u00f4ler la dette technique au fil des versions, afin d\u2019\u00e9viter qu\u2019elle ne s\u2019accroisse au-del\u00e0 d\u2019un seuil o\u00f9 elle commence \u00e0 devenir insupportable et trop co\u00fbteuse.<\/p>\n

Dans notre cas, nous n\u2019avons qu\u2019une seule et unique version, donc je vais \u00e0 nouveau signaler que notre utilisation du plugin SQALE est particuli\u00e8re \u00e0 notre objectif d\u2019\u00e9valuation d\u2019un effort de refactoring, sans que nous ayons personnalis\u00e9 le mod\u00e8le, et en proc\u00e9dant directement \u00e0 partir des r\u00e9sultats \u2018out of the box\u2019.<\/p>\n

Dans le cadre de cet article, je pr\u00e9sente ces r\u00e9sultats simplement afin d’illustrer la d\u00e9marche pour estimer le co\u00fbt de refactoring d\u2019une application Legacy. Estimation \u2018a priori\u2019, avant m\u00eame d’aller consulter l’\u00e9quipe de projet ou le management, mais avec quelques pistes pr\u00e9alables pour ce faire.<\/p>\n

SQALE dans le dashboard SonarQube<\/h2>\n

Je me suis constitu\u00e9 mon propre dashboard dans SonarQube, avec un widget pour afficher les donn\u00e9es suivantes du plugin SQALE :<\/p>\n

Figure 1 \u2013 Donn\u00e9es SQALE sur la Dette Technique de notre application Legacy<\/em><\/strong><\/p>\n

\"Donn\u00e9es<\/a><\/p>\n

1 238.7 jours pour r\u00e9sorber la dette technique. A raison de 18.5 jours travaill\u00e9s par mois<\/a>, cela repr\u00e9sente 69.4 mois ou, pour une \u00e9quipe de 5 personnes, 13.9 mois\/hommes.<\/p>\n

Donc il faut pratiquement 14 mois \u00e0 notre \u00e9quipe de projet pour venir \u00e0 bout de cette dette technique. Inutile d\u2019imaginer que ce soit acceptable pour le management : cela signifie stopper toute \u00e9volution, interdire toute nouvelle version pendant plus d\u2019un an. Aucun client, aucun utilisateur ne consentirait \u00e0 une telle d\u00e9cision.<\/p>\n

Cela dit, notre objectif n\u2019est pas de supprimer 100% de cette dette, mais de fournir un effort de r\u00e9duction de celle-ci afin que le poids de la dette soit acceptable, et que la r\u00e9duction correspondante des co\u00fbts de maintenance soit sup\u00e9rieure au co\u00fbt de refactoring. En effet, la d\u00e9cision d\u2019effectuer ou non un refactoring se base habituellement sur un ROI, une esp\u00e9rance de gain ou en l\u2019esp\u00e8ce, de r\u00e9duction de co\u00fbts de maintenabilit\u00e9.<\/p>\n

Est-il possible d\u2019envisager un effort raisonnable, avec des actions de refactoring limit\u00e9es mais pr\u00e9cises, pour un retour sur investissement optimal ? C\u2019est ce que je vais regarder avec les autre donn\u00e9es configur\u00e9es dans mon widget.<\/p>\n

Tout d\u2019abord, je vois que le \u2018SQALE Rating\u2019 est \u00e9gal \u00e0 B. Celui-ci montre le poids de la dette technique par rapport \u00e0 l\u2019ensemble de l\u2019application. Un autre widget SQALE du portail de SonarQube me donne la distribution de la dette technique sur les diff\u00e9rents fichiers.<\/p>\n

Figure 2 \u2013 Distribution du SQALE Rating par fichier<\/em><\/strong><\/p>\n

\"Distribution<\/a><\/p>\n

Nous avons 12 fichiers avec une dette technique tr\u00e8s importante, et si je liste ces fichiers, je vais retrouver certains programmes d\u00e9j\u00e0 identifi\u00e9s auparavant<\/a> comme les plus complexes, les plus volumineux en nombre de lignes de code (LOC) et\/ou avec des fonctions elles-m\u00eames tr\u00e8s complexes et de grande taille.<\/p>\n

Figure 3 \u2013 Highest SQALE remediation costs<\/em><\/strong><\/p>\n

\"Highest<\/a><\/p>\n

Autre mani\u00e8re de v\u00e9rifier la distribution de la dette technique sur l\u2019ensemble des fichiers de l\u2019application : le Bubble Chart. J\u2019ai la possibilit\u00e9 de choisir quelles m\u00e9triques je souhaite croiser :<\/p>\n