En me demandant de quoi émanent les bugs de mon propre code, j'ai l'impression que ça se résume en 1 seule chose : au moment de coder, je n'ai pas prévu (ou pas envie, ou...) tous les cas possibles, par exemple :
- une fonction xxxx me renvoie 'vrai' ou un code d'erreur, et je ne teste jamais (paresse)
- je présuppose que mes variables d'entrée, quelles que soient leur provenance, sont correctement formées (grosse paresse)
- en codant, je ne parviens pas à gérer la multiplicité des cas pouvant se produire, en j'en loupe (limite de mon ptit cerveau)
(Je précise que même que je ne fais pas ces erreurs partout, tout le temps (non mais). Mais quand j'en fais, ça vient de là).
Ma liste est certainement partielle, ce serait intéressant de la compléter!
Et comment résoudre ça? Les tests systématiques sont longs à écrire, pas franchement marrants, et alourdissent le code (à la lecture surtout).
<fantasme>
Je rêve d'un IDE sans code (enfin si, mais beaucoup moins), où programmer se résumerait à : expliciter les flux d'entrée/sortie, et définir les actions en fonction des cas possibles...
Bon avant de recourir à des substances psychédéliques pour me suivre dans mon raisonnement, lisez plutôt cet exemple :
Objectif : réaliser une application permettant à un utilisateur de saisir son nom et sa date de naissance, puis d'afficher 'bonjour'+son nom, ou 'bon anniversaire'+son nom si c'est le cas.
J'ai une interface, 2 champs de saisie et un bouton pour valider (même si je préfèrerais un niveau d'abstraction + haut), un flux d'utilisateurs venant sur cette interface pour faire de la saisie. J'ai aussi un traitement (calcul du message à afficher) et une seconde interface affichant le résultat du traitement. Jusque là ça va.
Je construis mon appli : 1ère interface, 2 zones de saisie, un bouton qui valide, et j'ajoute le flux d'utilisateurs.
Avec les règles actuelles, d'IDE voit que mes users peuvent saisir (ou pas) ce qu'ils veulent dans 2 champs, cliquer sur le bouton, et bien sûr arrêter d'utiliser mon appli. L'IDE injecte des entrées possibles (=simule des utilisateurs) qui font un nombre aléatoire d'actions parmis celles possibles, puis s'arrêtent. Il conclut bien vite que mon programme ne fait rien et que 100% des utilisateurs quittent le programme là, sans qu'il ne se passe rien.
Puis je crée mon calcul (vide), et j'associe le clic sur le bouton à l'action 'envoie les données des 2 champs au calcul'. Pouf l'IDE me trouve 2 cas distincts : celui des utilisateurs qui cliquent, et celui des utilisateurs qui cliquent pas. Je commence mon calcul (là, du code: si date saisie=date du jour, alors message commence par "bon anniversaire " sinon "bonjour";ajouter le nom saisi au message).
En créant ma condition 'SI', l'IDE me trouve (toujours par simulation) 3 cas : test vrai, test faux, problème de prérequis (je ne suis pas sûr que la date saisie est bien une date, et qu'elle répond au format voulu). Il (l'IDE) me dit que pour 99% des personnes déclenchant le calcul, il ne se passera pas ce que j'ai prévu. A moi maintenant de rattacher ce flux à quelquechose (message "saisie incorrecte"), ou de faire en sorte que ce flux n'existe plus (tests à la saisie).
En gros à l'aide de tests successifs et aléatoires, l'IDE de mes rêves m'aide à identifier tous (ok beaucoup) les cas possibles, et à les gérer. Mon programme n'est plus orienté objet ou procédural, il dépend du flux utilisateur, et ça tombe bien, parce que c'est comme ça qu'il fonctionne, et c'est comme ça que les gens tombent sur des bugs.
</fantasme>
<retour sur terre>
Waouh, ça a l'air bien complexe, assez lourd à la longue (pour un programme de 10 millions de lignes de code, ça en fait des cas à tester!), ça demande un moteur de génération de code source (ou compilateur) pas évident, etc.
</retour sur terre>
Mais si c'était finalement faisable, à votre avis, ça vaudrait le coup ou pas ? Est-ce qu'il 'suffit' de faire ça pour diminuer fortement, voire éradiquer, les bugs et autres nuisances ?
# I had a dream...
Posté par qstone . En réponse au journal Comment résoudre la "crise du logiciel" ?. Évalué à 3.
- une fonction xxxx me renvoie 'vrai' ou un code d'erreur, et je ne teste jamais (paresse)
- je présuppose que mes variables d'entrée, quelles que soient leur provenance, sont correctement formées (grosse paresse)
- en codant, je ne parviens pas à gérer la multiplicité des cas pouvant se produire, en j'en loupe (limite de mon ptit cerveau)
(Je précise que même que je ne fais pas ces erreurs partout, tout le temps (non mais). Mais quand j'en fais, ça vient de là).
Ma liste est certainement partielle, ce serait intéressant de la compléter!
Et comment résoudre ça? Les tests systématiques sont longs à écrire, pas franchement marrants, et alourdissent le code (à la lecture surtout).
<fantasme>
Je rêve d'un IDE sans code (enfin si, mais beaucoup moins), où programmer se résumerait à : expliciter les flux d'entrée/sortie, et définir les actions en fonction des cas possibles...
Bon avant de recourir à des substances psychédéliques pour me suivre dans mon raisonnement, lisez plutôt cet exemple :
Objectif : réaliser une application permettant à un utilisateur de saisir son nom et sa date de naissance, puis d'afficher 'bonjour'+son nom, ou 'bon anniversaire'+son nom si c'est le cas.
J'ai une interface, 2 champs de saisie et un bouton pour valider (même si je préfèrerais un niveau d'abstraction + haut), un flux d'utilisateurs venant sur cette interface pour faire de la saisie. J'ai aussi un traitement (calcul du message à afficher) et une seconde interface affichant le résultat du traitement. Jusque là ça va.
Je construis mon appli : 1ère interface, 2 zones de saisie, un bouton qui valide, et j'ajoute le flux d'utilisateurs.
Avec les règles actuelles, d'IDE voit que mes users peuvent saisir (ou pas) ce qu'ils veulent dans 2 champs, cliquer sur le bouton, et bien sûr arrêter d'utiliser mon appli. L'IDE injecte des entrées possibles (=simule des utilisateurs) qui font un nombre aléatoire d'actions parmis celles possibles, puis s'arrêtent. Il conclut bien vite que mon programme ne fait rien et que 100% des utilisateurs quittent le programme là, sans qu'il ne se passe rien.
Puis je crée mon calcul (vide), et j'associe le clic sur le bouton à l'action 'envoie les données des 2 champs au calcul'. Pouf l'IDE me trouve 2 cas distincts : celui des utilisateurs qui cliquent, et celui des utilisateurs qui cliquent pas. Je commence mon calcul (là, du code: si date saisie=date du jour, alors message commence par "bon anniversaire " sinon "bonjour";ajouter le nom saisi au message).
En créant ma condition 'SI', l'IDE me trouve (toujours par simulation) 3 cas : test vrai, test faux, problème de prérequis (je ne suis pas sûr que la date saisie est bien une date, et qu'elle répond au format voulu). Il (l'IDE) me dit que pour 99% des personnes déclenchant le calcul, il ne se passera pas ce que j'ai prévu. A moi maintenant de rattacher ce flux à quelquechose (message "saisie incorrecte"), ou de faire en sorte que ce flux n'existe plus (tests à la saisie).
En gros à l'aide de tests successifs et aléatoires, l'IDE de mes rêves m'aide à identifier tous (ok beaucoup) les cas possibles, et à les gérer. Mon programme n'est plus orienté objet ou procédural, il dépend du flux utilisateur, et ça tombe bien, parce que c'est comme ça qu'il fonctionne, et c'est comme ça que les gens tombent sur des bugs.
</fantasme>
<retour sur terre>
Waouh, ça a l'air bien complexe, assez lourd à la longue (pour un programme de 10 millions de lignes de code, ça en fait des cas à tester!), ça demande un moteur de génération de code source (ou compilateur) pas évident, etc.
</retour sur terre>
Mais si c'était finalement faisable, à votre avis, ça vaudrait le coup ou pas ? Est-ce qu'il 'suffit' de faire ça pour diminuer fortement, voire éradiquer, les bugs et autres nuisances ?