Sonarqube – Plugin VB.NET Gratuit

sonarLogo

Sonarqube est un outil plus qu’intéressant pour gérer les métriques de code de manière centralisée. Il permet de voir du même coup d’œil les analyses statiques de code de plusieurs langages comme C#, JavaScript, Java et plusieurs autres. Le principal élément d’intérêt dans cet outil est de pouvoir évaluer et quantifier la dette technique d’une application.

Le problème?

L’organisation pour laquelle je travaille était très intéressée par l’outil (bon d’accord, disons que c’était moi plus que les autres…), mais un élément était bloquant pour vraiment évaluer l’outil : l’analyse du langage VB.NET coutait 6000 euros et est maintenant inclus dans un package pour entreprise qui requiert un abonnement. Bref, difficile de valider l’utilité de l’outil quand notre dette réside probablement dans le code patrimonial qui a été fait depuis plusieurs années, principalement en VB.NET.

 

Radin ou ingénieux?

Les motivations derrière la découverte que j’ai faite peuvent laisser place à interprétation mais, en analysant le code du plugin C#, j’ai pu remarquer que l’équipe SonarSource avait publié tous les éléments pour créer notre propre plugin VB.NET sans trop d’efforts. Un bon travail de copier-coller et le tour est joué.

 

Résultat (GitHub)

J’ai placé les sources dans GitHub dans un « fork » du repository de SonarSource que vous trouverez à l’emplacement suivant. J’hésite encore à faire une pull request pour leur proposer de le rendre gratuit pour tous.

https://github.com/karoldeland/sonar-csharp/commit/a1d748832f6fba1a940288450c436a50f63e1088

 

Pour arriver à compiler le plugin VB.NET, juste à suivre les instructions pour le plugin C#. Bonne chance avec Maven ! 🙂

Suis-je seul à trouver ce hack super cool? 🙂

Petits trucs…

J’ai aussi pu intégrer mon nouveau plugin dans TFS 2017 à l’aide des tâches fournies dans le « marketplace ». Toutefois, comme l’exécution des tests unitaires pour tous mes projets étaient conservés dans un fichier unique (C# et VB.NET combinés), on doit faire l’importation du fichier trx par un seul des deux plugins .NET. Pour la couverture de code, on peut importer le même fichier .coveragexml par les deux plugins et tout fonctionne correctement.

Dette technique – Partie 1

Comme plusieurs développeurs, j’ai toujours préféré travailler dans un contexte de nouveau développement et non en maintenance ou en entretien. Pour moi, ces deux derniers termes étaient péjoratifs parce qu’ils étaient synonymes de « patch » et de « workaround », voire de frustration. Un logiciel qui dégénère semblait être à cette époque une évolution normale et une fatalité. Après quelques années de bon service, on devait prévoir une réécriture. Ça ne donnait pas vraiment le goût à quiconque de travailler dans un contexte semblable. Produire quelque chose en sachant qu’on prévoit déjà le jeter n’est pas très motivant.

Pourquoi fallait-il toujours en venir à ça? Qu’est-ce qui fait que les logiciels vieillissent souvent mal? Malheureusement, il n’y a pas consensus dans l’industrie sur la manière de nommer les éléments qui impactent négativement le vieillissement d’une application. Certains vont parler de santé d’un système, d’autres de qualités non-fonctionnelles ou encore de qualité tout court. Un terme à la mode depuis quelques années, surtout en agilité, pour parler des éléments techniques qui sont problématiques, est celui de la dette technique. Je vous propose de creuser un peu le sujet pour voir ce qui en retourne.
(Temps de lecture 10 minutes)

Méthaphore

La métaphore de la dette technique a été introduite par M. Ward Cunningham en 1992 :

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

Si on paraphrase, la notion de dette technique fait le parallèle entre la notion de dette financière et le développement logiciel. Si on livre du code qui n’est pas de première qualité, on aura à le refaire éventuellement (rapidement svp!) et ça aura donc coûté plus cher à développer au final (capital + intérêts). En fait, tout le temps supplémentaire effectué sur ce code de pietre qualité doit être considéré comme des intérêts (difficulté de lecture, maintenance compliquée, etc.).

Une notion de stratégie est aussi sous-jacente sans quoi on parlerait simplement de mauvais code. Dans la définition de M. Cunningham, contracter une dette technique peut être une bonne chose si un autre objectif est atteint pour compenser. Le gain peut être le délai de commercialisation ou time to market plus court, rétroaction plus rapide ou autre.

Cette métaphore ciblait donc essentiellement du code, ce qui ne semble plus tout à fait être le cas aujourd’hui. La notion de dette technique a évolué et on y inclut maintenant à peu près tout ce qui n’est pas idéal du point de vue technique. On peut donc parler de dette de code, de connaissance, de test, d’architecture et de dette technologique. Voyons un peu les différents types de dette.

 

Types de dette

Dette de code

La dette de code regroupe tous les éléments reliés directement au code. Les avertissements du compilateurs, les indices de maintenabilité ou de complexité cyclomatique, longueur des méthodes ou des classes, etc.. D’autres éléments sont toutefois plus difficile à déceler. Quelle sont les qualités non-fonctionnelles que du code devrait avoir? Facile à modifier, couplage faible, respect des principes SOLID, facile à lire, représentatif du domaine d’affaire, etc.. Dépendamment du contexte, ces éléments sont d’une importance relative, ce qui explique probablement qu’il n’y a pas encore de consensus…

Dette de connaissance

Est-ce que votre documentation est à jour en tout point? Probablement pas… Il ne faut pas s’en vouloir, je n’ai pas encore vu une seule organisation où c’était le cas. Ce qui varie, c’est le degré de fiabilité de cette dernière. Si les documents ne sont pas à jour ou sont incomplets, comment fait-on pour se retrouver? Il faut demander au super-héros qui était là lors du dernier projet? Espérons qu’il a une bonne mémoire… Et si on parlait de PowerBuilder, VB6 et les autres? Par ailleurs, êtes-vous certains d’avoir bien compris le domaine d’affaire? Il suffit de prendre deux experts du domaine d’affaire et de les faire discuter ensemble pour se rendre compte que les termes employés sont les mêmes, mais que la définition est différente d’une personne à l’autre.

Dette de test

Le manque de couverture par les tests automatisés est une dette incontestable. Une application vieillira mal si on ne peut pas valider facilement et rapidement les changements qu’on y fait. On peut toujours s’en sortir avec les tests manuels, mais ils sont coûteux, lents et ils ne sont pas infaillibles. Par ailleurs, qui est capable de savoir ce qu’il faut tester lorsqu’on change la classe Dieu (God class)? La majorité des équipes ne prennent pas de chance et test l’application au complet. L’autre option est de ne pas modifier l’application…

Dette d’architecture

Cette notion de dette est plus difficile à cerner étant donné qu’il n’existe pas de principes architecturaux clairs et réglementés en développement logiciel comme c’est le cas pour les bâtiments. Un conseiller en architecture pourra toujours dire que le couplage est acceptable pour le moment étant donné les besoins actuels et, comme il est difficile de prévoir les changements, l’architecture est donc correcte. Ce dernier aura raison, mais c’est un jeu risqué. Par ailleurs, certains choix architecturaux pourront être fait en début de projet et, s’ils ne sont pas remis en question, il faudra vivre avec les intérêts de la dette ainsi contractée. C’est souvent cette étape qui fait mal en maintenance ou en entretien de système. On évite des changements fondamentaux pour ne pas déstabiliser l’application. Mais c’est une erreur parce qu’on commence alors à ajouter des nouvelles classes avec des noms proches de celles qui existent déjà et on ajoute des condition à un if else if qui n’en finit plus et on rend le code plus difficile à modifier, car on ajoute de la complexité.

Dette technologique

La dette technologique est plus facile à comprendre à mon avis. Toutes les librairies ont une version. Même chose pour les systèmes d’exploitation et les serveurs de base de données. Ne rien faire lors de la sortie d’une nouvelle version contribue à accroître la dette. On doit mettre à jour les technologies sur lesquelles reposent nos applications, sinon on doit gérer le risque qu’on encoure. Par ailleurs, mette à jour une version à la fois d’un produit est souvent moins coûteux que de passer trois versions en même temps.

 

Pourquoi avons-nous de la dette technique?

Selon la définition de M. Cunningham, la réponse est simple : c’est voulu. C’est une décision d’équipe qui est éclairée. Avec la définition élargie dont on parle maintenant, les raisons sont plus subtiles. La raison qui revient le plus souvent est celle de la pression de la date de livraison. On devait livrer alors on a coupé les coins ronds pour y arriver. Cependant, un changement externe à notre application peut engendrer de la dette technique. Le changement de version d’un API en est un exemple, mais ce n’est pas toujours aussi facile à détecter. Par ailleurs, il faut convaincre les clients qu’il doivent investir pour payer la dette. Certains clients sont plus coriaces que d’autres… Pourtant, la dette ne s’éliminera pas toute seule.

Votre logiciel n’est peut-être pas facilement modifiable. Si la couverture de code par les tests est insuffisante ou inexistante, on voudra limiter les changements ou les faire en périphérie, ce qui aura pour effet de contrevenir à l’évolution du système ou de l’application et à ralentir la maintenance.

L’obsession des nouvelles fonctionnalité n’est pas à négliger. Certains clients qui veulent toujours plus de fonctionnalités sans retravailler l’existant s’expose à des problèmes. Il ne faut pas mal interpréter l’agilité ou le SCRUM. Il est vrai que le but est toujours de produire de la valeur pour le client à chaque itération. Mais il faut s’habituer à garder une portion du budget pour l’entretien et le refactoring pour avoir une saine évolution.

 

Et ensuite?

Un fois qu’on comprend bien les types de dette, il importe de s’en occuper. Pour ce faire, on devra tenter de la repérer, de la mesurer et d’y remédier. C’est ce que nous verrons dans un prochain billet.