2014-05-14 Deux ou trois choses à vérifier avant de rendre un projet informatique
Avant de remettre un programme informatique à un relecteur, il est deux ou trois petites choses qui facilitent le travail de relecture :
- Vérifier que le programme est transmis avec les fichiers supplémentaires dont il a besoin (données, images, ...)
- Vérifier que le programme n'inclut pas de noms de fichiers absolus mais relatifs (je n'ai pas de lecteur d:)
- Si le programme demande des valeurs que l'utilisateur doit rentrer, il faut ajouter dans l'intitulé de la question une valeur par défaut ou recommandée. C'est sans doute évident mais comme je relis plusieurs programmes à la fois, deviner la valeur qui fonctionne et qui ne fait pas planter le programme devient un exercice délicat. Je préfère également quelques lignes au début du programme spécifiant ces valeurs plutôt que d'avoir à les renseigner à chaque exécution.
Lorsqu'un programme ne marche pas et qu'on a passé beaucoup de temps à chercher l'erreur, quoi de plus naturel que d'envoyer un mail à son professeur : "Monsieur, je ne comprends pas, ça ne marche pas et ça devrait marcher". Une fois sur deux, je réponds qu'il me serait utile d'en savoir un peu plus :
- les valeurs des paramètres et les données afin que je puisse reproduire l'erreur,
- la raison pour laquelle vous pensez que cela ne marche pas (pas de convergence, le résultat attendu n'est pas là, ...),
- les directions que vous avez explorées pour comprendre l'erreur (sous-entendu elles se sont révélées infructueuses).
- mettre des print un peu partout pour afficher les valeurs intermédiaires,
- ajouter des tests à des endroits clés du programme pour m'assurer que les tableaux ont la bonne dimension, qu'il n'y a pas de valeurs nulles ou presque nulles lors d'une division, ...,
- réduire la taille du problème ou choisir des valeurs singulières pour obtenir un problème pour lequel je connais le résultat.
Un cas concret : un programme est censé minimiser la longueur du chemin passant par tous les noeuds d'un graphe (problème du voyageur de commerce). L'algorithme implémenté était tout-à-fait correct à ceci près que l'arc liant le dernier noeud au premier était oublié dans le calcul de la longueur du chemin (il ne bouclait pas). Je vous laisse imaginer ce que l'algorithme produisait comme solution et pourquoi ce que j'ai vu au fil des itérations m'a incité à aller inspecter le calcul de cette longueur.
| <-- --> |
Xavier Dupré
|
