La maintenance des programmes

De Wiki EELL.

Version du 26 février 2010 à 16:43

Introduction

Mise à jour: janvier 1991 - 2010

Les programmeur qui ont la charge d'écrire des programmes sont de plus en plus nombreux, d'autres auront la charge de les modifier, et par voie de conséquence la maintenance de leurs programmes prend de l'importance.
Il peut être plus efficace d'écrire un nouveau programme plutôt que de bricoler un programme mal structuré ou difficile à lire. Si le programme est difficile à lire il devra être abandonné ou utilisé tel quel. Il en résulte que la programmation effectuée sans souci de la maintenance doit être considéré comme du temps perdu.

Afin d'améliorer la qualité de vos programmes il est nécessaire de les documenter plus ou moins abondamment, pour être très compréhensibles sans être trop lourds.
Les commentaires alourdissent peu le traitement par le préprocesseur et ne prennent pas de temps à la compilation.

Faites des modules courts, écrivez de nombreuses fonctions dans des fichiers indépendants avec leur module d'épreuve (de test). Le critère de complexité d'une fonction ne devrait pas dépasser 50 lignes de programme ou 10 blocs.

Structurez vos programmes par une analyse bien faite avec un seul point d'entée et un seul point de sortie en dehors des sorties sur erreurs. N'oubliez les procédures d'échappement dans les boucles! (Ignorez les GOTO)

Utilisez des noms courts (pas trop) pour les variables, et des verbes pour les procédures et fonctions. vous pouvez nommer les variables globales avec des préfixes de 3 caractères majuscules suivis d'un souligné qui rappellent le nom de la fonction ou le nom du fichier source auxquels ils sont associés; cela facilite la compréhension dans les autres modules.
En dehors des variables locales évitez les noms courts: i, j, k etc. Ils sont difficiles à retrouver pour les modifier.

Utilisez le générateur de documentation mkd pour contrôler vos codes.

Intégrez les tests unitaires (avec #define TESTS_U) et points de test (#ifdef TEST_U ... #endif) dans vos modules.
Prévoyez le cas échéant les tests d'intégrations (avec #define TESTS_I dans l'entête de version | version.h pour le C) pour évaluer le module quand tout sera au point, avant les tests de validation et la mise en service d'un programme stable.

Si vous n'avez pas la charge d'établir le cahier des charges. exigez un cahier des charge précis afin qu'il n'y ait pas d'ambiguïté dans la qualité du code à rendre; si on vous le refuse précisez les charges qu'on vous a donné dans vos entêtes de programme.

Généralités

1. Si vous avez la charge d'administrer votre système.
2. Si vous avez le choix du langage.
   1. Le C, C++
   2. Le FORTRAN
   3. Le PASCAL
   4. Le BASIC Microsoft
   5. l'ASSEMBLEUR
3. Si vous devez établir le cahier des charges

L'emboitage ou l'organigramme structuré

1. Généralités
2. Analyse du programme
3. Représentation
   1. La séquence
   2. Le Si (conditions), alors: (actions 1), sinon: (actions 2)
   3. Le Tant que (conditions), répéter: (actions)
   4. Le Répéter: (actions), tant que (conditions)
   5. Le Pour toutes (conditions), répéter: (actions)
   6. Le Au cas où (expression), exécuter la séquence du cas.

La programmation

1. Les entêtes (organisation et présentation).
   1. Les entêtes des programmes et modules.
   2. Les entêtes de fonctions et de procédures.
2. Les déclarations de variables.
   1. Les variables globales.
   2. Les variables d'unité ou de module.
3. Méthode d'écriture.
   1. Exemples de commentaires en C C++.
   2. Exemples de commentaires en PASCAL.
   3. Exemples de commentaires en ASSEMBLEUR.
4. Les épreuves (tests)
   1. Les tests intégrés ou d'intégration.
   2. Les tests de validation et d'exploitation.
5. L'exploitation et la maintenance.

Bibliographie

Voir aussi