Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Beaucoup utiliser la fonction Print
Commencer avec un code qui fonctionne déjà
Exécuter votre code à chaque petit changement
Bien lire les messages d'erreur
Rechercher le message d'erreur sur Google
Deviner et vérfier
Déguiser votre code en commentaire
Effectuer une recherche dichotomique
Faire une pause et s'éloigner du clavier
Savoir comment demander de l’aide
Autres (à préciser dans les commentaires)
Pas d'avis
Discussion :
Lors de mes études nous avons rencontré un problème et tenté de résoudre le problème de cette façons. Résultat nous avons fait une liste de DLL manquante au lieu de compilé correctement vue que l'EDI de librairie pro VCL n'avait vraiment pas besoin de mise à jour d'aucune sorte.Envoyé par Matthieu Vergne
Très souvent les détails sont submergés sous de très quantités d'informations.
C'est là qu'est le problème. Le message d'erreur c'est moi qui le crée. Comment un autre que moi pourrait savoir ce que ça implique ?
Et tu fais comment pour identifier rapidement (typiquement < 30 min - PROD oblige) les causes d'un BUG sur des serveurs en PROD ?
install chaine de compilation + debogage en pas a pas ?
=> les rares fois ou je l'ai vu faire ca j'avoue que j'etais plus géné pour le developpeur qui passe pour un mauvais (ce qui de plus n'est pas pour rassurer un client) quand tu vois qu'il fait du pas a pas pour comprendre pourquoi son code ne fonctionne pas... (malgré tous les tests unitaires pourtant OK).
Le plus discret restera toujours un petit fichier de log (avec niveau de traces) dans un coin.
On a encore des gens dans ma boite qui partent du principe que si le code passe les TU alors il n'y aura jamais aucun pb en PROD (donc traces etc pour comprendre des eventuels plantages erreurs sont tout simplement ignorées).
Pour moi c'est juste la pretention d'un developpeur qui se croit infaillible. J'en suis un (developpeur) et pourtant j'accepte l'idée de faire des bugs (c'est humain) et que malgré tous les process du monde tu n'empecheras pas l'epreuve du terrain qui te rappeleras cruellement que tu n'est pas infaillible. Ca s'appelle de l'humilité.
Et apres tu passes 2 jours a essayer de reproduire le pb (context d'execution potentiellement tres complexe - ex archi SOA) sur ta plateforme (parce que du pas a pas avec le client dans le dos c'est pas vraiment PRO) pour avoir peut etre un debut d'idée du pb. Vachement productif !
Ce genre de comportement nous coute enormement et aucun efficacité en pratique (tout ca parce qu'un gars a ecrit que c'etait pas bien de faire un printf dans un fichier).
C'est du vécu au quotidien et des dizaines d'heures perdues a comprendre les pbs alors que quelques traces bien placées sont redoutablement plus efficaces.
Apres je n'attends pas qu'une personne me dise que ca c'est mieux (sans vraiment argumenter si on y regarde bien - car dire qu'un debogueur c'est mieux ce n'est pas un argument). Je prefere largement me faire un avis de ma propre experience et a ce jour, il n'y a pas photo. C'est verifié tous les jours (et je trouve meme cela ridicule l'entetement/l'ideologie a ne pas vouloir ajouter des traces dans du code parce que ce n'est pas "l'etat de l'art" - lol).
Je ne vois pas en quoi la methode du debogueur serait mieux ? voir meme plus efficace ? Tu as peur que les traces ralentissent ton logiciel ?
Je verrai meme plutot le contraire. Si pour la resolution du probleme on ne compte que sur le debogeur alors c'est que le code n'est pas maitrisé, logiciel mal architecturé (mauvaise conception), mille feuille technologique etc. et qu'on joue aux apprentis sorciers.
Ce qu'il manque le plus aux developpeurs en 2016 c'est du pragmatisme et moins d'ideologie.
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.
Tu le dis toi-même :
maintenant compare mon "de temps en temps" (je l'ai souligné, y'a une raison) et le "beaucoup" de l'auteur initial, et tu auras compris que finalement ce que tu dis n'est pas différent de moi. Mais pour bien le comprendre, il faut remettre les choses dans l'ordre.
L'auteur initial parle (point 4) de bien lire les messages d'erreurs mais oublie complètement -ce que j'ai critiqué- de dire qu'il faut soi-même en faire en rapport avec l'application qu'on cherche à faire (que ce soit pour générer des exceptions ou pour des traces de log). Et quand tu dis que des traces bien placée sont redoutablement efficace, c'est précisément ce que j'entends quand je dis qu'il faut faire ces messages d'erreur. Tu peux rajouter autre chose pour enrichir tes logs, mais ce qui compte c'est de ne pas attendre d'avoir un soucis pour commencer à chercher, il faut s'y prendre avant plutôt que de trafiquer le code après coup à coup d'ajouts de prints en masse.
Pour ma part, le débogueur je l'utilise très rarement, tout simplement parce que je suis très stricte sur mon développement et que du coup je met des générations d'exceptions à peu près partout où il peut y en avoir. Donc si quelque chose foire, je sais à peu près toujours où et pourquoi tout de suite, le plus long étant de chercher une solution pérenne. J'utilise le débogueur tellement rarement que ça doit être autant que des prints. Cela dit, ta critique se centre sur la nécessité de générer du log, ce qui présuppose d'avoir fait ce qu'il faut pour en générer. L'auteur initial parle de rajouter des print (ou de commenter du code) pour chercher où ça casse a posteriori. Et c'est là que se situe ma critique... ainsi que visiblement la tienne.
Donc si l'humilité consiste à avoir conscience de ses lacunes, il me semble que tu as (aussi) encore un peu de travail à faire de ce côté là.
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 {^_^})
Je n'ai pas pris au mot pres ce qui est ecrit dans l'article initial et j'entendais bien uniquement la mise en place d'un systeme de log rien de plus (mais pas dans les exces comme il l'ecrit et a posteriori ce qui me semble plutot une mauvais pratique - mode panique).
Le debogeur comme outil miraculeux je laisse ca aux autres (d'ou mon etonnement de voir qu'on encense sa pratique quand dans la plupart des cas elle n'est utilisée qu'en marge (et pas l'inverse)).
Je pense que c'est l'idee generale qu'il faut conserver cad, 1ere brique a mettre en place dans une archi logiciel c'est le composant de log, le reste n'en est que plus facilité par la suite.
Concernant l'humilité je ne crois pas avoir deroulé de phrases toutes faites qui classifierait les bonnes et les mauvaises pratiques, chacun a celles qui lui conviennent le mieux.
Je suis developpeur donc par definition je ne suis pas parfait et n'en ai aucunement la pretention. En informatique on entend trop souvent des grands principes jetés ca en la en regle absolue (comme etant l'etat de l'art) - ce sont des choses qui passent comme la mode.
La seule qualité a laquelle j'attache le plus d'importance pour un developpeur etant le pragmatisme (et les idéologies/effets de mode etc. je les laisse aux autres).
Ni ce que j'ai écrit, de toute évidence, ce qui t'a amené à me reprocher à moi ce qui lui est reprochable à lui. Oui l'erreur est humaine, mais les grosses bourdes de ce genre c'est plus une question de négligence que d'imperfection. Et sortir les grandes phrases d'erreur humaine et d'humilité dans ces conditions, ça résonne plus comme une excuse qu'autre chose.
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 {^_^})
Tiens c'est marrant, il y a eu un débat similaire il y a quelques temps dans la section C++. Je m'étais fait traiter de "suffisant" pour avoir oser dire que j'utilisais moins souvent le débogueur au profit d'autres outils complémentaires.
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.
Ç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).
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
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).
Ah ben on est bien d'accord alors
"en combinaison des logs bien sur"
Là je suis pas d'accord. Avec Visual Studio en tous cas, c'est assez simple et rapide à mettre en place. Et quand il s'agit de trouver où se situe le déréférencement du pointeur null ou la levée d'exception, c'est très pratique. le log permet ensuite de comprendre pourquoi on en arrivé là - ça se complète.
En embarqué, le dump ne peut parfois toujours être généré et stocké localement pour un futur export (avec les logs) quand le technicien passe. Dans ce cas les logs sont critiques non pas parce que c'est un outil plus puissant que le dump, mais parce que c'est le seul dont on dispose (nuance!).
Je suis pas sûr de raconter la même chose, car pour moi une appli sans fichier de log, c'est de l'amateurisme, TU ou pas TU. Faut pas mettre la charrue avant les boeufs.
Le côté "être pro", c'est vis à vis du support client. Pour l'avoir vécu, quand un soft te pète dans les pattes, et que 10 secondes plus tard, il t'informe que ton problème est corrigé et que c'est dispo à telle URL, ben moi j'ai trouvé ça très pro!
Si on va dans cette direction, je peux moi aussi te donner une exemple de piètre efficacité des fichiers de logs : des logs tellement volumineux (plusieurs Go) qu'il ne sont pas exploitables (ne serait-ce que les ouvrir dans un éditeur de texte) et qu'il faut coder des outils spécifiques (4 jours de dev...) pour extraire les lignes dignes d'intérêt... Et c'est tellement fréquent comme fonctionnement que y'a des produits spécialisés dans l'aggrégation et le filtrage de tout ce bruit (kibana...). Pour autant, j'en ai pas conclu (dans l'exemple précédent) que les logs étaient un mauvais outil, juste que c'était fait n'importe comment dans ce contexte.
Ce que je contacte souvent, c'est que c'est plus facile de blâmer l'outil que de remettre en question la façon dont on l'utilise. C'est pour ça que j'ai toujours une petite alerte dans ma tête quand quelqu'un dit "ce truc là ça sert à rien c'est nul". Je ne me souviens pas d'un exemple où, après approfondissement, on ne s'est pas rendu compte que, en fait, la personne ne savait juste pas s'en servir correctement.
Et oui, "l'etat de l'art du dev" est une façon parmi d'autres de déguiser son incompétencetout comme le terme "pragmatisme" peut servir (aussi) à cela (je ne te vise pas attention,j'ai aimé nos échanges).
200% d'accord !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.
En ce qui concerne "Beaucoup utiliser la fonction Print" ou "Déguiser votre code en commentaire", le jour où un lead dev vous demande de faire ça, je vous invite à lui jeter du café bouillant à la figure.
Pour "Exécuter votre code à chaque petit changement" - Je vous souhaite bonne chance si votre environnement met 30 secondes à s'exécuter à chaque lancement de l'application.
Quant à "Effectuer une recherche dichotomique" : C' est encore mieux ! ça permet de combiner la lenteur de l'exécution + la fonction Print + le code commenté à souhait ! le meilleur moyen de créer des ancres de bateau
ça doit être la joie de bosser avec Hartley
debug pas a pas evidemment :/. Lire les logs (donc logger).
Un print après chaque instruction affichant les nombres de 1 à n, n étant le nombre total d'instruction.
Si le programme plante, je vois quelle instruction a été exécutée avec succès en dernier, et par extension laquelle fait planter. J'enlève donc cette instruction en partant du principe que le programme ne pourra que mieux fonctionner sans. Je répète l'opération jusqu'à ce qu'il n'y aie plus aucun bug.
Ça y'est, c'est prêt à partir en prod !
Ça c'est du pragmatisme ! {^o^}
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 {^_^})
Du fait que le "print" passe en premier et qu'aucune référence à un outil de débugage n'est faite, je suppose que le monsieur nous parle de débogage de Javascript (enfin moi c'est ce que j'appelle le débugage "JS style", maintenant avec la montée du JS il existe peut-être des vrais débugueurs pour ce langage).
edit : ortho
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 ?
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
L'IA !
Il faut un logiciel intelligent de débogage !
Non bogué, évidemment !
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...
Répondre avec citation
Partager