Styles

lundi 16 juin 2008

Ni guru, ni hacker, arrêtons l’anarchie dans les routines : utilisons des assertions !

Le principal véhicule de la civilisation est le contrat, l’échange de promesses entre deux parties. Sans contrat, aucune confiance ne peut s’installer, aucun projet ne peut être concrétisé, chacun est dans son coin sans pouvoir compter sur personne.

En informatique on peut dire que c’est souvent l’anarchie dans le code source. Tout le monde veut utiliser tout le monde, toute routine s’arroge le droit de faire appel de n’importe quelle manière à tout autre routine qu’elle trouve dans son scope.

Dans le cas où toute les routines ont été conçues et construites pour être appelées de n’importe où et pour fonctionner sur n’importe quel environnement et dans n’importe quelle condition, il n’y a aucun problème. Or, ce n'est bien sûr jamais le cas.

Quand un développeur code une routine, il a en tête toutes les conditions nécessaires à son fonctionnement : les domaines de valeur possible des paramètres d’entrée, l’état actuel du système sur lequel elle fonctionne (comme par exemple le boutisme de la machine), la place mémoire et CPU disponible, l’état des variables globales à sa portée, les caractéristiques des valeurs de sortie…

Quand on est seul à coder une application il n’y a aucun problème. Dès qu’on est 2 ou plus à développer un même code, c’est l’anarchie [1]. Chacun imagine les conditions nécessaires de fonctionnement de chaque routine. Et pourquoi ne pas expliciter toutes ces conditions ? Pourquoi ne pas établir un contrat d’utilisation pour chaque routine ? L'idée d'utiliser des assertions semble dater d'un papier de C.A.R. Hoare de 1969 :

Sir Charles Antony Richard Hoare, professeur/chercheur britannique en informatique, créateur de la logique de Hoare et de l'algorithme Quicksort.

L'assertion est un des outils les plus utiles pour améliorer la qualité du code source, du point de vue de sa lecture, de sa simplification, de sa robustesse, de sa capacité de réutilisation, et de la facilité de son débogage. Or, c'est bien la technique que j'ai le moins rencontré dans les codes sources que j'ai été amené à lire ou auditer. C'est pourtant un moyen simple à comprendre et à mettre en œuvre. Et en plus, les conditions étant posées par le développeur, ce dernier peut se passer de traiter au niveau de sa routine toutes les conditions qui ne sont pas respectées. Chacun son métier, les vaches seront bien gardées !

[1] En fait, c'est à partir de 3 développeurs que c'est vraiment la galère comme la montré F.B. Brooks en 1975 dans son livre "The Mythical Man-Month". Le coût de la communication entre les développeurs augmente de façon quadratique : n(n-1)/2 : 3 développeurs nécessitent 3 fois plus de communications que 2 développeurs. 4 développeurs nécessitent 6 fois plus de communications que 2 développeurs...

Aucun commentaire: