{"id":1615,"date":"2014-01-28T11:13:47","date_gmt":"2014-01-28T10:13:47","guid":{"rendered":"http:\/\/qualilogy.com\/fr\/?p=1615"},"modified":"2014-02-23T16:05:55","modified_gmt":"2014-02-23T15:05:55","slug":"analyse-plsql-avec-sonarqube-evaluer-la-qualite-1","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/analyse-plsql-avec-sonarqube-evaluer-la-qualite-1\/","title":{"rendered":"Analyse PL\/SQL avec SonarQube &#8211; Evaluer la qualit\u00e9 (1\/3)"},"content":{"rendered":"<p><a href=\"http:\/\/500px.com\/Vicken\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-1626\" alt=\"PLSQL_EvaluationQualit\u00e91\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/01\/PLSQL_EvaluationQualit\u00e91.jpg\" width=\"370\" height=\"264\" srcset=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/01\/PLSQL_EvaluationQualit\u00e91.jpg 350w, http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/01\/PLSQL_EvaluationQualit\u00e91-300x214.jpg 300w\" sizes=\"(max-width: 370px) 100vw, 370px\" \/><\/a>Un post en guise de synth\u00e8se, pour cette s\u00e9rie sur l\u2019analyse de code PL\/SQL avec SonarQube.<\/p>\n<p>Apr\u00e8s avoir <a href=\"http:\/\/qualilogy.com\/fr\/analyse-plsql-sonarqube-configuration\/\" target=\"_blank\">configur\u00e9 notre analyse <\/a>avec Jenkins, nous avons lanc\u00e9 celle-ci et constat\u00e9 17 infractions bloquantes (<a href=\"http:\/\/qualilogy.com\/fr\/analyse-plsql-sonarqube-blockers\/\" target=\"_blank\">Blockers<\/a>) mais z\u00e9ro d\u00e9faut critique (<a href=\"http:\/\/qualilogy.com\/fr\/analyse-plsql-avec-sonarqube-criticals\/\" target=\"_blank\">Critical<\/a>) avec le Quality Profile par d\u00e9faut de SonarQube. En fait, les 5 r\u00e8gles Critical existantes \u00e9taient d\u00e9sactiv\u00e9es, ainsi que certaines des autres r\u00e8gles de diff\u00e9rentes criticit\u00e9s : 58 sur un total de 132. <!--more--><\/p>\n<p>Nous avons donc cr\u00e9\u00e9 <a href=\"http:\/\/qualilogy.com\/fr\/analyse-plsql-sonarqube-quality-profile-plsql\/\" target=\"_blank\">notre propre Quality Profile<\/a> afin d\u2019activer toutes ces r\u00e8gles, relanc\u00e9 une analyse et regarder concr\u00e8tement de quelles r\u00e8gles nous disposions ainsi dans les diff\u00e9rentes cat\u00e9gories Blockers, Criticals et <a href=\"http:\/\/qualilogy.com\/fr\/analyse-plsql-avec-sonarqube-majors\/\" target=\"_blank\">Majors<\/a>.<\/p>\n<p>L\u2019objectif de ce travail est de me constituer une d\u00e9mo sur du code PL\/SQL afin de pr\u00e9senter \u00e0 un client ou un prospect les b\u00e9n\u00e9fices qu\u2019il peut tirer de SonarQube. Pour cette raison, j\u2019ai d\u00e9lib\u00e9r\u00e9ment remont\u00e9 en Criticals, voire en Blockers certaines r\u00e8gles qui concernent la fiabilit\u00e9, la s\u00e9curit\u00e9 ou la performance tout en minimisant les r\u00e8gles en mati\u00e8re de lisibilit\u00e9 ou de portabilit\u00e9 du code. Tout simplement parce que je souhaite mettre en avant les violations qui vont impacter l\u2019utilisateur final :<\/p>\n<ul>\n<li>une application qui s\u2019arr\u00eate brusquement,<\/li>\n<li>une transaction qui n\u2019est pas finalis\u00e9e, avec une possible corruption de donn\u00e9es,<\/li>\n<li>une erreur dans un algorithme qui conduit \u00e0 une erreur de logique ou de calcul,<\/li>\n<li>une performance d\u00e9grad\u00e9e,<\/li>\n<li>etc.<\/li>\n<\/ul>\n<p>A quoi ressemble maintenant mon tableau de bord SonarQube ? Quelles sont les informations utiles ou que je vais mettre en avant dans une pr\u00e9sentation ? M\u00eame si le dashboard SonarQube est tr\u00e8s bien organis\u00e9, il est facile de ne pas savoir par o\u00f9 commencer.<\/p>\n<p>Je ne vais pas expliquer ici comment j\u2019effectue une d\u00e9mo, encore moins comment je construis un audit de la qualit\u00e9 du code. Il faudrait bien plus d\u2019un post, et ce fera probablement l\u2019objet d\u2019une s\u00e9rie future. Mais en guise de synth\u00e8se des posts pr\u00e9c\u00e9dents de cette s\u00e9rie, voici comment je proc\u00e8de lorsque je d\u00e9couvre une nouvelle application.<\/p>\n<h2>La taille<\/h2>\n<p>Lorsque vous rencontrez une personne, la premi\u00e8re chose que vous remarquez, c\u2019est sa taille. Est-elle grande, moyenne, petite ?<\/p>\n<p><a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/01\/PLSQL_Size.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"alignright size-full wp-image-1637\" alt=\"PLSQL_Size\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/01\/PLSQL_Size.jpg\" width=\"348\" height=\"103\" srcset=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/01\/PLSQL_Size.jpg 348w, http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/01\/PLSQL_Size-300x88.jpg 300w\" sizes=\"(max-width: 348px) 100vw, 348px\" \/><\/a>Un premier widget me permet de voir que nous avons ici 16 fichiers ou programmes de base de donn\u00e9es, qui contiennent 1 569 \u2018fonctions\u2019 (objets de type proc\u00e9dure, fonction, trigger, etc. ) repr\u00e9sentant 28 116 instructions (statements).<\/p>\n<p>Cette application compte environ 95 KLoc (milliers de Lines of Code) sur un total de 147 KLoc : la diff\u00e9rence est constitu\u00e9e par les lignes de commentaires (ou des lignes blanches, ou du code en commentaire).<\/p>\n<p>Avec le widget \u2018Custom Measures\u2019, je me suis constitu\u00e9 mon propre \u2018panneau\u2019 afin d\u2019afficher ensemble ces informations de taille et de commentaires.<\/p>\n<p><a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/01\/PLSQL_Wdiget1.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-1638\" alt=\"PLSQL_Wdiget1\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/01\/PLSQL_Wdiget1.jpg\" width=\"584\" height=\"143\" srcset=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/01\/PLSQL_Wdiget1.jpg 584w, http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/01\/PLSQL_Wdiget1-300x73.jpg 300w\" sizes=\"(max-width: 584px) 100vw, 584px\" \/><\/a><\/p>\n<p>Que pouvons-nous en d\u00e9duire ? Nous avons l\u00e0 une application de taille moyenne \u00e0 importante pour cette technologie, avec un taux de commentaires sup\u00e9rieur \u00e0 25%, donc correct (sans pr\u00e9sager de la qualit\u00e9 de ceux-ci).<\/p>\n<p>Le nombre de lignes de code par objet (Functions) est inf\u00e9rieur \u00e0 100, donc raisonnable. Nous comptons en moyenne 18 instructions (Statements) par objet, donc l\u00e0 encore ce n\u2019est pas \u00e9norme.<\/p>\n<p>Sur la base de ces chiffres, on peut penser qu\u2019une correction ou une \u00e9volution sur ces composants ne repr\u00e9sentera pas une charge trop importante.<\/p>\n<p>Sauf que tout cela tient en seulement 16 fichiers, c\u2019est-a-dire 16 scripts ou programmes. La granularit\u00e9 de chaque composant est peut-\u00eatre correcte, mais nous avons en moyenne 6 000 lignes de code par fichier, ce qui est donc \u00e9norme, et vous pouvez imaginer que cela va peser sur la maintenabilit\u00e9 de ces programmes.<\/p>\n<p>Ajouter ou modifier du code dans un composant PL\/SQL de 100 lignes est relativement ais\u00e9. Mais lorsque vous devez rechercher ces 100 lignes ou le code de tous les autres composants qui seront impact\u00e9s par cette modification, au sein d\u2019un programme de 6 000 lignes de code, cela va prendre du temps et le risque d\u2019introduire une erreur \u2013 un bug &#8211; \u00e0 l\u2019occasion de cette correction ou de cette \u00e9volution sera \u00e9galement \u00e9lev\u00e9.<\/p>\n<p>Donc l\u2019\u00e9tape suivante dans la d\u00e9couverte et l\u2019\u00e9valuation de la qualit\u00e9 de cette application consiste \u00e0 v\u00e9rifier la granularit\u00e9 de ses composants.<\/p>\n<h2>Granularit\u00e9 des composants<\/h2>\n<p>Et c\u2019est l\u00e0 qu\u2019un nouveau widget introduit avec la version 4.1 de SonarQube nous apporte une aide pr\u00e9cieuse.<\/p>\n<p>Le Project File Bublle Chart affiche la r\u00e9partition des diff\u00e9rents fichiers selon deux axes : le nombre de Lines of Loc sur l\u2019axe horizontal X, et le nombre de violations aux bonnes pratiques de programmation, sur l\u2019axe vertical Y. A noter que j\u2019ai choisi une \u00e9chelle logarithmique pour ce dernier. La taille de chaque bulle repr\u00e9sente la dette technique en nombre de jours pour chaque composant. Tout ceci est param\u00e9trable.<\/p>\n<p><a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/01\/PLSQL_Bubble31.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-1639\" alt=\"PLSQL_Bubble3\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/01\/PLSQL_Bubble31.jpg\" width=\"775\" height=\"407\" srcset=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/01\/PLSQL_Bubble31.jpg 775w, http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/01\/PLSQL_Bubble31-300x157.jpg 300w, http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/01\/PLSQL_Bubble31-624x327.jpg 624w\" sizes=\"(max-width: 775px) 100vw, 775px\" \/><\/a><\/p>\n<p>En pointant sur une bulle, nous pouvons voir s\u2019afficher ses diff\u00e9rentes caract\u00e9ristiques. A gauche, le programme \u2018CreatePackage1.sql\u2019 contient 6 119 lignes de code, plus de 4 000 d\u00e9fauts et une dette technique de 228 jours.<\/p>\n<p>Le script \u2018Create_Tables.sql\u2019, au milieu, contient 2,5 fois plus de lignes de code (16 810 Loc) mais seulement 400 d\u00e9fauts.<\/p>\n<p>Et dans le coin sup\u00e9rieur droit de ce graphique, nous trouvons le fichier \u2018CreatePackageBody.sql\u2019 avec pr\u00e8s de 58 500 lignes de code, pr\u00e9s de 20 000 d\u00e9fauts et plus de 1 400 jours de dette technique.<\/p>\n<p>Vous allez penser que l\u2019\u00e9quipe de projet responsable d\u2019une telle application est compl\u00e8tement irresponsable de laisser cro\u00eetre un tel programme \u00e0 ce point. En fait, pas du tout. Nous avons l\u00e0 un ensemble de scripts et de programmes de bases de donn\u00e9es pour une application client-serveur tr\u00e8s ancienne (plus de 20 ans d\u2019\u00e2ge), avec les traitements de logique m\u00e9tier d\u00e9port\u00e9s au niveau de la base de donn\u00e9es. C\u2019\u00e9tait \u00e7\u00e0 ou coder ces traitement dans les \u00e9crans, dans les langages de l\u2019\u00e9poque, ce qui n\u2019\u00e9tait pas du tout recommand\u00e9.<\/p>\n<p>Mais pourquoi impl\u00e9menter toute la logique applicative dans un seul et unique fichier \u2018CreatePackageBody.sql\u2019 ? Une autre solution consisterait en r\u00e9partir tous ces traitements dans diff\u00e9rents programmes, mais cela implique de g\u00e9rer tous les liens entre ceux-ci, et ce sur diff\u00e9rentes versions. Or \u00e1 l\u2019\u00e9poque, il n\u2019y avait pas d\u2019outils de gestion de configuration (SCM). Et puis, il est plus compliqu\u00e9 de reconstruire la base de donn\u00e9es avec plusieurs programmes que vous devez ex\u00e9cuter en respectant un ordre pr\u00e9cis, sans vous tromper de versions, &#8230;<\/p>\n<p>Un coup d\u2019\u0153il sur les autres fichiers nous permettra de v\u00e9rifier que ces programmes sont en charge de cr\u00e9er des vues, des triggers, donc avec peu de lignes de code et donc peu de d\u00e9fauts. Comme par exemple, le script de cr\u00e9ation des tables qui pr\u00e9sente tr\u00e8s peu de violations pour un nombre \u00e9lev\u00e9 de lignes puisqu\u2019il n\u2019y a pas de traitements.<\/p>\n<p>Et donc ce composant monstrueux qui r\u00e9unit tous les traitements, et fausse toutes les moyennes en mati\u00e8re de taille des composants, puisqu&rsquo;il repr\u00e9sente \u00e0 lui seul plus de 60% du code de l\u2019application. Ces mesures de taille semblaient indiquer un code pas trop complexe \u00e0 faire \u00e9voluer, jusqu&rsquo;\u00e0 ce que le Bubble Chart nous fournisse des indications contraires.<\/p>\n<p>Il est tr\u00e8s probable que la maintenabilit\u00e9 et les co\u00fbts de maintenance de cette application vont en souffrir. Ce que nous v\u00e9rifierons dans le prochain post.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Un post en guise de synth\u00e8se, pour cette s\u00e9rie sur l\u2019analyse de code PL\/SQL avec SonarQube. Apr\u00e8s avoir configur\u00e9 notre analyse avec Jenkins, nous avons lanc\u00e9 celle-ci et constat\u00e9 17 infractions bloquantes (Blockers) mais z\u00e9ro d\u00e9faut critique (Critical) avec le Quality Profile par d\u00e9faut de SonarQube. En fait, les 5 r\u00e8gles Critical existantes \u00e9taient d\u00e9sactiv\u00e9es, [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[],"class_list":["post-1615","post","type-post","status-publish","format-standard","hentry","category-sonarqube-plsql"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/1615"}],"collection":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/comments?post=1615"}],"version-history":[{"count":28,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/1615\/revisions"}],"predecessor-version":[{"id":1618,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/1615\/revisions\/1618"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=1615"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=1615"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=1615"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}