Dans le post précédent Mesurer et contrôler, je disais que les métriques quantitatives telles que le nombre de lignes de code (LOC) ou la mesure de la complexité cyclomatique étaient :

• facilement disponibles – tous les outils d’analyse de code les proposent ;
• exactes – ces mesures ne varient (presque) pas selon les outils ;
• facilement compréhensible pour le management.

Est-ce á dire que les mesures qualitatives seraient difficiles, inexactes et peu utiles ? En fait, tout dépend ce que vous voulez faire, donc du cas d’utilisation. Aujourd’hui, nous verrons un cas idéal : l’amélioration continue de la qualité (Continuous Improvement).

Elisez 12 ou 15 métriques considérées comme critiques et pour lesquelles vous – votre équipe de projet – visez le zéro défaut. Chaque nuit (ou chaque fin de semaine) le code de l’application est analysé et les violations pour ces métriques critiques sont identifiées. Chaque matin (ou chaque début de semaine) l’équipe de projet passe en revue les défauts nouvellement introduits et décide de ses remédiations. Si l’outil d’analyse est plugué avec l’outil de développement, ces remédiations apparaîtront dans la task list de chaque développeur. Vous avez un exemple d’un tel processus ici : Effective Code Review with Sonar.

Quels sont les avantages d’un processus d’amélioration continue :

• Coût de correction de la non-qualité le plus bas, puisque le plus en amont possible dans le cycle de développement. Sooner is cheaper.
• Amélioration continue des compétences : l’équipe de projet se familiarise avec les bonnes pratiques les plus importantes.
• Dette technique contrôlée : les dérives de maintenabilité sont contenues.

Cependant, afin de limiter la charge de travail additionnelle (analyse du code source, exploitation des résultats, répartition des corrections á effectuer, …), il est souhaitable de disposer d’un outillage adéquat :

• Un serveur de gestion de versions qui permette de partager le code source entre les développeurs et d’alimenter l’outil d’analyse de code.
• Si possible, un outil de gestion des tests pour valider chaque version (build).
• Un outil d’intégration qui se charge d’automatiser les tâches de compilation (build), d’analyse de code et de test.

Idéalement, ces outils doivent pouvoir communiquer entre eux, notamment afin de :

• Remonter (upload) dans l’outil d’analyse de code les résultats des tests et identifier, par exemple, les composants les plus ‘dangereux’ pour l’application : composants avec une Complexité Cyclomatique (CC) élevée ou très élevée et insuffisamment testés. Parce qu’ils sont complexes, ces composants présentent un risque élevé d’introduire un défaut en cas d’évolution, et donc doivent être testés prioritairement.
• Descendre (download) dans l’outil de développement la liste des corrections á effectuer, pour chaque développeur.

Il s’agit lá d’un processus complet d’intégration continue, qui suppose des outils complètement intégrés mais également un niveau de maturité suffisant des équipes de développement. L’intégration est importante afin d’automatiser au mieux les différentes phases du processus et limiter la charge de travail additionnelle, notamment pour les développeurs, et donc faciliter l’acceptation de ce nouveau mode de travail.

Je recommanderais également de commencer avec un nombre limité de métriques, afin de ne pas submerger les développeurs de bonnes pratiques á tolérance zéro. Il sera possible d’élargir la cible par la suite, lorsque les développeurs auront gravi cette première marche et adhéré pleinement á cette nouvelle organisation. D’oú l’importance de disposer d’un outillage complètement intégré.

Cette publication est également disponible en Leer este articulo en castellano.