Dernier post de notre série sur l’analyse de la qualité du code PL/SQL avec SonarQube.
Evaluer la qualité d’une application ne consiste pas uniquement en l’analyse du code : cela, n’importe qui peut le faire. Le travail du consultant Qualité s’articule autour des questions suivantes : quoi, pourquoi, comment, combien.
- Quoi : analyser les résultats. Taille et complexité du code, duplications, c’est ce que nous avons vu dans les posts précédents. On examinera les chiffres globaux mais aussi les moyennes, ainsi que les tendances dans le temps si l’on dispose de plusieurs versions. Puis on regarde les principales violations aux bonnes pratiques, en s’intéressant en priorité aux Blockers et Criticals.
- Pourquoi ces résultats : rechercher les causes des mesures analysées, investiguer l’origine des résultats rencontrés.
- Comment remédier : proposer un plan d’action. En fait, réaliser plusieurs propositions de plan d’action. Nous verrons ci-dessous que je décline ceux-ci en différents plans à court, moyen et long terme.
- Combien cela coûte : évaluation du coût de chaque plan.
Par exemple :
- Quoi : nous constatons un défaut, critique pour la sécurité.
- Pourquoi : il est probable qu’une ou plusieurs personnes dans l’équipe de projet ne connaisse pas cette règle. Ou au contraire, la bonne pratique correspondante est connue, mais une erreur d’inattention est toujours possible.
- Comment : la remédiation peut consister en une simple correction du défaut dans le code ou une action de formation sur la bonne pratique.
- Combien : c’est là où le plugin SQALE nous sera utile.
Je ne vais pas vous présenter en détail la méthode SQUALE et le plugin SQALE de SonarQube. Peut-être aurons-nous l’occasion de le faire dans un futur post, mais il existe déjà suffisamment d’informations sur le sujet. Je vous conseille notamment :
Pour nos calculs, nous allons considérer que l’équipe de projet pour maintenir ce code SQL est composée de 3 personnes. En général, une application Legacy de ce type n’est pas modifiée très fréquemment, donc nous allons considérer que cette équipe produit 4 versions par an.
Rappelons qu’une année homme est égale à 52 semaines, moins les congés et autres jours fériés (ou autres absences maladie), soit 45 semaines ou 225 jours (en France). Ce chiffre peut varier selon les pays, mais pas tant que cela.
La dette technique en PL/SQL
Plan court terme – Supprimer les menaces
Le plus important et prioritaire consiste à supprimer tout ce qui constitue une menace pour l’utilisateur final, le plus rapidement et le plus tôt possible. C’est le plan minimal, indispensable, à court terme donc.
Nous avons orienté notre Quality Profile vers les violations en matière de Sécurité, de Robustesse et de Performance, qui impactent l’utilisateur. Les défauts Blockers et Criticals constituent bien évidemment les menaces les plus sérieuses.
Le plugin SQALE nous permet de vérifier le coût de remédiation pour ceux-ci : environ 113 jours.
Le plan à court terme consiste donc en un chantier de refactoring de 6 mois hommes, ou 2 mois pour notre équipe de projet de 3 personnes.
Quand : le plus tôt possible, pour la prochaine version dans 3 mois. Il est tout à fait acceptable de proposer aux stakholders de reporter les évolutions non indispensables sur la version suivante, de telle sorte que l’équipe de projet effectue d’abord les 2 mois de refactoring, puis travaille le mois suivant sur les fonctionnalités les plus essentielles. Si ces dernières sont trop nombreuses, il est possible de jouer avec le calendrier en décalant la prochaine version à 4 mois. Ou de faire une version ‘refactorisée’ à 2 mois et la prochaine dans les 4 mois suivants.
Bénéfices : une application plus sûre, plus robuste et plus performante, grâce à la suppression des menaces les plus urgentes et les plus graves.
Plan moyen terme – Aligner la dette technique avec les objectifs IT
Il ne faut jamais oublier que la stratégie IT, et donc la gestion du portefeuille d’applications, est toujours alignée sur la stratégie de l’entreprise. Un marché est soit :
- Mature, avec une stratégie de préservation des parts de marché et des marges financières, donc le respect des budgets et des coûts sera un objectif majeur de la stratégie IT. Au niveau de l’équipe de projet, cela se traduit par : priorité à la maintenabilité et l’évolutivité de l’application. Ne pas laisser dériver la dette technique sur ces 2 facteurs.
- Nouveau, avec une stratégie de gains de part de marché, un time-to-market important, des applications robustes et performantes : c’est l’orientation que nous avons donné à notre Quality Profile et notre analyse de la qualité de cette application.
Notre plan à moyen terme visera donc à corriger tous les défauts impactant la sécurité, la performance et la fiabilité, et non pas simplement les Blockers et Critical. La pyramide SQALE nous permet de calculer le coût de ce plan à moyen terme.
Un total de 395.6 jours. A 3 personnes, cela représente un chantier de 7 mois au complet. Difficile de paralyser le projet durant plus de la moitié de l’année.
Cependant, ces 395 jours incluent les 113 précédents (du plan à court terme), donc il s’agit en fait de 282 jours additionnels, ou encore 15 mois d’une personne ou 5 mois pour chacune des 3 personnes de l’équipe de projet. Différentes suggestions viennent alors à l’esprit :
- Limiter le nombre de fonctionnalités nouvelles sur les 5 prochaines versions afin de libérer 1 mois par version pour chaque membre de l’équipe afin qu’il se consacre à ces remédiations. Envisageable si cette application n’évolue plus énorrmément et que les utilisateurs demandent effectivement des améliorations en matière de robustesse et de performance, par exemple.
- Si nombre de fonctionnalités nouvelles sont critiques et que la charge d’évolution ne peut être réduite, alors les stakeholders doivent être prêts à payer pour ajouter une 4ème personne à l’équipe de projet, qui se consacrera uniquement à corriger ces défauts au cours des 5 prochaines versions.
Comme on peut le voir, ce plan est à moyen terme, à l’horizon des 18 prochains mois en incluant le plan à court terme, mais il est possible d’affiner pour présenter différentes variantes, plus acceptables pour les stakeholders et le Directeur Informatique soucieux de son budget. Là encore, le plugin SQALE nous permet d’aller à l’essentiel.
Par exemple, le SQALE Sunburst suivant nous montre que, en matière de Performance (Efficiency), 104 jours sont nécessaire pour corriger les violations à une règle concernant les types de données.
Il me semble que c’est avec la version Oracle 11g qu’un nouveau type de données a permis d’améliorer jusqu’à 50% la performance de certaines procédures stockées. Si les temps de réponse de l’application ne sont pas un problème majeur pour les utilisateurs, alors nous pouvons reporter la remédiation de cette règle Major dans un plan à plus long terme, et gagner ainsi 104 jours, soit 21 semaines, soit environ 7 semaines par membre de l’équipe de projet. Bien sûr, il ne s’agit pas de réduire le plan à moyen terme en un plan à court terme, mais de se concentrer sur l’essentiel, avec l’aide de ce graphique qui nous montre la répartition de la dette technique sur les différents types de risques applicatifs.
Plan long terme – Aligner la dette technique avec la stratégie applicative
Le plan à long terme doit adresser une question évidente : que faire de ce composant monstrueux qui embarque toute la logique applicative de l’application ? Le plugin SQALE nous montre que la dette technique pour ce seul composant est de 1 431.9 jours, soit 75% de la dette technique totale pour cette application (plus de 6 années-hommes).
En fait, la question qui se pose devient dés lors : que faire de cette application ? Tout va dépendre de son niveau de criticité.
Si une application avec une dette technique très élevée n’est pas critique, la solution est simple : vous la jetez. La maintenir va coûter plus cher que la remplacer, soit par un progiciel, soit par une nouvelle application développée dans une technologie plus récente. Comme l’application n’est pas critique, il n’est pas indispensable que vous en conserviez la maîtrise ou la connaissance, donc vous pouvez soit externaliser ce développement auprès d’un outsourceur, soit effectuer un appel d’offres pour mettre en concurrence éditeur de logiciels ou intégrateurs compétents sur un progiciel du même type. Dans tous les cas, le partenaire que vous aurez choisi pourra assurer la maintenance de la solution, avec des coûts normalement moindres que si vous effectuez vous-mêmes la maintenance – mais aussi avec la complexité supplémentaire de gérer un fournisseur externe.
Si l’application est critique, alors vous devez gérer le problème vous-mêmes puisque vous ne souhaitez pas abandonner à un tiers la gestion du risque ‘business’ que cette application peut représenter pour votre entreprise. Il n’existe alors que deux possibilités : un refactoring de l’application ou la réécriture complète de celle-ci.
En l’espèce, corriger tous les défauts rencontrés dans ce composant monstrueux et laisser celui-ci tel quel n’a pas beaucoup de sens. Le refactoring doit porter prioritairement sur un nouveau design de cette application, ce qui favorise en fait la solution de porter celle-ci vers une nouvelle technologie.
Nous avons vu que cette base de données comportait 687 tables, sans compter les vues, mais avec une duplication importante de structures de données. Ma recommandation pour un plan à long terme sera donc :
- D’effectuer une rétro-documentation afin de lister les différents composants présents dans cette application et les liens entre ceux-ci.
- D’effectuer un re-design conceptuel afin de dresser la carte des objets fonctionnels, d’abord à périmètre égal, puis en prenant en compte les évolutions fonctionnelles souhaitées par les utilisateurs.
Il est possible d’externaliser ce travail vers un prestataire, notamment si l’équipe de projet actuel a connu un turnover important durant la vie de cette application et a quelque peu perdu la connaissance de celle-ci.
Il faut néanmoins que ce prestataire soit outillé pour ce faire : même avec « seulement » 150 000 lignes de code et de commentaires, ce travail doit être automatisé à l’aide d’un outil de cartographie applicative qui permette de tracer l’ensemble des composants et leurs liens.
Cela tombe bien : SonarSource a justement dans ses cartons un projet pour un tel outil. Notre application PL/SQL sera donc une bonne candidate pour un test de cette future production SonarSource.