Accueil > .Net, Développement, Qualité > SonarQube – 28 Jours plus tard

SonarQube – 28 Jours plus tard

Bon, c’est pas 28 jours, mais la référence me plaisait !

J’avais parlé de SonarQube ici : SonarQube et la qualité du code. Ce billet est donc la suite logique.

Cela fait maintenant plus d’un mois que je suis sur un nouveau projet, seul.
Du coup, il m’a été aisé de mettre en place SonarQube depuis mon poste, via des tâches planifiées : démarrage du serveur et analyse à 8h du matin, chaque jour.
Et comme j’étais sur plusieurs projets, j’avais tendance à faire des allers-retours, ce qui est très nuisible à la concentration et donc la qualité de code.
J’ai aussi démarré SonarQube avec un décalage de 10 jours de développement par rapport au projet (contraintes de temps).
Du coup, à la première analyse, j’avais déjà quelques données.

Ce billet a donc deux buts.
Le premier, c’est de m’aider à formaliser un retour d’expérience et le second, de la partager.

 

Le bon

 

Ce qui m’a bien aidé sur SonarQube, c’est les messages du genre : « Reduce the number of conditional operators (4) used in the expression (maximum allowed 3). » ou « The Cyclomatic Complexity of this method is 20 which is greater than 10 authorized. ».
J’ai pas toujours pu régler le problème (c’est parfois des problématiques fonctionnelles), mais au moins, cela pointe les endroits qui méritent une refonte ou, à minima, des explications.

Un autre soucis qu’il m’a bien indiqué et que j’avais un peu zappé, c’était l’usage d’un « TextWriter » sur lequel je n’avais pas d’appel de Dispose() (c’est pour des fonctionnalités de log d’un batch, donc dès que le batch s’arrêtait, en erreur ou non, c’était fait in fine). Grâce à ça, j’ai pu refaire l’organisation de la classe en question.

Un autre point très sympa, c’est l’identification de duplication de code.
SonarQube a vu des duplications qui m’avait échappées.
Ci-dessous, le graphique représentant la duplication de code.
Le premier pic m’avait complètement échappé. Par contre, le second, je le savais (c’était avant que je fasse un gros morceau de refactoring).
Duplication

Le graphique ci-dessous représente la dette technique.
On peut très bien voir le décalage des 10 jours dont je parlais plus haut : à vouloir avancer rapidement, j’ai accumulé de la dette.
Au fil de l’eau, j’ai pu la gérer et la garder au minimum.
Dette Technique

Ce qui est assez sympa, c’est aussi de voir l’évolution du nombre de ligne de code.
Pour moi, moins de lignes de code = moins à maintenir, donc j’aime bien les limiter, du coup voir que je parviens effectivement à maitriser les choses en ajoutant des fonctionnalités, c’est juste du bonheur !
Lignes de code

 

Le moyen

 

La première chose qui est assez flagrante, c’est que SonarQube et moi, on est pas toujours d’accord.

Typiquement, voici un bout de code :

private const SqlBulkCopyOptions DefaultOptions =
    SqlBulkCopyOptions.Default | SqlBulkCopyOptions.CheckConstraints;

public void WriteToServer<T>(string table, IList<T> entities, SqlBulkCopyOptions options = DefaultOptions)
{
    // [...]
}

Pour SonarQube, c’est « Use the overloading mechanism instead of the optional parameters. ».
Autrement dit, il voudrait ceci :

public void WriteToServer<T>(string table, IList<T> entities)
{
    WriteToServer<T>(table, entities, DefaultOptions);
}

public void WriteToServer<T>(string table, IList<T> entities, SqlBulkCopyOptions options)
{
    // [...]
}

Comme cela fait partie de la « mécanique interne », autrement dit, que ce n’est pas exposé via une API ou autre et comme je n’ai pas un amour particulier pour pisser du code, j’ai quand même une préférence pour les paramètres optionnels.

Un autre exemple est le « Define the locale to be used in this string operation. » qui m’est signalé au sujet d’un ToString() sur une enum.
Le problème, c’est que :

    [Obsolete("The provider argument is not used. Please use ToString().")]
    public string ToString(IFormatProvider provider)
    {
      return this.ToString();
    }

Ecran des Issues
Issues

Pour les Issues Critical, j’en ai eu 4 au total.
Le problème c’est que deux d’entre elles c’était pour « Remove this logging statement. » au sein d’une console.
Mais au final, comme j’écrivais un batch console qui écrit dans la console à destination de l’ordonnanceur utilisé par l’exploitation…et bien c’est des choses que je dois conserver. Mais ça, il ne peut pas le deviner. SonarQube n’est pas magique non plus.

Les deux autres, c’est le Dispose() dont je parlais plus haut : il m’a signalé celui en défaut et une solution pour le gérer (et pour le coup, je n’y avais pas pensé, donc bon point ^^).

 

Le moche

 

Le premier truc qui est frustrant, je ne sais pas si c’est du fait de la version « Embedded database » ou non, mais c’est que l’historique n’est pas réellement conservé.
SonarQube garde des métriques (pour faire les graphiques, par exemple), mais il ne garde pas le code (par exemple).
Ce qui veut dire que, lorsqu’on regarde les Issues qui ont été Fixed, on se retrouve parfois avec une Issue et haut du fichier, qui ne pointe sur rien.

De même, pour une même version, il ne garde que les Events divergents, c’est-à-dire si la Quality Gate passe d’une couleur à une autre (le passage au rouge veut dire qu’une Issue critique a été créée ; le passage au vert, c’est quand elle est traitée).

A part ça, c’est surtout la personnalisation inexistante pour le C# qui me gêne.

 

Conclusion

 

SonarQube, c’est bien, c’est beau, mangez-en.
Par contre, il n’est pas magique.

Je l’ai fait dans une démarche totalement volontaire et je me suis pris au jeu de tout traiter.
Ce qui était d’autant plus simple que j’étais seul sur un nouveau projet.

Pour les projets existants et/ou ayant un volume beaucoup plus important, ça va clairement être différent.
Sur d’autres applicatifs, j’ai un nombre de lignes de code 10 à 20 fois supérieur et une dette technique évaluée qui est clairement démotivante.

De plus, SonarQube n’a aucun aspect contraignant.
Du coup, si un développeur n’est pas motivé pour le respecter, il va falloir s’y prendre autrement qu’en lui présentant de beaux écrans qui lui disent qu’il fait de la merde.
Mais ça, ça fait aussi partie de la conduite du changement.

Catégories :.Net, Développement, Qualité
  1. Aucun commentaire pour l’instant.
  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :