Qualité De Code

Qu a l i té du code avec Maven 2 Présentation Filière Ingénierie 12 juin 2007 Jean-François Hélie

Agenda

Qualité de code

Validations

Critère d’évaluation

Les outils

Maven 2

Plugin

Démo

Revue de code manuelle

Remarques

Questions

Références

Qualité de code

La qualité du code peut se mesurer de plusieurs façons:

Activement: les tests de qualité sont passés de façon active automatiquement et empêche la génération des binaires d’installation ou voir affichage d’erreur de compilation dans Eclipse

Passivement: les tests de qualité sont formalisés automatiquement sous forme de rapports de tests

Manuellement: la qualité du code est faite de façon manuelle par un développeur expérimenté

Les critères de qualité du code sont les suivants:

un code testé: un code qui possède le comportement attendu par rapport aux expressions de besoins

un code simple et compréhensible: un code avec des noms de packages, de classes, de méthodes et d'attributs qui portent des noms exprimés en langage parlé le plus précis possible (Visiteur est plus précis qu'Utilisateur)

un code standard: un code qui suit les règles de formatage et les conventions spécifié par Sun

un code documenté: un code susceptible d'être compris par de nouveaux acteurs sur le projet sans avoir besoin de lire le code (Javadoc)

un code performant: un code qui répond correctement par rapport aux critères de performances spécifiés en début de projet

un code maintenable et évolutif: un code qui est facile à modifier ou à faire évoluer sans changer son comportement observable de l'extérieur (Utilisation d'interfaces)

un code cohérent: un code écrit de la même forme au travers des différentes applications d'un même Système d'Information

Maven 2

Maven est un outil de gestion de projets, il offre les fonctionnalités suivantes:

Compilation

Gestion des sources

Gestion des dépendances

Intégration avec les IDE du marché

Déploiement

Documentation

Rapport de tests, de couverture de tests, de qualité...

Autres

Les apports de Maven 2 sur les projets sont:

Cohérence: une structure de projets bien définie et une standardisation basée sur les bonnes pratiques

Réutilisabilité: en utilisant Maven 2, on utilise des composants qui ont déjà été éprouvé par la communauté open source

Agilité: il est plus facile de réutiliser des éléments d'un projet à l'autre

Maintenabilité: plus besoin de passer du temps sur la livraison, le packaging... avec Maven on se concentre sur l'application

Maven 2

La revue de code doit s'instrumenter d'outils permettant une revue automatisée de conventions définies pour le développement de l'application.

L'utilisation de Maven 2 permet de façon simple et industrielle la génération de rapports permettant de valider la qualité du code produit:

code testé:

Sunfire Report: rapports d'exécution de tests unitaires

Cobertura: rapports de couverture de tests

code sans bugs:

FindBugs: analyse le code statique pour trouver des bugs courants

PMD: recherche de bugs, de code mort

code standard:

Checkstyle: analyse du code par rapport aux conventions de codage

code compréhensible et documenté:

Javadoc: génération automatique de la Javadoc

code simple et maintenable:

JDepend: niveau de couplage

PMD CPD: duplication de code

code de qualité:

JavaNCSS: analyse le code source et calcule des métriques de qualité

Maven 2

Définition des rapports dans le pom.xml de Maven 2:

Génération des rapports:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> ... <reporting> <plugins> ... C'est Ici qu'on déclare les plugins pour générer les rapports </plugins> </reporting> … </project> mvn site

Maven 2

Déploiement des rapports en ligne

Déclaration dans le fichier pom.xml

Déclaration du serveur dans le fichier M2_HOME/conf/settings.xml

Déploiement des rapports (unzip doit être installé sur la machine distante)

… <distributionManagement> <site> <id>website</id> <url>scp://nomserveur/usr/www/site/canam-hotline</url> </site> </distributionManagement> … <reporting> … … <servers> <server> <id>website</id> <username>login</username> <password>password</password> </server> </servers> … mvn site-deploy

Plugin Sunfire report

Résultats

… <reporting> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-report-plugin</artifactId> </plugin> </plugins> … </reporting> …

Plugin Cobertura

Résultats

… <reporting> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>cobertura-maven-plugin</artifactId> </plugin> </plugins> … </reporting> …

Plugin FindBugs

Résultats

… <reporting> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>findbugs-maven-plugin</artifactId> </plugin> </plugins> … </reporting> …

Plugin PMD

Résultats

… <reporting> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-pmd-plugin</artifactId> </plugin> </plugins> … </reporting> …

Plugin Java Doc

Résultats

… <reporting> <plugins> <plugin> <artifactId>maven-javadoc-plugin</artifactId> <configuration> <minmemory>128m</minmemory> <maxmemory>512m</maxmemory> </configuration> </plugin> </plugins> … </reporting> …

Plugin JDepend

Résultats

… <reporting> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>jdepend-maven-plugin</artifactId> </plugin> </plugins> … </reporting> …

Plugin JavaNCSS

Résultats

… <reporting> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>javancss-maven-plugin</artifactId> <version>2.0-beta-2</version> </plugin> </plugins> … </reporting> …

Plugin JXR

Résultats

… <reporting> <plugins> <plugin> <artifactId>maven-jxr-plugin</artifactId> </plugin> </plugins> … </reporting> …

Démo EASY D E M O

Interpréter les rapports - JDepend

Afferent coupling (Ca) où couplage par dépendance descendante

Le nombre de packages qui utilisent les classes du package analysé peut être un indicateur de mauvaise gestion des dépendances ou être le signe que le package est le centre de l’application. Plus ce nombre est grand, plus il est nécessaire de fragmenter le package.

Efferent coupling (Ce) où couplage par dépendance ascendante.

Le nombre de packages utilisés par les classes du package analysé. C’est un indicateur d’indépendance du code. Plus ce nombre est faible, mieux c’est.

Abstractness (A) où degré d’abstraction.

Pourcentage de classes concrètes par rapport aux classes abstraites. Proche de 0 : package concret, proche de 1 : package abstrait.

Le degré d’abstraction d’un package doit tendre vers l’une ou l’autre des deux borne : 0 ou 1. Une valeur proche de 0.5 montrerait une mauvaise écriture du code.

Interpréter les rapports - JDepend

Instability (I) où degré de stabilité.

Indicateur de résilience du package : propriété de stabilité par rapport à la mise à jour d’autres packages.

Proche de 0 : package stable, proche de 1 : package instable.

Lié aux critères de dépendances ascendante (Ca) et descendante (Ce).

Distance from the Main Sequence (D)

Proche de 0 : le package coïncide avec la « Main sequence », proche de 1 : très éloigné de la « Main séquence ». Dans le cas idéal (D = 0), un package est soit complètement abstrait et stable (A=1, I = 0) ou complètement concret et instable (A=0, I=0). Si D est proche de 1, c’est mauvais et est le signe d’un package mal géré.

Package dependency cycle : Volatility (V)

La volatilité d’un package est sa propension à évoluer au fil du temps. Un V est proche de 0 dénote un package qui est le noyau dur d’une application du fait du couplage avec un grand nombre d’autres packages qui font référence à ce premier.

Interpréter les rapports - JavaNCSS

Le nombre d’instructions sans commentaire (Non Commenting Source Statements : NCSS) corresponde aux commentaires qui auraient du logiquement se trouver dans le code source mais qui font défaut. Il doit être réduit au maximum.

Le nombre de commentaires JavaDoc (JavaDocs) est le nombre de tag JavaDoc trouvés dans le source. Il doit être maximisé.

Interpréter les rapports - JavaNCSS

La complexité cyclomatique (Cyclomatic Complexity Numbers : CCN) correspond au degré d’imbrication des structures de contrôle. Il doit être raisonnable (<3) car il n’est jamais bon d’avoir trop de IF imbriqués, par exemple (valable aussi pour les WHILE, etc…).

Revue de code manuelle

Les rapports d'audit générés de façon automatiques ne suffisent pas à valider la qualité du code par rapport aux exigences définies par le projet. Certaines règles comme le nom des packages, les règles de nommage des classes propres ne sont pas vérifiés de façon automatiquement. De même pour un pattern donné, plusieurs implémentations sont possibles et dépendent du contexte du projet et de choix faits lors de l'architecture applicative. Le choix d'un framework peut aussi avoir des conséquences sur l'architecture, un choix comme le framework Spring pour l'injection de dépendances créé un découplage fort entre les objets et une testabilité facilité

La revue de code manuelle permettra aussi de faire ressortir des règles qui ont été complexifiées involontairement (copie d’objets, …)

Remarques

Les rapports de tests Maven 2 sont à utiliser en interne dans la plupart des cas, car avoir une couverture de tests à 100% n’est pas forcément réalisable et n’a pas forcément de plus value pour l’application que l’on développe.

Fournir les rapports Maven 2 au client peut être fait dans certains cas, comme dans le cas d’une avant-vente d’un framework maison que l’on souhaite vendre au client, ça a été le cas pour le framework LDAP où l’on a utilisé les rapports pour montrer au client le niveau de qualité du produit.

Toutes les métriques de qualité ne sont pas forcément intéressantes, par contre certaines permettent de se focaliser sur certains et de remonter les faiblesses de l’application.

Questions Moi

Références