Mise au point de programmes
Langages et programmation
Plan
Introduction
Un programme fonctionne très rarement du premier coup, il faut généralement déboguer. Il y a plusieurs types de bugs. Le plus simple: erreur de syntaxe, vous avez fait une faute de frappe et le programme s'arrête et vous indique où est l'erreur.
Parfois c'est plus grave, un dépassement dans une liste mais là aussi on sait au moins où l'erreur se produit
Le pire c'est lorsque l'erreur ne se produit qu'occasionnellement ou que le programme va bien jusqu'au bout mais en faisant n'importe quoi. Dans de tels cas, l'algorithme élaboré n'est pas bon et n'a pas tenu compte de toutes les contraintes.
Lorsque l'erreur est occasionnelle, la première difficulté et de reproduire l'erreur pour comprendre d'où elle vient. Des jeux de tests variés et biens chosis peuvent permettre d'aider.
Algorithmique
La réalisation d'un programme non trivial demande la réalisation d'un algorithme. Bien souvent, on a tendance à se dire, 'c'est bon, je vois comment je vais faire' sans aucune trace papier. C'est une très mauvaise chose. Il est indispensable de noter l'algorithme afin de pouvoir réfléchir dessus, en discuter, le compléter.
L'algorithme doit décrire les principales étapes que le programme doit réaliser. Chacune de ses étapes peut être redécomposée en un algorithme. Cet algorithme doit être compréhensible de tous, y compris un non informaticien. Il doit être assez court, tenir sur une page, être clair et concis: il ne peut y avoir plusieurs interprétations!
Une fois persuadé de la validité de l'algorithme, on peut passer à la phase programmation.
Débogage
Votre programme comportera des fonctions voire des bibliothèques crées par vous. Il est indispensable de s'assurer que vos fonctions font exactement ce que vous avez prévu. La moindre erreur dans l'une de vos fonctions va fausser votre programme et il arrive bien souvent que l'on se dise, 'ça peut pas venir de là', ou de tout chambouler dans le programme alors que l'erreur est dans une fonction. Tester une partie de programme s'appelle test unitaire. Il est même recommandé de prévoir les tests avant la fonction à tester et de laisser ces tests dans le code accompagnés de commentaires. Ces tests vont contenir plusieurs jeux de test (jeux d'essai ou jeux de données). Par exemple dans le cas du tri d'une liste que l'on veut ranger dans l'ordre croissant, on peut prévoir des tests avec une liste de longueur 1, une liste déjà ordonnées, une liste avec seulement le premier à déplacer en 2nd place, une liste rangée dans l'ordre inverse, une liste avec des valeurs égales, une liste très longue,...
Les environnement de travails 'framework' actuels ont des debogueurs intégrés. Ces derniers permettent de définir des points d'arrêt (carrés ou ronds rouges), d'observer les valeurs des variables (en passant la souris dessus), d'afficher la pile d'appels et d'executer le programme pas à pas. Sinon, il reste la méthode à l'ancienne...afficher les valeurs des variables ou des messages aux endroits sur lesquels on a des soupçons. Il faudra juste penser à nettoyer votre code ensuite. C'est même prévu par certains langages: console.log dans de nombreux langages.
Il est important de comprendre que ce n'est pas parce que vos tests unitaires ont fonctionné que votre fonction est juste! Il faudra parfois remettre en question des choses qui paraissaient acquises, ce n'est pas facile.
Enfin voici une méthode de débogage assez drôle mais sérieuse: la méthode du canard en plastique aussi nommée : « parler à une plante verte ». Oui on peut se demander en quoi cela consiste. L'idée est assez simple en fait. Il s'agit de décrire le code très méticuleusement à une personne n'aillant aucune compétence en informatique. Comme votre auditeur risque de se lasser ou d'avoir mieux à faire, on peut le remplacer par n'importe quel objet du moment que l'on s'exprime à voix haute. Un objet bien visible mais petit auquel on s'adresse joue le rôle de l'auditeur!
