SONAR : La chasse aux 7 péchés du développeur

JUG Summer Camp

Durant le JUG Summer Camp 2011 qui a eu lieu à La Rochelle, Olivier Gaudin de la société SonarSource a présenté l’inspection continue du code source avec Sonar.

Olivier a détaillé les 7 péchés communément commis par les développeurs et comment les aider à améliorer la qualité technique des applications.

JUG Summer Camp 2011 - Sonar - Olivier Gaudin

Au départ, le développeur était un aventurier...

Le développeur devait affronter les dangers multiples des applications mal conçues et non testées où se cachaient en embuscade de multiples « bugs » prêts à attaquer le pauvre utilisateur innocent.

.. il est maintenant un chirurgien

Armé de l’intégration continue, et de tests unitaires, le développeur peut opérer au cœur des applications afin de corriger et d’ajouter de nouvelles fonctionnalités tout en s’assurant de la santé de l’application. Les outils sont là pour vérifier l’état du code source.

Développement durable

Développement durable
Une application évolue dans le temps et le développeur doit faire du neuf avec du vieux.

Ces multiples itérations entraînent rapidement de la maintenance à effectuer sur le code existant. D’ailleurs, pour un projet Agile, tout est maintenance.

Nous avons besoin de nous assurer que ce qui a été fini continuera à fonctionner dans le futur. La validation par les tests unitaires permet de s’assurer que l’existant fonctionne toujours et qu’une nouvelle fonctionnalité n’entraîne pas de régressions.

Réaliser les exigences

Le client n’est satisfait que si l’application répond à ses exigences.

Pour les exigences fonctionnelles, l’équipe projet valide l’implémentation des demandes clients à l’aide d’un gestionnaire de tickets.

Pour les exigences techniques, elle utilise une intégration continue pour surveiller l’état du projet et s’assurer que celui-ci est toujours capable de compiler.

Enfin pour les exigences de qualités, elle met en place une inspection continue pour s’assurer de la qualité du code et qu’un maximum de lignes de code est couvert par des tests unitaires.

La réalisation de ces exigences permet de s’assurer que le code sera maintenable dans le temps par de nouvelles personnes et que l’application répond bien aux demandes.

Comment s'assurer de la qualité du code ?

La qualité peut se mesurer en calculant la non-qualité du code. Nous parlons alors de dette technique. Dans le domaine du développement logiciel, une dette technique correspond au coût de correction d’une erreur ou de non respect de la conception d’une application.

En effet, comme nous ne pouvons pas attendre d’avoir une qualité parfaite pour livrer une application, des bugs et des incohérences restent présents dans le code. Ceci peut être restreint en identifiant les « péchés » commis par les développeurs. Un outil comme Sonar permet de détecter ces erreurs à l’aide d’indicateurs.

Les 7 péchés du développeur

Voici les 7 péchés du développeur :

1 - Duplication de code

De tous les péchés, la duplication de code est la plus dangereuse.

En effet, il est difficile de maintenir deux codes similaires en parallèle. Il faut penser à apporter la même correction à deux endroits. De plus la recopie d’une correction d'un endroit à l’autre endroit peut être mal effectuée et entraîner un effet de bord qui n’aura pas forcément été testé.

C’est pourquoi il est primordial de factoriser le plus possible le code.

L’écriture de tests unitaires permet de définir le contrat actuel du code dupliqué. Nous factorisons ensuite ces deux codes. Les tests unitaires permettent d'indiquer que le fonctionnement précédent est conservé.

2 - Mauvaise distribution de la complexité

La complexité dite « complexité cyclomatique » se mesure d’après le nombre de choix et de branches dans une méthode. C'est-à-dire le nombre de « if », « else », « for », « while », « switch / case » dans une méthode.

Il est conseillé d’avoir au maximum une complexité de 12 dans une méthode.

Plus la complexité d’une méthode est importante et plus elle sera jugée trop complexe et trop dangereuse à modifier. Une modification de ce type de méthodes présente un risque important d’effets de bord et de régressions.

Pour éviter une complexité trop importante, les deux règles d’or suivantes sont à respecter :

  • « Une méthode ou une classe n’est jamais trop petite »
  • « Une et une seule responsabilité par classe. »

En effet, il est nécessaire de séparer les préoccupations : une classe n’est responsable que d’un traitement. Elle délègue les autres traitements à d’autres classes.

3 - Mauvais design

Le design se mesure par les dépendances entres les couches de l’application.

Ainsi les classes d’un package « A » ne doivent pas utiliser les classes d’un autre package « B » dans le cas où ces dernières utilisent les classes du package « A ». Il s’agirait alors d’un cycle de dépendance entre packages.

Dans ce cas, les deux packages « A » et « B » sont inter-dépendants et ne pourraient exister ni être livrés séparément.

4 - Pas de tests unitaires

Un test unitaire définit le contrat d’une méthode. Nous nous assurons de cette façon que la méthode répond bien à ce qui a été spécifié dans le test unitaire.

Ainsi le test unitaire est le garant technique de la bonne tenue de l’application.

5 - Pas de respect des standards

Un standard correspond par exemple à la gestion des exceptions, au formatage du code source.

Le respect de ces standards facilite la prise en main de la maintenance et de l’évolution de l’application par de nouveaux développeurs.

6 - Bugs potentiels

Les bugs potentiels correspondent par exemple à la présence d’un risque de « NullPointerExpression » ou d’expressions ambigües.

Ils sont détectés à l’aide de l’outil « FindBugs ». Intégré à Sonar, les résultats de l’analyse de « Findbugs » sont présentés de façon synthétiques et hiérarchiques.

7 - Pas ou trop de commentaires

Il est conseillé de définir les commentaires sur les API publiques car elles permettent de décrire les intentions des classes et méthodes à une autre couche de l’application.

Cependant, trop de commentaires peuvent devenir contre-productifs car ils peuvent polluer le code et leur maintenance deviendrait coûteuse.

Il est plus important de bien nommer les méthodes et les variables, et de définir le contrat de chaque méthode à l’aide de tests unitaires.

Finalement, ce sont les tests unitaires qui commentent les méthodes en indiquant leurs intentions. Les tests unitaires deviennent ainsi la documentation technique du code source.

La chasse aux 7 péchés du développeur

Sonar
Sonar a pour objectif d’aider à améliorer la qualité de ce qui est produit. Il s’agit d’une aide technique : il permet de détecter les erreurs commises par les développeurs.

L’interface de Sonar se compose des écrans suivants :

  • Le Dashboard technique qui affiche les indicateurs pour chacun des 7 péchés
  • Le Dashboard de management « SQALE » qui calcule la dette technique (ce module est payant)
  • Le nuage « Cloud » présente de façon mélangée les noms des classes de l’ensemble du projet : les noms les plus gros et les plus rouges sont ceux à corriger en premier
  • La page « Design » affiche les dépendances cycliques entre packages
  • La page « Hotspot » priorise les maintenances à effectuer
  • La page « Time machine » permet de voir la progression de la qualité du code dans le temps

Dans l’ensemble des pages, l’interface présente d’abord une vue générale de l’application. L’utilisateur est alors libre de cliquer sur chaque élément : package, classe, méthode ; afin de visualiser en détail les défauts jusqu’à la visualisation du code source.

Sonar est collaboratif : il est possible à un utilisateur d’affecter une tâche de maintenance d’une méthode ou d’une classe à un autre utilisateur. Celui-ci en se connectant à Sonar verra la tâche de maintenance qui lui a été affectée.

Nouveautés 2011 de Sonar

Sonar est prévu pour se détacher de plus en plus de la base de données afin d’être décentralisé et embarqué. Cependant, il y aura toujours besoin d’un serveur Sonar.

Sonar est disponible en tant que plugin pour Eclipse afin de faire l’analyse du code depuis l’IDE. Cependant, ce plugin n’est pour le moment pas prévu pour Netbeans ou Intellij IDEA.

Sonar permettra d’indiquer de manière objective l’activité de chaque développeur. C'est-à-dire qui ajoute, qui corrige le plus et qui impacte les autres développeurs. Ceci a pour objectif d’améliorer les pratiques de chacun.

Lancement de l'analyse de Sonar

Pour un projet sous Maven, une analyse Sonar se lance depuis la commande : « mvn sonar ».

Liens

Livre

  • Clean Code: A Handbook of Agile Software Craftsmanship de Robert C. Martin

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.