Discussion :

[Aurelien.Regat-Barrel]

Passer en mode debogeur c'est quand vraiment tu ne comprends plus pourquoi ton logiciel se comporte bizarrement (et donc j'aurai tendance a dire mauvaise programmation/archi si non maitrise).
Pour moi le debogueur c'est l'outil de derniers recours (un peu comme les outils de detections de fuites memoires en C++ - quand le seul salut c'est leur utilisation c'est que c'est vraiment grave et que tu ne maitrises pas/plus ce que tu fais).
Compter sur l'outil miraculeux (debogeur) pour corriger les pbs je n'ai pas l'impression que ca valorise le developpeur au contraire.

Le problème avec ton discours c'est ce que tu as dit avant:

Personnellement je n'utilise jamais le debogueur et ca ne m'a jamais fait defaut (pourtant je fais beaucoup de C++ et pointeurs). Avec de la rigueur et en appliquant les principes du KISS (et eviter les mille feuilles logiciels 9 fois sur 10 on s'en sort rien qu'avec quelques traces bien placées - mon experience depuis 30 ans de devpt en tout cas).

Le dire ainsi ce n'est pas pareil que de dire "j'ai utilisé le débogueur pendant 20 ans et au final aujourd'hui je travaille mieux sans". D'autant plus que tu parles de pragmatisme vs idéologie... ben quand tu te trouves à bosser sur une "archi non maitrise", tu fais quoi? Tu la recodes intégralement (idéologie) ou tu sors le débogueur (pragmatisme)? C'est pour ça que ton discours me laisse sceptique car pour moi ça sent le "je sais pas (bien) me servir de cet outil alors je préfère le dénigrer / dire qu'il sert à rien".

Les logs sont super utiles / indispensables. Le débogueur est super utile / indispensable. Pourquoi ne prendre que l'un ou l'autre? Pourquoi pas les deux? C'est très pragmatique...

La méthode pro en PROD c'est d'intercepter le crash depuis son appli pour générer un coredump / minidump, packager tout ça avec les logs et envoyer le tout sur un serveur avec création de ticket. En tant que dev, tu récupères le tout, et avec un environnement bien foutu (symbol server), en ouvrant ton minidump le compilo va télécharger les mêmes versions de binaires que ce qui a craché en prod + les symboles de débogage. De cette manière tu te retrouves en 1 minute avec le code source sous les yeux, le contexte d'exécution (pile, registres etc...)... et les logs.

Pour être encore plus pro: au prochain crash similaire chez le client, on peut se rendre compte (via la stack trace) que le problème a déjà été corrigé dans une nouvelle version du logiciel. Et en informer le client immédiatement via une popup. C'est ce que fait tortoise svn par exemple. Si on peut / veut pas mettre un tel système en place soi-même, on peut utiliser bugsplat par exemple.

[jopopmk]

[..] Le debugging est très intéressant pour comprendre un espace relativement restreint. On a quelques lignes qui ne donnent pas le résultat escompté, on les exécutes sous nos yeux jusqu'à voir ou on a merdé. C'est très puissant, très vivant, très dynamique... mais ça présuppose qu'on sait cibler l'erreur, toujours. [..]

Je reviens juste sur ce point : selon le bug ça peut être le débugage qui t'indique où est l'erreur (mon cas : C, Visual Studio, Windows, recherche de bug dans des applications que je n'ai pas codées). Par exemple un bon vieux crash des familles. Tu lances en mode debug, sans point d'arrêt, l'exécution s'arrêtera là où y'a souci. Si c'est au fin fond d'une DLL système, optimisée à la Conan, il suffit de remonter la pile d'appel pour arriver au code maison à incriminer.

Et merci pour "canulant", terme que je ne connaissais pas

[maske]

La méthode pro en PROD c'est d'intercepter le crash depuis son appli pour générer un coredump / minidump, packager tout ça avec les logs et envoyer le tout sur un serveur avec création de ticket. En tant que dev, tu récupères le tout, et avec un environnement bien foutu (symbol server), en ouvrant ton minidump le compilo va télécharger les mêmes versions de binaires que ce qui a craché en prod + les symboles de débogage. De cette manière tu te retrouves en 1 minute avec le code source sous les yeux, le contexte d'exécution (pile, registres etc...)... et les logs.

Ça me semble très spécifique comme méthode. Comment on fait ça sur des systèmes embarqués, par exemple sur une machine en chaine de montage dans une usine ? Ou rien que sur une application qui n'a pas accès à internet ?

Je ne connais "symbol server", tu peux remettre en place exactement le même contexte d'exécution (avec les mêmes valeurs) à partir de ces "symboles" ? Comment ça marche si le crash vient d'une interaction externe ? (la donnée foireuse vient d'une requête par exemple).

Pour être encore plus pro: au prochain crash similaire chez le client, on peut se rendre compte (via la stack trace) que le problème a déjà été corrigé dans une nouvelle version du logiciel. Et en informer le client immédiatement via une popup. C'est ce que fait tortoise svn par exemple. Si on peut / veut pas mettre un tel système en place soi-même, on peut utiliser bugsplat par exemple.

Même remarque : sur les systèmes embarqués dans des grosses machines de production, comment on fait ça ? C'est réthorique, je sais qu'on peut pas =p

[Garvelienn]

Les méthodes sont complémentaires et aucune dispense d'utiliser les autres dans des cas différents.

Juste une petite question : avez vous des astuces pour trouver un bug lorsqu'il n'est déclenché que lorsqu'il n'y a ni le débogueur, ni les traces, ni les prints ? Car chacun change le temps et l'ordre des exécutions de l'application (exemple: une application multi-threadée). Cela vient très souvent d'une mauvaise architecture et/ou gestion de la mémoire mais avant d'arriver à cette conclusion et de trouver le fautif, cela peut être très long. Sachant que Valgrind n'aide pas toujours non plus

[ilatech]

Les conseils de Hartley Brody ne sont pas des 10 commandements de Moïse.
Ce sont des outils que chaque développeur doit avoir dans sa boîte à outils, qui seront utilisés au moment le plus pertinent. Lorsque que je veux planter un clou, je ne vais as utiliser un tournevis, même si j'en ai plein dans ma boîte à outils.

Pour moi tous ces conseils sont utiles, et on peut effectivement en ajouter d'autres (le débogueur par exemple).

[Lung]

Est-ce qu'il y aurait des retours d'expérience (avec peut-être des liens ?) sur le debug de systèmes qui foirent en prod mais qui, quand on les teste en dev, marchent niquel ?
Quelles sont les possibilités ?

Moi dans ces cas-là, je fais du débogage distant.
Selon moi, ça reste le plus rapide et efficace quand toutes les autres solutions ne donnent rien.

[maske]

Moi dans ces cas-là, je fais du débogage distant.
Selon moi, ça reste le plus rapide et efficace quand toutes les autres solutions ne donnent rien.

Ah, ça m'intéresse. Il y a quoi comme techniques ou possibilités de debug à distance ?

[kilroyFR]

Est-ce qu'il y aurait des retours d'expérience (avec peut-être des liens ?) sur le debug de systèmes qui foirent en prod mais qui, quand on les teste en dev, marchent niquel ?

Le débat en soi, lancé par un développeur lambda sur internet (sérieux faut arrêter de faire des news avec ça), n'est pas très intéressant. Tous les développeurs ont leurs techniques, certaines meilleures que d'autres, et souvent limitées à la culture et aux contraintes de leur entreprise. Bref, m'intéresse pas. Par contre j'aimerais bien savoir comment les gens font pour investiguer les problèmes qui arrivent en production, surtout dans les cas où l'appli marche très bien en dev. J'ai rencontré plusieurs fois le problème et la meilleure solution que j'avais à l'époque était de déployer des patchs pour ajouter du log directement sur une install client (bien sûr il m'est arrivé d'oublier de les retirer par la suite...).

Quelles sont les possibilités ?

Personnellement avec du log dans le code aux bons endroits suffit rapidement a trouver les pbs de pointeurs et autres (sur les langages bas niveau).
On a deja eu des devp qui ne comprenant pas pourquoi ca marchait en DEBUG et pas en RELEASE nous ont sorti, c'est un pb compilo, on installe la version DEBUG... ou l'art de botter en touche pour ne pas chercher a comprendre pourquoi ca ne marche pas.

[GrandFather]

C'est vrai que l'absence de l'usage d'un débogueur dans ces recommandations (à l'intention des débutants, rappelons-le) peut étonner de de prime abord, mais c'est finalement assez logique. Les points d'arrêts, l'examen des variables et de la pile d'appel, tout cela est très bien quand on sait dans quelle section de l'application le mettre en oeuvre, et ça n'est pas forcément trivial dans une grosse application. Cela suppose qu'on a cerné, même grossièrement, l'origine du problème, et donc qu'on a utilisé préalablement une ou plusieurs des techniques exposées par l'auteur.

J'en ajouterai une autre, en rapport avec la n°6 et directement tirée de mon expérience auprès de développeurs débutants (et de la mienne propre) : toujours partir d'hypothèses simples concernant l'origine de l'erreur, pour éventuellement partir sur des scénarios plus compliqués (effet de bord, bugs dans les librairies/frameworks utilisés, etc.) quand ça n'a vraiment rien donné. 99% (estimation pifométrique) des erreurs sont assez triviales (typo dans le nom d'une variable, mauvaise imbrication de boucles, indices erronés dans les tableaux, etc.) et seraient repérées plus vite si, par un biais psychologique répandu chez les débutants, les développeurs n'avaient pas tendance à estimer naturellement que la cause est plus complexe qu'elle ne l'est, et à chercher du mauvais côté.

[RedGuff]

Il faut un logiciel intelligent de débogage !
Non bogué, évidemment !

[MikeRowSoft]

Inclure l’outil de débogage et d'édition dans l'application pour que l'utilisateur puisse le débogué lui même. A la base je croyais que .JAR servait aussi a sa.
Mais PHP a réussi a démontré le contraire...

[Songbird]

Ecrire les TU en même temps que le code de production et effectuer des itérations très très courtes de quelques minutes entre écriture et exécution du TU.

Toute autre pratique relève de l'amateurisme.

Je rejoins marco46 concernant les tests unitaires, par contre un peu moins d'accord sur le fait que "pas de test unitaire => amateur".

Y'a des contextes où on ne peut utiliser correctement des TU sous peine de faire pire que si il n'y en avait pas. (e.g. faire des tests unitaires sur la communication d'une BDD, c'est possible, mais sans Mock c'est pas tellement utile, même principe pour la communication avec une infra (API))

Inclure l’outil de débogage et d'édition dans l'application pour que l'utilisateur puisse le débogué lui même. A la base je croyais que .JAR servait aussi a sa.
Mais PHP a réussi a démontré le contraire...

C'est voulu qu'on ne comprenne absolument rien à la majorité de tes commentaires ?

[kilroyFR]

Le problème avec ton discours c'est ce que tu as dit avant:


Le dire ainsi ce n'est pas pareil que de dire "j'ai utilisé le débogueur pendant 20 ans et au final aujourd'hui je travaille mieux sans". D'autant plus que tu parles de pragmatisme vs idéologie... ben quand tu te trouves à bosser sur une "archi non maitrise", tu fais quoi? Tu la recodes intégralement (idéologie) ou tu sors le débogueur (pragmatisme)? C'est pour ça que ton discours me laisse sceptique car pour moi ça sent le "je sais pas (bien) me servir de cet outil alors je préfère le dénigrer / dire qu'il sert à rien".

Les logs sont super utiles / indispensables. Le débogueur est super utile / indispensable. Pourquoi ne prendre que l'un ou l'autre? Pourquoi pas les deux? C'est très pragmatique...

La méthode pro en PROD c'est d'intercepter le crash depuis son appli pour générer un coredump / minidump, packager tout ça avec les logs et envoyer le tout sur un serveur avec création de ticket. En tant que dev, tu récupères le tout, et avec un environnement bien foutu (symbol server), en ouvrant ton minidump le compilo va télécharger les mêmes versions de binaires que ce qui a craché en prod + les symboles de débogage. De cette manière tu te retrouves en 1 minute avec le code source sous les yeux, le contexte d'exécution (pile, registres etc...)... et les logs.

Pour être encore plus pro: au prochain crash similaire chez le client, on peut se rendre compte (via la stack trace) que le problème a déjà été corrigé dans une nouvelle version du logiciel. Et en informer le client immédiatement via une popup. C'est ce que fait tortoise svn par exemple. Si on peut / veut pas mettre un tel système en place soi-même, on peut utiliser bugsplat par exemple.

non non je ne bave sur les debogueurs et je sais largement mieux m'en servir que les nouveaux arrivants qui ne savent coder qu'en C# sans vraiment rien maitriser dans la gestion memoire (fonctionnement GC etc).
Je dis que c'est a utiliser en dernier recours en combinaison des logs bien sur (enfin c'est comme ca que je le vis depuis des années et pour des pb pointus d'ecrasement memoire et autre c'est tres utile mais a la marge).
Je pense que c'est aussi tres utile pour les debutants (comme maintenant coder est a la portee de tout le monde meme si pas informaticien a la base) pour comprendre concretement leur code mais a un moment s'en detacher pour ne le reserver plus qu'aux cas avancés.

J'ai appris a developper sans il y a bien longtemps a une epoque ou ils etaient primitifs et si c'est utile de temps en temps ca n'est personnellement pas un reflexe car je n'ai jamais eu pb d'efficacité a trouve les pbs (je prefere passer du temps sur l'architecture du logiciel) . C'est comme ca, chacun fait a sa façon. Il n'y en n'a pas une plus pro qu'une autre.

Et pour repondre a la question, meme sur un soft non maitrisé je prefere passer un peu de temps a ajouter des traces pour avoir une trame general et savoir identifier rapidement l'origine du pb plutot que de passer en debug + analyse du code dans les grandes lignes.
arf le coup du serveur de symbole et analyse du crash dump. En pratique c'est artillerie lourde pour un resultat pas forcement exploitable et sur embarqué meme pas tu y penses et bonjour les delais de reactivité pour corriger des pbs en prob.
Je travaille sur des applis dans des contextes ou les machines n'ont aucun acces internet (raison de securité) et tu ne fais pas transiter ce que tu veux sur le reseau alors la solution serveur de symbole n'est tout simplement pas applicable.
Ce que tu me racontes est ce qu'une equipe de mon taf ont mis en place (ceux la meme qui considerent que les traces sont inutiles et un soft passé par les TU il n'est nul besoin de traces quand un dump suffira).
Ou comment enfoncer un clou avec une masse - si c'est ca etre "pro" (surement parce que quelqu'un l'a ecrit quelque part) - pour moi ca manque cruellement d'arguments.
Au passage j'ai pu recemment voir avoir la demonstration de la pietre efficacité du systeme... puisque meme l'outil lui meme d'analyse du dump etait foiré.
Resultat, pour corriger un pb sur un logiciel tu te retrouves a devoir deboguer l'outil d'analyse lol !
Resultat plus d'1 journée pour corriger l'outil + le temps pour analyser les dumps quand ils sont exploitables et enfin faire la correction. Bilan 2 jours. Heureusement que ce n'etait pas un pb critique sinon on se serait fait jeter par notre client qui paie pour des delais de reponse/resolution de pbs (delai variable en fonction criticité mais on a des delais qui commencent a 4h max sur pb critiques).

tout ca parce que par ideologie le dev avait decidé que ce n'etait pas l'etat de l'art du dev (mise en place infra etc. et non applicable en prod mais seulement en valid machine donc interet tout relaitf).

[MikeRowSoft]

C'est voulu qu'on ne comprenne absolument rien à la majorité de tes commentaires ?

Non, c'est simplement que je suis dans une stade beaucoup plus visionnaire a cette instant, de temps en temps il y a des commentaires qui déclenche cela, désolé.
J'avais aussi fait la même réflexion a quelqu'un lors d'une formation JAVA/JAVA JEE et il trouvait sa plutôt intéressent de ne pas repassé par une phase compilation complète. Les fans de VCL me comprendront encore mieux en plus des première versions gratuite de de visual studio "sans couche graphique" qui finalement ont abandonnées cette politique.

[Matthieu Vergne]

Ce qui est sûr par contre est que ça n'a guère de succès. {^_^}

[mermich]

Il y a que moi que ca choque de lire ca:

7. Déguiser votre code en commentaire. Les commentaires ne servent pas seulement à décrire certaines actions que vous effectuez ou à laisser des notes dans votre code, mais aussi à demander au runtime de ne pas essayer d’exécuter certaines parties de votre code. Autrement dit, si vous ne souhaitez pas exécuter une partie de votre code, vous pouvez la déguiser en commentaire en ajoutant en début de ligne (et parfois à la fin), le caractère indiquant qu’il s’agit d’un commentaire. Cette approche permet de rendre l’exécution de votre code plus rapide et faciliter la recherche de l’erreur dans le reste du code. Vous devez toutefois vous assurer que les variables utilisées dans le reste du programme ne soient pas dans la partie que vous voulez déguiser en commentaire.

Donc:

• Produire du code mort
• Ne pas savoir sauter des instructions
• Faire de la compilation conditionnelle

[clementmarcotte]

Moi, j'aime bien le pas-à-pas en espionnant les valeurs des variables, avec des lancements fréquents. Et un peu de réflexion. Au pire, essais et erreurs.

Mais, le plus important c'est d'agir en amont et prendre le temps de programmer de façon à empêcher, ou du moins réduire le plus possible, la production de bugs. Parce que, à en croire Steve McConnell, c'est encore ce qui revient le moins cher.

[MikeRowSoft]

Ce qui est sûr par contre est que ça n'a guère de succès. {^_^}

StarOS a fait la même chose pour fournir une interface proche a Windows XP dans sa précédente appellation, pourtant il a fallu changé !

[Programming-Z]

Un IDE avec un module de déboguage est la base pour déboguer correctement.
Tester aussitôt un code développé est aussi très important pour réduire le temps de déboguage de fin de projet..

Après sans IDE le print reste la base.

[Lung]

Ah, ça m'intéresse. Il y a quoi comme techniques ou possibilités de debug à distance ?

Avec Delphi par exemple (je parle de ce que je connais), tu peux installer un tout petit exe sur le poste de l'utilisateur (pour communiquer avec l'IDE de mon poste), recompiler l'application en incluant les infos de débugage (l'exe est pas mal plus gros), et le déployer sur le poste de l'utilisateur.
Ainsi, depuis mon IDE (delphi), je peux exécuter l'application sur le poste de l'utilisateur, en faisant du pas-à-pas sur mon poste. Et de cette façon, être sûr d'être dans le même environnement que lui pour reproduire son problème.
Bien sûr, c'est la méthode de la dernière chance qui nécessite de prendre du temps de l'utilisateur, vu que je monopolise son poste.