“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 259 — #269
i
i
i
i
i
i
i
i
5.6 La programmation à grande échelle
259
Cela veut dire que les interfaces des composants souvent utilisés doivent être conçues
soigneusement dès le début.
Voici un exemple simple pour clarifier cette règle. Considérez un composant qui trie
des listes de chaînes de caractères. Il peut changer son algorithme de tri sans changer
son interface. Souvent on peut faire cela sans recompiler le reste du programme,
simplement en éditant les liens du nouveau composant. Par contre, si le code de
caractères est changé, il faudra peut-être changer l’interface. Par exemple, si l’espace
mémoire occupé par chaque caractère change d’un à deux octets (si l’ASCII est
remplacé par l’Unicode). Cela demande une recompilation de tous les composants
qui utilisent le composant changé (directement ou indirectement), car le code compilé
peut dépendre du code de caractères. La recompilation peut être pénible ; changer un
composant de dix lignes pourra impliquer la recompilation de la plupart du programme
si le composant est souvent utilisé.
La conception du système
➤ Le moins possible de dépendances externes
Un composant qui dépend d’un autre, c’est-à-dire qui a besoin de l’autre pour fonctionner, est une source de problèmes de maintenance. Si l’un est changé, l’autre devra être
changé aussi. C’est une source majeure de « délabrement de logiciel » : un logiciel
qui a fonctionné arrête de fonctionner. Par exemple, L A T E X 2 ´ est un système populaire
de typographie dans la communauté scientifique, connu pour la grande qualité de
ses résultats [58]. Un document L A T E X 2 ´ peut avoir des liens vers d’autres fichiers
pour personnaliser et étendre ses capacités. Certains de ces fichiers, appelés paquets
(« packages »), sont relativement standardisés et stables. D’autres sont simplement
des personnalisations locales, appelées fichiers de style. Selon notre expérience, il
est très mauvais pour les documents L A T E X 2 ´ d’avoir des liens aux fichiers de style
dans d’autres répertoires, parfois des répertoires globaux. Si ceux-ci sont changés, les
documents ne pourront plus être traités. Pour aider la maintenance, il est de loin préférable d’avoir des copies des fichiers de style dans chaque répertoire de document. Cela
satisfait un invariant simple : on peut toujours typographier chaque document (selon le
principe : un logiciel qui fonctionne fonctionnera). Cet invariant est un énorme avantage qui l’emporte de loin sur les deux inconvénients : (1) la mémoire supplémentaire
nécessaire pour les copies et (2) la possibilité qu’un document puisse utiliser un fichier
de style vieilli. Si un fichier de style est mis à jour, le programmeur est libre d’utiliser
la nouvelle version dans le document, mais seulement si c’est nécessaire. Entre temps,
le document reste cohérent. Un deuxième avantage est qu’il est facile d’envoyer le
document d’une personne à une autre, parce qu’il est indépendant du reste du système.
© Dunod – La photocopie non autorisée est un délit
i
i
i
i
i
i
i
i
5.6 La programmation à grande échelle
259
Cela veut dire que les interfaces des composants souvent utilisés doivent être conçues
soigneusement dès le début.
Voici un exemple simple pour clarifier cette règle. Considérez un composant qui trie
des listes de chaînes de caractères. Il peut changer son algorithme de tri sans changer
son interface. Souvent on peut faire cela sans recompiler le reste du programme,
simplement en éditant les liens du nouveau composant. Par contre, si le code de
caractères est changé, il faudra peut-être changer l’interface. Par exemple, si l’espace
mémoire occupé par chaque caractère change d’un à deux octets (si l’ASCII est
remplacé par l’Unicode). Cela demande une recompilation de tous les composants
qui utilisent le composant changé (directement ou indirectement), car le code compilé
peut dépendre du code de caractères. La recompilation peut être pénible ; changer un
composant de dix lignes pourra impliquer la recompilation de la plupart du programme
si le composant est souvent utilisé.
La conception du système
➤ Le moins possible de dépendances externes
Un composant qui dépend d’un autre, c’est-à-dire qui a besoin de l’autre pour fonctionner, est une source de problèmes de maintenance. Si l’un est changé, l’autre devra être
changé aussi. C’est une source majeure de « délabrement de logiciel » : un logiciel
qui a fonctionné arrête de fonctionner. Par exemple, L A T E X 2 ´ est un système populaire
de typographie dans la communauté scientifique, connu pour la grande qualité de
ses résultats [58]. Un document L A T E X 2 ´ peut avoir des liens vers d’autres fichiers
pour personnaliser et étendre ses capacités. Certains de ces fichiers, appelés paquets
(« packages »), sont relativement standardisés et stables. D’autres sont simplement
des personnalisations locales, appelées fichiers de style. Selon notre expérience, il
est très mauvais pour les documents L A T E X 2 ´ d’avoir des liens aux fichiers de style
dans d’autres répertoires, parfois des répertoires globaux. Si ceux-ci sont changés, les
documents ne pourront plus être traités. Pour aider la maintenance, il est de loin préférable d’avoir des copies des fichiers de style dans chaque répertoire de document. Cela
satisfait un invariant simple : on peut toujours typographier chaque document (selon le
principe : un logiciel qui fonctionne fonctionnera). Cet invariant est un énorme avantage qui l’emporte de loin sur les deux inconvénients : (1) la mémoire supplémentaire
nécessaire pour les copies et (2) la possibilité qu’un document puisse utiliser un fichier
de style vieilli. Si un fichier de style est mis à jour, le programmeur est libre d’utiliser
la nouvelle version dans le document, mais seulement si c’est nécessaire. Entre temps,
le document reste cohérent. Un deuxième avantage est qu’il est facile d’envoyer le
document d’une personne à une autre, parce qu’il est indépendant du reste du système.
© Dunod – La photocopie non autorisée est un délit