{"id":1651,"date":"2014-02-23T16:12:48","date_gmt":"2014-02-23T15:12:48","guid":{"rendered":"http:\/\/qualilogy.com\/fr\/?p=1651"},"modified":"2014-02-27T18:05:00","modified_gmt":"2014-02-27T17:05:00","slug":"analyse-plsql-avec-sonarqube-evaluer-la-qualite-2","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/analyse-plsql-avec-sonarqube-evaluer-la-qualite-2\/","title":{"rendered":"Analyse PL\/SQL avec SonarQube \u2013 Evaluer la qualit\u00e9 (2\/3)"},"content":{"rendered":"

\"PLSQLEva2\"<\/a>D\u00e9sol\u00e9 de vous avoir fait attendre pour la suite de cette s\u00e9rie sur le code PL\/SQL et SonarQube, mais j’ai \u00e9t\u00e9 pas mal occup\u00e9, entre voyages, travail et mon portable qui m’a l\u00e2chement abandonn\u00e9, en invoquant bien \u00e9videmment la loi de Murphy pour justifier de tomber en panne au pire moment.<\/p>\n

Rappel sur les posts pr\u00e9c\u00e9dents : apr\u00e8s avoir configur\u00e9 une analyse de code PL\/SQL avec SonarQube<\/a>, nous avons constitu\u00e9 notre propre Quality Profile<\/a> en orientant les r\u00e8gles Blockers<\/a> et Criticals<\/a> sur la robustesse, la performance et la s\u00e9curit\u00e9. A quoi ressemble maintenant notre tableau de bord ? <\/p>\n

Nous avons d\u2019abord examin\u00e9 dans le post pr\u00e9c\u00e9dent les m\u00e9triques de taille<\/a> pour constater que le nombre moyen de lignes de codes par objet (proc\u00e9dure, fonction, trigger, etc.) \u00e9tait correct.<\/p>\n

Gr\u00e2ce au nouveau widget File Bubble Chart nous avons d\u00e9couvert qu\u2019un fichier unique \u2018CreatePackageBody.sql\u2019 de plus de 58 000 lignes, embarquait toute la logique m\u00e9tier au niveau de la base de donn\u00e9es, ce qui va tr\u00e8s certainement entra\u00eener un co\u00fbt de maintenance \u00e9lev\u00e9 pour cette application.<\/p>\n

Complexit\u00e9 et duplications<\/h2>\n

Complexit\u00e9<\/h3>\n

\"PLSQL_Complexity\"<\/a> Un coup d\u2019\u0153il sur la Complexit\u00e9 Cyclomatique (CC) aboutit \u00e0 des r\u00e9sultats semblables : la complexit\u00e9 moyenne par objet est relativement basse avec 6.9 points de CC, et un maximum de 12 points. Par contre, la complexit\u00e9 par fichier d\u00e9passe les 600 points, et nous avons un total d\u2019un peu plus de 10 000 points de CC dans toute l\u2019application, ce qui est assez peu.<\/p>\n

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

L\u2019effort de tests pour celle-ci n\u2019est donc pas tr\u00e8s \u00e9lev\u00e9. Rappelons que la Complexit\u00e9 Cyclomatique est une mesure du nombre de \u2018chemins\u2019 diff\u00e9rents dans une application. Id\u00e9alement, tous ses chemins doivent \u00eatre test\u00e9s, donc la CC nous donne une id\u00e9e de l\u2019effort de tests.<\/p>\n

On consid\u00e8re qu\u2019\u00e0 partir de 20 000 points pour une application, il est n\u00e9cessaire d\u2019effectuer une \u00e9tape sp\u00e9cifique de QA et de r\u00e9diger des cahiers de test, et si possible d\u2019automatiser ceux-ci avec un outil sp\u00e9cifique. Dans notre cas, nous pouvons laisser l\u2019\u00e9quipe de projet r\u00e9aliser ces tests en interne.
\nMais comme on peut le voir avec le Treemap ci-dessous, que j\u2019ai configur\u00e9 pour afficher la Complexit\u00e9 Cyclomatique \u2026<\/p>\n

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

Notre fichier \u2018CreatePackageBody.sql\u2019 embarque 90% de la complexit\u00e9 et donc de la logique de l\u2019application. Donc encore une fois, nous avons des chiffres qui sont corrects au niveau d\u2019une application \u2026 sauf qu\u2019ici l\u2019application tient pratiquement dans un seul fichier monstrueux.<\/p>\n

Duplications<\/h3>\n

\"PLSQL_Duplications\"<\/a>Apr\u00e8s la complexit\u00e9, je vais regarder le niveau de duplication, assez \u00e9lev\u00e9. Pas de surprise, le m\u00eame fichier monstre qui impl\u00e9mente la logique applicative est l\u00e0 encore en t\u00eate.<\/p>\n

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

Cependant, nous rencontrons un nombre \u00e9lev\u00e9 de Copier\/Coller dans les autres fichiers, et en particulier le fichier \u2018Create_Tables.sql\u2019. Puisque ce script se charge de cr\u00e9er les tables de la base de donn\u00e9es, cela signifie que nous avons nombre de structures de donn\u00e9es qui sont dupliqu\u00e9es.<\/p>\n

Ce qui pourrait indiquer que le mod\u00e8le de donn\u00e9es n\u2019est pas optimis\u00e9. Cela arrive pour une application ancienne, car il est plus facile d\u2019ajouter de nouvelles tables que de faire \u00e9voluer celles existantes. Mais plus de tables signifie plus de jointures, donc une moindre performance et plus de complexit\u00e9 pour maintenir ces structures de donn\u00e9es.<\/p>\n

Dans le cadre d\u2019un v\u00e9ritable audit de la qualit\u00e9 de cette application, je prendrais le temps de me plonger dans ce script de cr\u00e9ation de tables afin de v\u00e9rifier cette hypoth\u00e8se, et trouver quelques exemples qui puissent supporter une recommandation de refactoring de la base de donn\u00e9es.
\nPar exemple, je compte 687 \u2018CREATE TABLE\u2019 dans ce fichier, donc 687 tables en tout (sans compter les vues). 8 963 lignes dupliqu\u00e9es dans ce script signifie en moyenne 13 lignes, donc 13 champs semblables par table. Il est logique d\u2019avoir quelques champs \u2018cl\u00e9s\u2019 r\u00e9p\u00e9t\u00e9s pour pouvoir effectuer des jointures, mais peut-\u00eatre pas \u00e0 ce point l\u00e0.<\/p>\n

Composants \u00e0 risque<\/h2>\n

Apr\u00e8s avoir regard\u00e9 les m\u00e9triques quantitatives, nous avons d\u00e9j\u00e0 pas mal d\u2019informations concernant cette application, certainement plus d’ailleurs que n\u2019en connaissent habituellement les responsables de celle-ci, pour ne pas parler des stakeholders ou responsables informatiques.<\/p>\n

La seconde partie d\u2019une \u00e9valuation de la qualit\u00e9 consiste \u00e0 identifier les principales menaces, et cela passe par le recensement des composants les plus risqu\u00e9s. Nous avons vu, dans les posts pr\u00e9c\u00e9dents :<\/p>\n