Styles

samedi 28 juin 2008

L'arme absolue de la qualité : la CheckList

Le problème avec l'informatique c'est qu'elle ne supporte pas l'imprécision, l'à-peu-près. La machine sur laquelle tourne un programme n'ayant aucune intelligence en soi, et les langages employés sont finalement, tellement bas niveau qu'il faut toujours penser à tous les détails, ceux qui font toute la différence entre un code qui tourne correctement et un code boggué.

Le diable est dans les détails, c'est sûre, mais l'excellence aussi. On trouve dans tous les bonnes bibliothèques informatiques, des tonnes de livres remplis de bonnes pratiques qu'on doit mettre en oeuvre dans tous les cas possible est imaginable de l'activité de développement d'un logiciel.

Or qui peut se targuer de connaître toutes ses bonnes pratiques, et qui est capable de les utiliser à bon escient et à tous les moments opportuns ? Avoir tous les détails en tête n'est pas humain, puisque le fondement de l'esprit humain est l'oubli. Le programmeur de base est ainsi fait qu'il a une mémoire bien plus volatile que son PC. Comment faire pour qu'un développeur puisse coder proprement sans avoir à lire des milliers de pages de livres informatiques ?

Un des problèmes est que la maîtrise d'une matière demande beaucoup de temps, au minimum une dizaine d'année, quelque soit la matière. Or, en France tout du moins, les ingénieurs informatique ont tous tendance à ne plus vouloir programmer, passé les quelques années d'expérience, principalement par le fait que l'activité de programmation est déconsidérée par rapport aux autres métiers tournant autour. Résultat, les personnes en charge du développement d'application sont souvent jeunes et inexpérimentées, même si elles ont beaucoup de volonté.

La solution classique, simple, c'est bien sur d'utiliser des "checklists", des listes de vérification à chaque étape du processus de développement.

Un projet sans checklist ne peut produire que du code propre à chaque développeur. Il ne sera pas forcément mauvais, mais le code source sera construit sous la forme d'un écosystème avec plusieurs façon de coder différentes, de façon de traiter les erreurs différentes, d'organiser et de nommer les éléments du code, etc.

La checklist est un moyen simple et efficace. Elle peut être employée pour améliorer n'importe quel type d'activité même créative. On la voit malheureusement trop peu employée là où elle aura pourtant le plus d'impact sur la productivité de nos activités.

Dans des domaines où la qualité est un facteur important, les checklists sont au coeur de l'assurance qualité, comme par exemple chez Renault où la validation de la conception d'un nouveau modèle passe par la vérification de toutes les checklists maison, construites au cours de années et rassemblant toutes les bonnes pratiques durement apprises par l'expérience.

La checklist implique un processus minimal :

- un travail

- la vérification de ce travail au regard de la checklist.

La conception et l'utilisation de checklists est bien l'activité fondamentale de ce qu'on appelle couramment "l'assurance Qualité". La vérification à la main des checklists est assez longue et coûteuse, et on a tout intérêt à mettre les vérifications dans un processus automatique, notamment par l'utilisation d'outils.

Au niveau du code source, on dispose de beaucoup d'outils plus ou moins puissants, comme les analyseurs statiques. Chacun peut les utiliser pour soi-même mais cela prend tout son sens quand on effectue les vérifications au niveau du système de gestion des sources, lors d'un "commit" dans Subversion par exemple. Il est aisé d'ajouter des "hooks" aux évènements de base des systèmes de gestion de configuration comme CVS ou Subversion.

On ne peut pas tout vérifier au niveau d'un commit, cela prendrait trop de temps, et les développeurs se mettraient à attendre trop longtemps avant de commiter et y réfléchiraient à deux fois, voire, il ne commiteraient jamais ! C'est pour cela qu'il est intéressant d'effectuer des vérifications régulièrement sur un serveur d'intégration continue.

Aujourd'hui l'intégration continue à le vent en poupe, tout le monde en parle. Mais là où on a le plus intérêt à effectuer des vérifications, c'est aux phases amonts de la simple activité de codage.

Le coût d'une erreur étant dépendant de la phase dans laquelle elle est détectée, une erreur d'expression de besoin coûtera beaucoup moins chère à corriger lors de la phase d'expression de besoin que lors du codage de l'application. Ainsi, on a tout intérêt à vérifier les phases amonts pour éviter de grosses embûches en phase de construction.

On trouve beaucoup de checklists sur le Web, mais je n'ai pas réussi à trouver beaucoup de sites proposant une mise en commun de checklists, notamment par profession.

Ca serait vraiment intéressant de mettre en commun toutes les bonnes pratiques, sous forme de checklist à un seul endroit, directement utilisable sur les projets de développement logiciel. Les livres de Steve McConnell sont particulièrement riches en checklists et méritent vraiment qu'on s'y intéresse.

Aucun commentaire: