{"id":1578,"date":"2014-01-19T15:39:31","date_gmt":"2014-01-19T14:39:31","guid":{"rendered":"http:\/\/qualilogy.com\/fr\/?p=1578"},"modified":"2014-01-21T16:40:19","modified_gmt":"2014-01-21T15:40:19","slug":"analyse-plsql-avec-sonarqube-majors","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/analyse-plsql-avec-sonarqube-majors\/","title":{"rendered":"Analyse PL\/SQL avec SonarQube \u2013 Majors"},"content":{"rendered":"

\"PLSQL_Majors\"<\/a>Nous continuons cette s\u00e9rie sur l’analyse de code PL\/SQL, avec aujourd’hui les r\u00e8gles de type Major.<\/p>\n

Nous avons vu pr\u00e9c\u00e9demment comment organiser notre environnement <\/a>et configurer notre analyse de code avec Jenkins et SonarQube<\/a>.<\/p>\n

Nous avons cr\u00e9\u00e9 notre propre Quality Profile<\/a>, puis examin\u00e9 les r\u00e8gles de type Blockers<\/a> et Criticals<\/a>, toutes orient\u00e9es Robustesse (Reliability) et S\u00e9curit\u00e9. <\/p>\n

Les r\u00e8gles de type Major<\/h2>\n

Si on passe aux Majors, on commence \u00e0 avoir des r\u00e8gles qui impactent la maintenabilit\u00e9.<\/p>\n

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

Je vais faire passer en Minors un certain nombre de bonnes pratiques qui concernent la lisibilit\u00e9 du code ou sa portabilit\u00e9, car je ne souhaite pas en faire une priorit\u00e9. Et faire passer en Criticals certaines r\u00e8gles Majors qui concernent la robustesse, la performance ou la s\u00e9curit\u00e9.<\/p>\n

Pour quelles raisons ? Parce que ces d\u00e9fauts vont impacter l\u2019utilisateur. Un bug qui \u2018sort\u2019 l\u2019utilisateur de l\u2019application ou laisse celle-ci dans un \u00e9tat instable, avec une possible corruption de donn\u00e9es, ou un temps de traitement trop long vont affecter l\u2019utilisateur alors que des d\u00e9fauts portant sur la lisibilit\u00e9 ou la compr\u00e9hension du code vont augmenter le travail \u2013 et donc les co\u00fbts et les temps \u2013 de maintenance, mais sans cons\u00e9quences directes pour l\u2019utilisateur. Je souhaite donc mettre ce type de bonnes pratiques au second plan \u2013 en issues de type Major voire Minor.<\/p>\n

Il s’agit bien entendu d’une d\u00e9cision personnelle dans le cadre de cette analyse, destin\u00e9e \u00e0 r\u00e9aliser une ‘d\u00e9mo’ qui puisse me permettre de d\u00e9montrer \u00e0 un client comment utiliser SonarQube et quels b\u00e9n\u00e9fices en tirer. Je ne vais pas ignorer des d\u00e9fauts qui affectent les co\u00fbts de maintenance, mais je souhaite les faire passer au second plan et mettre en avant les violations aux bonnes pratiques qui pr\u00e9sentent un risque pour l’utilisateur final.<\/p>\n

Egalement, la plupart du code utilis\u00e9 pour effectuer cette analyse est assez ancien, et date d\u2019une \u00e9poque o\u00f9 ces bonnes pratiques de programmation n\u2019\u00e9taient pas en vigueur. Les d\u00e9veloppeurs qui doivent maintenir actuellement ce code ne sont pas responsables de ces d\u00e9fauts, alors m\u00eame qu\u2019ils p\u00e8sent lourdement sur la dette technique.<\/p>\n

Technical dette et SQALE<\/h2>\n

Si nous allons dans la page Squale, la pyramide suivante nous montre que la Robustesse (Reliabililty – 163 jours), la performance (Efficiency \u2013 192.5 jours) et la s\u00e9curit\u00e9 (Security \u2013 40 jours) repr\u00e9sentent ensemble 395.6 jours de dette technique (co\u00fbts de rem\u00e9diation des d\u00e9fauts correspondants) sur un total de 2 677.2, soit 14.7%.<\/p>\n

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

Le diagramme suivant nous montre bien l\u2019importance prise par la maintenabilit\u00e9, qui repr\u00e9sente les 3\/4 de la dette technique. Nous reviendrons dans un prochain post sur ce diagramme SQALE Sunburst. Mais nous pouvons voir (second cercle) que la lisibilit\u00e9 (Readibility) et la compr\u00e9hension du code (Understandability) sont les 2 facteurs constitutifs de la Maintenability. Toutes les r\u00e8gles (troisi\u00e8me cercle, le plus ext\u00e9rieur) concernant la Maintenabilit\u00e9 se r\u00e9partissent au sein de ces 2 groupes.<\/p>\n

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

La fl\u00e8che nous montre qu\u2019en mati\u00e8re de Changeabilit\u00e9, il faudrait 165.6 jours de travail pour affecter un alias \u00e0 chaque colonne des tables afin d\u2019en faciliter la compr\u00e9hension et les \u00e9volutions futures (Changeability). Cela repr\u00e9sente plus d’une ann\u00e9e-homme, et je ne pense pas que cela soit vraiment le plus critique. Ou en tout cas pas autant qu’un d\u00e9faut qui impacte l’utilisateur.<\/p>\n

En fait, il faudrait un chantier sp\u00e9cifique de plus de 15 ann\u00e9es hommes afin de supprimer la part de la dette technique imputable \u00e0 la Maintenabilit\u00e9, alors m\u00eame que nous ignorons si cette application va \u00e9voluer, voire m\u00eame exister encore longtemps.<\/p>\n

Je vais faire donc faire passer en Minors un certain nombre de bonnes pratiques qui concernent la lisibilit\u00e9 du code ou sa portabilit\u00e9, car je ne souhaite pas en faire une priorit\u00e9. Et faire passer en Critical certaines r\u00e8gles Major qui concernent la robustesse, la performance ou la s\u00e9curit\u00e9.<\/p>\n

Sans rentrer dans trop de d\u00e9tails, les r\u00e8gles que nous passons en Criticals sont les suivantes :<\/p>\n