Ceci est un post invité de Golgotha posté sous licence creative common 3.0 unported.
On a parfois du mal à localiser l’origine d’un bug dans une longue requête sql ou un code spaghetti de 5000 lignes écris en 1999 par un biologiste recruté dans une SSII. Bien sur vous pouvez tenter la méthode traditionnelle, essayer de comprendre d’où viens le bug, de façon logique… ou bien gagner du temps et appliquer la méthode que je préfère dans ce genre de situation : la dichotomie.
Le principe est simple, couper en deux le code défectueux (commenter la moitié), re-faire un test, si le code marche, l’erreur viens de la partie commentée ou inversement, ensuite prenez la partie défectueuse et recommencez. Vous tomberez assez rapidement sur le bug, généralement en quelques minutes grand max, sans avoir réfléchi, c’est pratique quand vous devez trouver un bug rapidement en prod dans la panique générale.
Honnêtement c’est ma méthode de debug privilégiée dès qu’on dépasse les 2 heures du matin.
Ah ben t’es bon toi. Si tu coupe un de mes codes sans bug en deux.
Aucune des deux moitié ne marchera sans l’autre.
Mes codes sont des monolithes, comme toutes sculpture respectant les canons du genre.
Ne t’avise pas de couper un de mes codes !!! Sagoin !
Simple et efficace. :)
D’ailleurs
git bisectutilise le même principe pour retrouver le commit à la source d’un bug.Combien de fois j’ai fait ça après 3h d’arrachage de cheveux et finalement trouvé le bug en 10 min la ptite larmichette à l’œil.
Pas évident évident de couper un code en 2. Quand la partie du bas fait par exemple appel à des objets définis dans la partie du haut plus rien ne fonctionne.
Perso j’ai toujours trouvé mes bugs assez facilement avec juste quelques print bien placés. Peut-être l’habitude y fait quelque chose…
je dirai meme plus “grand max” et “petit Sam” :-)
Je vois pas comment cette méthode peut fonctionner..
le fait de couper le code en deux peux amener de nouveaux bugs ..
J’aime quand il faut pas réfléchir.
@ freakazoid, C’est une méthode de débuggage qui est adaptée à certaines situations plus qu’a d’autres en effet. ça ne marche pas partout, tout le temps ;) ça fonctionne particulièrement bien dans les grosses requêtes SQL par exemple.
@foxmask : J’allais faire cette mauvaise blague mais heureusement tu m’a permis de ne pas la faire.
Comme évoqué précédemment ça ne fonctionne pas dans tous les cas loin de là; ça dépend du langage et surtout du type d’erreur.
J’ai utilisé cette méthode pas plus tard qu’hier pour trouver la source d’une erreur dans un code php déclenchant une “segmentation fault”.
Dans ce type de cas de figure la technique est efficace car en commentant le bloc de code en cause, on obtient en effet plein d’erreurs d’exécution mais plus la “Segmentation Fault” ;)
Ou la dicotomie du return/exit. J’exit le code petit à petit, tant que ça plante pas c’est que le bug est plus loin. Si ça plante c’est que mon exit est trop loin dans le code.
Il me semble ici qu’on a une version très bancale du test unitaire. Si t’as pas de grosse méthode de 4 pages (ce qui n’est pas recommandé), t’as pas besoin de couper en morceaux pour tester des bouts.
Il me semble ici qu’on a pas de tests unitaires du tout, surtout. On parle d’un code écrit à l’arrache, avec des verrues qui se rajoutent au fil des années. Les scientifiques par exemple codent en général super crade, mais y’a vraiment pas qu’eux. Y’a qu’à voir le nombre de plugins wordpress où Sam et Max disent qu’ils ne cherchent même pas à corriger les bugs tellement c’est mal fichu.
Dans certains programmes de ma connaissance, je serais hyper content de n’avoir que des méthodes de 4 pages.