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
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
On ne parle pas des messages d'erreurs custom, on parle des messages que génère l'environnement d’exécution ? par exemple.
Il y a souvent une référence.
En Java avec les Exceptions qui sont throw c'est assez fun, on voit qu'une méthode a appelé une méthode qui a appelé une méthode qui a appelé une méthode (...) et PAF! ça plante.
Rechercher des messages d'erreurs dans un moteur de recherche c'est souvent utile quand on sait un peu près d'où vient l'erreur.
Mais parfois ça ne sert à rien de rechercher, vu que quelque part notre erreur est unique (framework, config, tout ça).
Keith Flint 1969 - 2019
Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
Un peu de programmation réseau ?
Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.
Le print reste l'incontournable dans tous les langages.
Surtout avec tous les maudits frameworks qui blackboxent ce qu'ils font, c'est parfois difficile de débuguer.
Si la réponse vous a aidé, pensez à cliquer sur +1
Et alors ? Qui a dit que ça marchait à tous les coups ? Sans ça, tu aurais réussi à faire mieux ? Si c'est le cas c'est que tu as sauté trop vite sur la solution de facilité, et donc tu ne peux t'en prendre qu'à toi-même (et tes camarades).
Dans ce cas oui ça n'aurait aucun sens, mais ce n'est visiblement pas ce dont parle l'auteur des conseils.
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 {^_^})
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).
Non, j'implémente très lentement, la plus part du temps aucun algorithme écrit à l'avance. Et encore moins de code source.
Je suis vraiment loin d'être quelqu'un qui ira modifier le code source d'une application directement dans le projet pour "plombé" une sécurité. Imagine un défunt étudiant d'une grande université en sommeil.
Vive les multiples librairies du C++. La plus part du temps il y a rien à rajouter.
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.
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 {^_^})
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 !
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
Plus je connais de langages, plus j'aime le C.
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 rigolo, ça relance l'éternel débat debugging contre trace/log. En bref, faut-il suivre le cheminement fautif de l'extérieur, ou bien de l'intérieur?
Ben, moi j'aime bien les deux, en fait. Infanterie ET cavalerie. fromage ET dessert. Brunes ET blondes. Traces ET debugging.....suivant le contexte.
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.
Quand on fait du batch de masse, et qu'on a une erreur infime après deux millions d'enregistrements, l'erreur est probablement limité à quelques cas spéciaux, et il faut pouvoir établir des traces de comportement complètes, histoire de pouvoir dichotomiser. J'ai déjà eu une erreur à cause d'un seul client, sur plusieurs centaines de milliers. Mais sans traces ciblées, impossible de savoir lequel.
Une fois le cas fautif identifié, on peut repasser au debugging pour voir ou il fait planter le cas en question, avec un point d'arrêt un peu intelligent. Sur le client 33130, et pas un autre. Et on trouve.
J'ai aussi remarqué, en traitement par lots de masse(c'est certainement une mauvaise pratique en transactionnel, et aussi dans la plupart des autres contextes), qui mettre des compteurs complets, détaillés, à la fin de chaque exécution, était une pratique qui permettait de réduire fortement le temps de débug. du genre "3701 enregistrements lus, 3701 enregistrements validés, 523 clients pros ignorés, 3178 clients privés traités, 24 clients privés corrigés, 3154 clients privés inchangés, 3178 clients privés écrits". Parce-que si les chiffres ne collent pas, on sait tout de suite ou chercher. C'est un peu canulant à mettre en place, mais à la maintenance, ça fait gagner un temps fou. Mais c'est du spécifique à un cas particulier. Dans d'autres cas(peut-être le tien, ami lecteur), c'est juste de la foutaise.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager