Discussion :

[GeoffreyOnRails]

Bonjour,

Je vous présente mon premier article sur le forum intitulé :

La correction de bogues en sept étapes

Cet article essaie de prendre du recul sur la démarche de correction de bogues et propose une méthode quel que soit le système à réparer.

La correction de bogues occupe une place importante dans la vie d'un développeur. Entre les bogues qui remontent durant la phase de développement et la phase de pure maintenance, nous sommes littéralement infestés.

Il faut bien reconnaître que les bogues ont un certain talent pour apparaître sous des formes très variées (erreur système, problème fonctionnel, soucis de performance…) et avoir des causes toutes aussi diverses : mauvaise configuration, mauvais choix d'algorithme, mauvais format de données, cas particulier non pris en compte…

Néanmoins, il est surprenant de constater que malgré le temps qu'on y consacre, le « bug fixing » est un sujet parmi les moins discutés dans la communauté des développeurs, un peu comme si le simple fait d'évoquer le mot « bug » accroissait le risque de passer sa journée à s'en occuper.

Par conséquent il s'agit peut-être de l'un des domaines d'activité du développeur parmi les moins matures, où la plupart y vont un peu « au feeling ». L'objectif de ce billet va donc être de remédier à ça en proposant une méthode pour la résolution de bogues.

N'hésitez pas à partager vos opinions et vos expériences, qu'elles confortent la démarche ou au contraire la remette en cause!

[MichaelREMY]

D'expérience, l'étape 3 "circonscrire le problème" est la plus dure à passer.
Car souvent on confond "bug" et "fonctionnalité" issue et mal expliquée du CDC.

Un bug à corriger n'est pas aussi simple que corriger le pourquoi (2+2 fait=5) hélas...non . mais plutôt trouver pourquoi ce n'est pas "2+3 = 5" car souvent ce n'est pas un bug, mais une mauvaise "orientation ou compréhension ou explication" du besoin.
En gros, le bug n'est pas l'absence de la conséquence attendue, mais l'absence des conditions pour obtenir la conséquence attendu (je sais, ce n'est pas facile à comprendre cette phrase, et je n'ai pas utilisé le mot de prédicat pour ne pas en perdre sur le chemin...).

Les bugs simple (2+2!=4) sont vus et corrigés lors des tests primaires.

[GeoffreyOnRails]

D'expérience, l'étape 3 "circonscrire le problème" est la plus dure à passer.
Car souvent on confond "bug" et "fonctionnalité" issue et mal expliquée du CDC.

Un bug à corriger n'est pas aussi simple que corriger le pourquoi (2+2 fait=5) hélas...non . mais plutôt trouver pourquoi ce n'est pas "2+3 = 5" car souvent ce n'est pas un bug, mais une mauvaise "orientation ou compréhension ou explication" du besoin.
En gros, le bug n'est pas l'absence de la conséquence attendue, mais l'absence des conditions pour obtenir la conséquence attendu (je sais, ce n'est pas facile à comprendre cette phrase, et je n'ai pas utilisé le mot de prédicat pour ne pas en perdre sur le chemin...).

Les bugs simple (2+2!=4) sont vus et corrigés lors des tests primaires.

Merci pour ton retour!
Je suis assez d'accord de par ma propre expérience, mais c'est plutôt teinté informatique d'entreprise.

Il y avait assez récemment un article (http://jeux.developpez.com/tutoriels...-multijoueurs/) sur comment déboguer un jeu vidéo en réseau (avec les interactions de plusieurs joueurs à des dates très précises), et il apparaît nécessaire d'avoir des outils assez sophistiqués pour pouvoir passer l'étape 1 "reproduire le bug" de manière systématique.
Dans des codes assez mal conçus (gros legacy), l'étape 4 : "s'assurer que la correction ne va rien casser autour", peut devenir très pénible également.

Du coup j'ai envie de dire que la difficulté de chaque étape dépend beaucoup de la situation.