Affichage des résultats du sondage: Quels sont les meilleurs conseils pour bien déboguer son code ?

Votants
54. Vous ne pouvez pas participer à ce sondage.
  • Beaucoup utiliser la fonction Print

    23 42,59%
  • Commencer avec un code qui fonctionne déjà

    13 24,07%
  • Exécuter votre code à chaque petit changement

    21 38,89%
  • Bien lire les messages d'erreur

    33 61,11%
  • Rechercher le message d'erreur sur Google

    16 29,63%
  • Deviner et vérfier

    7 12,96%
  • Déguiser votre code en commentaire

    8 14,81%
  • Effectuer une recherche dichotomique

    5 9,26%
  • Faire une pause et s'éloigner du clavier

    29 53,70%
  • Savoir comment demander de l’aide

    14 25,93%
  • Autres (à préciser dans les commentaires)

    12 22,22%
  • Pas d'avis

    1 1,85%
Sondage à choix multiple
+ Répondre à la discussion Actualité déjà publiée
  1. #41
    Expert éminent

    Profil pro
    Inscrit en
    juin 2003
    Messages
    5 587
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : juin 2003
    Messages : 5 587
    Points : 8 466
    Points
    8 466
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par kilroyFR Voir le message
    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:
    Citation Envoyé par kilroyFR Voir le message
    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.

  2. #42
    Membre expert Avatar de jopopmk
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2011
    Messages
    1 816
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2011
    Messages : 1 816
    Points : 3 393
    Points
    3 393

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    [..] 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
    Plus je connais de langages, plus j'aime le C.

  3. #43
    Membre éprouvé
    Avatar de maske
    Homme Profil pro
    Escla... Thésard
    Inscrit en
    mai 2008
    Messages
    382
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Finistère (Bretagne)

    Informations professionnelles :
    Activité : Escla... Thésard

    Informations forums :
    Inscription : mai 2008
    Messages : 382
    Points : 1 212
    Points
    1 212

    Par défaut

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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).

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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
    [|]

  4. #44
    Membre confirmé
    Avatar de Garvelienn
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2016
    Messages
    133
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : septembre 2016
    Messages : 133
    Points : 547
    Points
    547

    Par défaut

    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
    «Le management, tel qu’on l’apprend dans les écoles et tel qu’on l’applique ensuite, sous prétexte de «motivation du personnel», organise exactement le contraire, à savoir la démotivation organisée.» - Bernard Stiegler

  5. #45
    Nouveau membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    novembre 2016
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2016
    Messages : 6
    Points : 36
    Points
    36

    Par défaut Utilisation de nos outils au bon moment

    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).

  6. #46
    Expert confirmé
    Avatar de Lung
    Profil pro
    Analyste-programmeur
    Inscrit en
    mai 2002
    Messages
    2 465
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Analyste-programmeur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2002
    Messages : 2 465
    Points : 4 195
    Points
    4 195

    Par défaut

    Citation Envoyé par maske Voir le message
    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.
    L'urgent est fait, l'impossible est en cours, pour les miracles prévoir un délai. Écrivez dans un français correct !!

    Delphi 6#2 Entreprise - Delphi 2007 Entreprise - Delphi 2010 Architecte - Delphi XE Entreprise - Delphi XE7 Entreprise - Delphi 10 Entreprise - Visual studio 2003
    OpenGL 2.1 - Oracle 10g - Interbase (7 - XE) - PostgreSQL 9.3.12

  7. #47
    Membre éprouvé
    Avatar de maske
    Homme Profil pro
    Escla... Thésard
    Inscrit en
    mai 2008
    Messages
    382
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Finistère (Bretagne)

    Informations professionnelles :
    Activité : Escla... Thésard

    Informations forums :
    Inscription : mai 2008
    Messages : 382
    Points : 1 212
    Points
    1 212

    Par défaut

    Citation Envoyé par Lung Voir le message
    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 ?
    [|]

  8. #48
    Membre averti
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    août 2014
    Messages
    231
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : août 2014
    Messages : 231
    Points : 385
    Points
    385

    Par défaut

    Citation Envoyé par maske Voir le message
    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.

  9. #49
    Expert éminent
    Avatar de GrandFather
    Inscrit en
    mai 2004
    Messages
    4 587
    Détails du profil
    Informations personnelles :
    Âge : 47

    Informations forums :
    Inscription : mai 2004
    Messages : 4 587
    Points : 7 037
    Points
    7 037

    Par défaut

    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é.
    FAQ XML
    ------------
    « Le moyen le plus sûr de cacher aux autres les limites de son savoir est de ne jamais les dépasser »
    Giacomo Leopardi

  10. #50
    Membre régulier
    Profil pro
    Caissier
    Inscrit en
    décembre 2010
    Messages
    65
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Caissier

    Informations forums :
    Inscription : décembre 2010
    Messages : 65
    Points : 87
    Points
    87

    Par défaut L'IA !

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

  11. #51
    Provisoirement toléré Avatar de MikeRowSoft
    Homme Profil pro
    sans profession
    Inscrit en
    avril 2013
    Messages
    1 152
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : sans profession

    Informations forums :
    Inscription : avril 2013
    Messages : 1 152
    Points : 0
    Points
    0

    Par défaut

    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...

  12. #52
    Rédacteur/Modérateur

    Avatar de Songbird_
    Homme Profil pro
    Bidouilleur
    Inscrit en
    juin 2015
    Messages
    318
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 19
    Localisation : France, Ardennes (Champagne Ardenne)

    Informations professionnelles :
    Activité : Bidouilleur
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juin 2015
    Messages : 318
    Points : 2 476
    Points
    2 476
    Billets dans le blog
    3

    Par défaut

    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 ?
    Avant de poster: FAQ Rust(WIP); FAQ Dart; FAQ Java; FAQ JavaFX.
    Vous souhaiteriez vous introduire au langage Rust ? C'est par ici ou ici !
    Une question à propos du langage ? N'hésitez pas à vous rendre sur le forum !

    N'hésitez pas à contribuer ou nous faire part de vos retours !
    Release Rust FAQ #7


    Ninja Gaiden meets Metal.

  13. #53
    Membre averti
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    août 2014
    Messages
    231
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : août 2014
    Messages : 231
    Points : 385
    Points
    385

    Par défaut

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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).

  14. #54
    Provisoirement toléré Avatar de MikeRowSoft
    Homme Profil pro
    sans profession
    Inscrit en
    avril 2013
    Messages
    1 152
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : sans profession

    Informations forums :
    Inscription : avril 2013
    Messages : 1 152
    Points : 0
    Points
    0

    Par défaut

    Citation Envoyé par Songbird_ Voir le message
    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.

  15. #55
    Expert confirmé
    Avatar de Matthieu Vergne
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    novembre 2011
    Messages
    1 839
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 1 839
    Points : 5 805
    Points
    5 805
    Billets dans le blog
    2

    Par défaut

    Ce qui est sûr par contre est que ça n'a guère de succès. {^_^}
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  16. #56
    Membre expérimenté
    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2007
    Messages
    760
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : février 2007
    Messages : 760
    Points : 1 336
    Points
    1 336

    Par défaut

    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

  17. #57
    Expert éminent

    Homme Profil pro
    Développeur .NET
    Inscrit en
    janvier 2012
    Messages
    3 773
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Finance

    Informations forums :
    Inscription : janvier 2012
    Messages : 3 773
    Points : 7 679
    Points
    7 679
    Billets dans le blog
    17

    Par défaut

    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.
    À ma connaissance, le seul personnage qui a été diagnostiqué comme étant allergique au mot effort. c'est Gaston Lagaffe.

    À force de vouloir considérer les utilisateurs comme des imbéciles patentés, on risque de se mettre dans le trouble.

    Excel n'a jamais été, n'est pas et ne sera jamais un SGBD, c'est pour cela que Excel s'appelle Excel et ne s'appelle pas Access junior.

  18. #58
    Provisoirement toléré Avatar de MikeRowSoft
    Homme Profil pro
    sans profession
    Inscrit en
    avril 2013
    Messages
    1 152
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : sans profession

    Informations forums :
    Inscription : avril 2013
    Messages : 1 152
    Points : 0
    Points
    0

    Par défaut

    Citation Envoyé par Matthieu Vergne Voir le message
    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é !

  19. #59
    Membre régulier
    Profil pro
    Inscrit en
    février 2007
    Messages
    111
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2007
    Messages : 111
    Points : 119
    Points
    119

    Par défaut

    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.

  20. #60
    Expert confirmé
    Avatar de Lung
    Profil pro
    Analyste-programmeur
    Inscrit en
    mai 2002
    Messages
    2 465
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Analyste-programmeur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2002
    Messages : 2 465
    Points : 4 195
    Points
    4 195

    Par défaut

    Citation Envoyé par maske Voir le message
    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.
    L'urgent est fait, l'impossible est en cours, pour les miracles prévoir un délai. Écrivez dans un français correct !!

    Delphi 6#2 Entreprise - Delphi 2007 Entreprise - Delphi 2010 Architecte - Delphi XE Entreprise - Delphi XE7 Entreprise - Delphi 10 Entreprise - Visual studio 2003
    OpenGL 2.1 - Oracle 10g - Interbase (7 - XE) - PostgreSQL 9.3.12

Discussions similaires

  1. Comment bien déboguer son code ?
    Par D[r]eadLock dans le forum Débuter
    Réponses: 46
    Dernier message: 04/07/2013, 10h48
  2. Réponses: 145
    Dernier message: 15/02/2009, 11h51
  3. Comment bien commencer la Programmation
    Par Le_Faya dans le forum Débuter
    Réponses: 6
    Dernier message: 01/12/2006, 18h39
  4. Memory Managment dans vos programmes
    Par Clad3 dans le forum C++
    Réponses: 11
    Dernier message: 25/07/2006, 01h25

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo