La semaine dernière, je vous ai présenté les différents niveaux de maturité en matière de qualité logicielle et comment la mesure de la dette technique nous permet de progresser à travers ces différents niveaux, pour une gestion proactive et optimisée de la qualité.

A cette occasion, j’ai parlé d’utiliser la dette technique dans le cadre de la représentation d’un portfolio d’applications, selon différents axes. Je me suis alors demandé ce que donnerait une représentation 3D d’un tel portfolio, avec le plugin ‘3D City Model’ d’eXcentia (1).

Je vous ai déjà présenté celui lors d’articles précédents : City Model, City Model – Nouvelle version,  Cité Critique, où nous avions vu notamment comment rentrer nos propres formules pour jouer avec ce modèle 3D, et enfin La métrique ABC  afin  d’investiguer la métrique du même nom.

Représentation 3D d’un porfolio

J’ai une instance SonarQube avec un portfolio composé de plusieurs applications dont 5,7 millions de lignes de code (MLoc) Cobol, 485 milles lignes de code (KLoc) Abap (applications SAP) et 205 KLoc d’applications J2EE. J’ai en fait constitué trois portfolios ‘Cobol’, ‘J2EE’ et ‘SAP’, ainsi qu’un portfolio ‘Global’ regroupant les 3 précédents.

Je me suis aidé pour ce faire du plugin ‘Views’ de SonarSource, qui permet d’agréger plusieurs projets ou analyses de code en une vue unique, et donc de consolider ainsi différentes mesures et métriques selon différents axes: métier, technologie, etc. Enfin bref, en différents portfolios.

Malheureusement, le plugin 3D City ne fonctionne pas avec des vues, quoique eXcentia prévoit de développer cette fonctionnalité dans le futur. Mais heureusement, le plugin vient avec un widget que j’ai trouvé intéressant pour ce que je voulais faire.

Donc, je me connecte en Admin sous Sonar afin de pouvoir configurer les widgets de mon tableau de bord …

… puis choisir le menu ‘3D Code Metrics’ afin de n’afficher que les widgets de ce plugin, et sélectionner le widget ‘Filtered Megalopolis’:

Je vais configurer celui-ci en entrant un titre pour ce graphique, et dans la combo-box ‘Project filter’, je vais choisir ‘Projects’. Tout autre filtre basé sur des ‘Views’ ne permettra pas d’afficher le modèle 3D, donc j’utilise ce widget afin de visualiser mon portfolio global, avec toutes ses applications.

Par contre, vous pouvez utiliser différents filtres, ce qui devrait donc permettre des associations de projets selon différents axes. Par exemple, je peux créer un filtre sur toutes les analyses dont le nom commence par ‘Cobol’ et ne lister ainsi que les projets Cobol, comme le serait un portfolio spécifique à ces applications.

Je ne vais pas insister plus avant sur la configuration du widget, je vous laisserai découvrir par vous-même (les posts cités précédemment pourront vous aider), et donc je vais revenir dans le dashboard afin de travailler avec cette représentation.

Dans le dashboard, vous pouvez cliquer sur le graphique afin de déplacer votre ‘cité’ selon toutes les directions souhaitées et utiliser également la roulette de la souris afin de modifier sa taille, c’est-à-dire son aperçu. Vous pouvez également cliquer sur n’importe quel édifice afin de disposer d’informations concernant celui-ci.

Ici, nous pouvons voir notre application la plus importante, ‘Billing’ en Cobol, avec 2,5 millions de lignes de code (MLoc) dans 116 019 fonctions (Paragraphes ou Sections en Cobol, méthodes en Java, fonctions pour les langages types L4G) et une Complexité Cyclomatique (CC) de 434 218 points. Ah, le Cobol, c’est gros hein ? Il y a du boulot là.

Mais ce qui appelle surtout mon attention. ce sont les deux barres rouges au pied de ces gigantesques applications Cobol.

Nous avons là deux applications Abap:

• CO_OT1 avec prés de 350 KLoc et plus de 54 000 points de CC.
• CO_OT2 avec moins de 100 KLoc et plus de 14 000 points de CC.

En cliquant sur ce qui ressemble à une éprouvette ou un flacon dans le menu du graphique, je peux afficher les différentes valeurs pour les différentes dimensions de ma cité 3D. Je peux voir ainsi que la couleur représente la complexité par fonction, et donc que proportionnellement, les objets Abap de ces deux applications, puisque très rouge, sont beaucoup plus complexes que dans les autres applications.

Rien qu’en regardant cette représentation 3D de mon portfolio, je peux identifier deux applications SAP avec une maintenabilité et une testabilité inférieures aux applications géantes en Cobol !

La couleur est d’ailleurs le critère sur lequel on va jouer principalement.

Par exemple, dans le graphique suivant, j’ai sélectionné la dette technique bloquante, c’est-à-dire le coût de remédiation des ‘Issues’ (violations aux bonnes pratiques de programmation) bloquantes.

On s’aperçoit que l’application CO_OT2 est maintenant en vert, donc sans aucune ‘Issue’ bloquante, alors que notre première application CO_OT1 a une dette technique bloquante de 2 100 minutes (soit 4 jours et 3 heures).

Quel autre caractéristique, éventuellement défectueuse, puis-je identifier?

Ici, j’ai paramétré la couleur sur le pourcentage de lignes dupliquées, plus communément appelé le ‘Copy/Paste’. Plus vous avez de blocs de code dupliqués, plus la maintenance de ce code sera difficile puisque vous devez répercuter toute modification dans chaque bloc de code ‘Copié/Collé’, et plus le risque de bug sera élevé en cas d’oubli. Dans une application difficile à tester, vous jouez avec votre budget de maintenance et la satisfaction – ou plutôt le mécontentement – de vos utilisateurs.

Le niveau de commentaires est correct, ce qui n’est pas rare pour les applications de type Legacy. Le Cobol est en vert également. Par contre, les blocs rouges représentent des applis J2EE. C’est devenu à la mode de ne plus commenter en Java.

Evaluation

Donc je sais maintenant que j’ai 2 applications SAP avec une complexité (par fonction) plus élevée que n’importe quelle autre application de mon portfolio. Qui dit application complexe dit application difficile à tester. Avec plus de 50 000 points de CC, CO_OT1 nécessite de concevoir des plans de tests le plus en amont du projet et de disposer d’outils de tests automatisés, notamment pour éviter les régressions. De plus, un code complexe signifie une maintenabilité plus faible, donc des coûts d’évolution plus importants, mais également un risque plus élevé d’introduire un défaut dans le code, et donc des bugs pour l’utilisateur final. D’où l’importance accrue d’investir dans les tests.

De plus, cette application a une dette technique portant sur des défauts de type ‘Blockers’, certes pas très importante mais lorsque je vais dans la page ‘Issues’ de cette applications, je constate 40 violations sur deux règles ‘System C functions should not be used’ et ‘Internal source code processing statements should not be used’.

Dans les deux cas, il s’agit d’instructions réservées par SAP, et qui peuvent changer ou disparaître d’une version à l’autre. C’est d’ailleurs l’un des problèmes majeurs d’un upgrade de version SAP, des plus coûteux qui soient.

D’ailleurs, le fait de rencontrer 40 de ces défauts ‘Blocker’ sur cette application CO_OT1 et aucun sur les autres applications Abap m’amènent à penser que cette équipe de projet – ou cet outsourcer – ne connaît pas cette règle critique. Point à vérifier.

Enfin, le taux élevé de code dupliqué met en péril la maintenabilité et la fiabilité de cette application. Raison de plus pour envisager un refactoring de celle-ci. Cela dit, la documentation du code – le niveau de commentaires – est très correcte et devrait donc faciliter (relativement) cette opération, avec l’objectif de ramener la dette technique à un niveau acceptable et remédier aux problèmes rencontrés.

Conclusion

Évidemment, je pourrais procéder à l’évaluation de mon portfolio et obtenir ces mêmes informations d’une autre manière, par exemple à l’aide de cette page ‘Compare’ dans SonarQube.

Je l’utiliserai d’ailleurs probablement afin de rassembler en un seul tableau les chiffres et les métriques que j’ai pu identifier précédemment à l’aide du plugin ‘3D City’. Néanmoins, il me faudrait configurer cette page avec tous les projets de mon portfolio et sur un nombre bien plus important de métriques, afin de repérer des problèmes potentiels sur mes différents domaines applicatifs. L’avantage du modèle 3D City est de permettre:

• Une identification immédiate des applications à problème.
• Une visualisation bien plus efficace qu’en parcourant des tableaux de chiffres.
• Le choix des métriques les plus utiles lors d’un audit de mon portfolio.
• Donc un diagnostic rapide et aisé.

Ensuite, il ne me reste plus qu’à zoomer au sein des applications que j’ai ainsi repérées afin de travailler les plans d’action qui me permettront de remédier à ces problèmes, et de chiffrer plus précisément les coûts de remédiation associés à la dette technique.

Simple, efficace et de plus très ludique, ce plugin 3D City est vraiment un must. C’est simple, les clients l’adorent.

 

(1) Si vous voulez faire de même, vous pouvez downloader une version d’essai (2 semaines) du ‘3D City model’ ici http://www.excentia.es/en/plugins/city-model/download, ou pour des versions précédentes de SonarQube: http://www.excentia.es/en/plugins/city-model/versions.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.