IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Débats sur le développement - Le Best Of Discussion :

Quelle est la place du débogage dans la programmation ?


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2014
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Septembre 2014
    Messages : 194
    Points : 12 291
    Points
    12 291
    Par défaut Quelle est la place du débogage dans la programmation ?
    Quelle est la place du débogage dans la programmation ?
    Les formateurs de CodeUnion pensent qu’elle est la compétence la plus précieuse que nous pourrions enseigner

    Si vous écrivez un programme et qu’il marche du premier coup sans aucun problème, c’est que quelque chose cloche. Voilà un fait dont tout le monde (ou presque) est d’accord.

    En effet, les développeurs les plus expérimentés savent bien que le processus de débogage est une phase très importante de la programmation. D’ailleurs ça prend généralement plus de temps pour déboguer un code que de l’écrire, on a même créé des outils spéciaux rien que pour ça.
    Ce qui fait du débogage une compétence essentielle que tout apprenti programmateur devra s’y intéresser.

    « Si les novices vont dépenser beaucoup de leur temps à déboguer, alors ne devrions-nous pas, en tant qu'enseignants, dépenser une quantité proportionnelle de temps à leur enseigner comment bien le faire? », se demandent les formateurs de CodeUnion dans un billet de blog, ceci parce qu’ils avaient remarqué que la plupart des questions posées par leurs élèves étaient dues à une difficulté à détecter pourquoi leur code ne marchait pas comme prévu. Selon eux, chacun devrait se poser 3 questions lorsqu’il rencontre un problème :

    1. Qu'est-ce qui me fait dire que mon code ne fonctionne pas ?
    2. Qu'est-ce que mon code est censé faire et pourquoi ?
    3. Qu'est-ce que mon code fait à la place et comment je le sais ?

    Cette méthodologie serait l’une des bonnes pratiques qu’un programmeur expérimenté intègre dans ses habitudes, même s’il le fait inconsciemment. Une autre difficulté réside dans le fait d’énumérer toutes les hypothèses assumées dans son algorithme ainsi que son code de sorte à pouvoir les tester une à une. Aussi, les apprentis programmeurs ne savent souvent pas poser les bonnes questions. En effet, lorsqu’on demande de l’aide à un expert, il faut bien lui définir ce que le code est censé faire et ce qu’il fait à la place.

    « Il est impossible de préparer vos élèves pour chaque situation future possible, même en supposant que vous les connaissez toutes. Cela signifie que la meilleure chose à faire est de leur apprendre à s’orienter en cas de confusion ou dans des situations incertaines […] Notre travail est donc de minimiser les mauvaises habitudes de nos élèves tout en les aidant à développer le plus efficacement », peut-on lire dans le billet de blog.

    Au final, les formateurs de CodeUnion pensent que le débogage est « la compétence la plus précieuse que à enseigner », et qu’elle est beaucoup trop négligée dans les formations. Pourtant, c’est elle « qui facilite, par la suite, l'acquisition de toutes les autres compétences de programmation ».

    Source : CodeUnion

    Et vous ?

    Pensez-vous aussi que le débogage est la compétence la plus importante à enseigner ?

    Pensez-vous que le débogage est négligé dans les formations en informatique ?

    Quels sont les critères qui font de quelqu'un « un expert du débogage » ?

  2. #2
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    Responsable Architecture logicielle
    Inscrit en
    Décembre 2008
    Messages
    541
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Responsable Architecture logicielle
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Décembre 2008
    Messages : 541
    Points : 1 729
    Points
    1 729
    Par défaut
    Bien-sûr que l'enseignement du débogage est primordial.
    Cela dit ce n'est pas le plus important dans l'enseignement, il y'a tellement de domaines qui font un bon développeur .

    Cela dit, sur beaucoup de projet (métier interne) on néglige des éléments essentiels :

    1) Tests Unitaires

    2) Débogage par IHM ( Ou débogage par création de fonctionnalité hors spécification)

    Cette notion peut paraître stupide et effraye beaucoup d'entreprises mais le débogage graphique peut être fondamental.

    Par exemple sur un moteur de tarifs pour le transport, il est important de prévoir des outils statistiques pouvant servir aussi bien pour le métier que pour le débogage.
    - Carte géographique d’analyse thématique : distance/coût, etc
    - Graphique de moyenne, écart type , dégressivité, ...


    En effet mettre en oeuvre ce genre de chose est plus intéressant que le débogage avec tableau car il s'adresse aussi bien au DEV qu'au métier,
    cela peut permettre de voir rapidement des anomalies en production (force utilisateur).
    Cela dit les entreprises ont une politique de suppression de l’inutile, et préfèrent perdre plus d'argent en maintenance ( en plus avec le turnOver massif c'est catastrophique)



    Le débogage ne doit pas corriger que les bugs/plantages facilement visibles.

  3. #3
    Membre régulier
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    Juillet 2011
    Messages
    30
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Juillet 2011
    Messages : 30
    Points : 111
    Points
    111
    Par défaut
    Un des gars qui m'a formé disait: " on devrait pas avoir besoin de débugger, si on en a besoin, c'est que le développement est pourri, recommence" c'est pas faux mais débugger fait gagner beaucoup de temps et permet d'apprendre de ses erreurs

  4. #4
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 113
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 113
    Points : 32 951
    Points
    32 951
    Billets dans le blog
    4
    Par défaut
    L'utilisation du debugger est essentiel. Croire qu'on peut écrire un code tout bon, c'est valable que pour des projets étudiants (et encore), où le nombre de lignes total ne dépasse les quelques milliers dans le meilleure/pire des cas.
    Dans la vraie vie, tu développes ton truc, ça marche, ton voisin (ou un mec à l'autre bout de la planète) en développe une autre, ça marche, mais sans s'en apercevoir il a impacté ton morceau, qui ne marche plus.
    C'est bien parce que les applications sont complexes qu'on a besoin de debugger. Parce qu'on a oublié certains cas précis, parce que....

    Savoir debugger est primordial pour toute personne voulant faire du dev son métier, ou voulant faire du dev un tantinet sérieux. Le problème étant surtout que pour vouloir apprendre à utiliser le debugger aux étudiants, malheureusement leurs projets/TP/cours ne proposent que des développements triviaux qui n'en ont pas vraiment utilité.
    Debugger un hello world, comment dire...


    Sinon pour se vanner, j'ai 2 MOTO à ce sujet
    - tester c'est douter
    - debugger c'est tricher
    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.

  5. #5
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Points : 7 752
    Points
    7 752
    Par défaut
    Citation Envoyé par Amine Horseman Voir le message
    Pensez-vous aussi que le débogage est la compétence la plus importante à enseigner ?
    Pensez-vous que le débogage est négligé dans les formations en informatique ?
    Non, sérieux c'est un travail qui se fait inconsciemment. Si on a besoin d'expliquer à quelqu'un comment il doit débugger son code, c'est que ce quelqu'un n'a pas un niveau suffisant pour comprendre ce qu'il fait.

    Qu'est-ce qui me fait dire que mon code ne fonctionne pas ?
    Qu'est-ce que mon code est censé faire et pourquoi ?
    Qu'est-ce que mon code fait à la place et comment je le sais ?
    Je regrette, ça s'enseigne pas... C'est une compétence qui se développe dans un coin du cerveau, il y a pas de mode de raisonnement universel qu'on apprend par coeur et qu'on applique. J'ai l'impression que c'est comme avec les tests, les approches de développement, les méthodologies de gestion de projet à la mode, on aimerait pouvoir tout standardiser et mettre dans des manuels qu'il suffirait de suivre.

    Quels sont les critères qui font de quelqu'un « un expert du débogage » ?
    La pratique? Avec l'expérience on commence à mieux sentir ce qui peut foirer dans un code, et mieux encore, on arrive mieux à isoler les causes des effets et ainsi, on saura plus vite où et dans quelle direction chercher. Et pour rejoindre mon point plus haut, la pratique c'est la chose qui s'apprend le moins bien en école, dommage.

  6. #6
    Membre éclairé

    Homme Profil pro
    Développeur Java
    Inscrit en
    Février 2007
    Messages
    179
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Rhône (Rhône Alpes)

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

    Informations forums :
    Inscription : Février 2007
    Messages : 179
    Points : 653
    Points
    653
    Par défaut
    Normalement on devrait pas avoir à faire de débug (dans la vie des bisounours).
    Dans mon ancien poste, le débug c'était normal on faisait ça quasiment à chaque fois qu'il y avait un problème, c'est à dire plusieurs fois par jour sur des portions de code plus ou moins importantes.
    Sur le projet ou je suis actuellement, le débug je m'en sert peut être 1 fois par semaine.
    Pourquoi cette différence ? (de mon point de vue).
    Sur le projet actuellement j'ai une meilleur vision du code et du métier. (je pense que c'est la principal raison).
    Mais aussi on a des tests unitaires qui couvrent presque toute l'application (on doit être à 85%), mais aussi des tests d'intégrations avec des cas métiers.
    Je pense que ces deux facteurs expliquent pourquoi je me sert presque plus du débug.

    Pour moi un expert du débug c'est une personne qui maîtrise mal, soit son projet, soit le code personne ne devrait être expert débug.
    L'expérience est une lanterne que l'on porte sur le dos et qui n'eclaire jamais que le chemin parcouru.

    La nature fait les choses sans se presser, et pourtant tout est accompli.

  7. #7
    Expert confirmé Avatar de AoCannaille
    Inscrit en
    Juin 2009
    Messages
    1 409
    Détails du profil
    Informations forums :
    Inscription : Juin 2009
    Messages : 1 409
    Points : 4 713
    Points
    4 713
    Par défaut
    Citation Envoyé par _skip Voir le message
    Non, sérieux c'est un travail qui se fait inconsciemment.
    Tu veux dire comme c'est dit dans la news?
    Citation Envoyé par News
    même s’il le fait inconsciemment.
    Plus sérieusement une fois que tu lutte sur un bug depuis un certain temps et que tes mécanismes inconscients n'ont pas suffit, ça peut tjrs servir d'avoir une liste quelque part qui te rappelle quoi essayer ou quoi remettre en cause. Reprendre du recul quoi.

    Citation Envoyé par Angelsafrania Voir le message
    Normalement on devrait pas avoir à faire de débug (dans la vie des bisounours).
    Dans mon ancien poste, le débug c'était normal on faisait ça quasiment à chaque fois qu'il y avait un problème, c'est à dire plusieurs fois par jour sur des portions de code plus ou moins importantes.
    Sur le projet ou je suis actuellement, le débug je m'en sert peut être 1 fois par semaine.
    Pourquoi cette différence ? (de mon point de vue).
    Sur le projet actuellement j'ai une meilleur vision du code et du métier. (je pense que c'est la principal raison).
    Mais aussi on a des tests unitaires qui couvrent presque toute l'application (on doit être à 85%), mais aussi des tests d'intégrations avec des cas métiers.
    Je pense que ces deux facteurs expliquent pourquoi je me sert presque plus du débug.

    Pour moi un expert du débug c'est une personne qui maîtrise mal, soit son projet, soit le code personne ne devrait être expert débug.
    Citation Envoyé par Angelsafrania Voir le message
    Pour moi un expert du débug c'est une personne qui maîtrise mal, soit son projet, soit le code personne ne devrait être expert débug.
    Je viens d’atterrir sur un projet en 20 ans d'age (MFC ) ou ceux qui savent où ont su ont disparu. 1,5 million de ligne de code sur 900 classes, avec une 15aine de tâches qui discutent entre elles.
    évidement, très peu de doc existe et celle qui existe est souvent obsolète.

    Bien maîtriser le débogage est essentiel, même si cela s'apparente finalement a du rétro engineering...

  8. #8
    Membre chevronné
    Profil pro
    Inscrit en
    Octobre 2005
    Messages
    938
    Détails du profil
    Informations personnelles :
    Âge : 44
    Localisation : France

    Informations forums :
    Inscription : Octobre 2005
    Messages : 938
    Points : 1 806
    Points
    1 806
    Par défaut
    Je m'étonne des commentaires parlant de n'utiliser que rarement le débogueur, et que l'utiliser souvent est le symptôme d'un problème. Je dois être moins doué que je ne le pensais : je suis incapable d'écrire en une fois un programme qui fonctionne sans erreur du premier coup. (Note : comme je vous vois venir, je ne parle pas de projets de type Hello World, mais d'applications complexes à développer rapidement.) Chez moi, les tests révèlent immanquablement des problèmes et dans ce cas, je recours quasi systématiquement au débogueur, aux logs, à tous les outils disponibles. Je me sers également du débogueur pour vérifier qu'un code qui ne produit pas de résultat visible à l'écran fonctionne comme il doit. Quand un code est complexe, je m'en sers aussi même si le code donne un résultat correct : ça permet de vérifier que le code a donné le résultat correct, mais aussi qu'il y est parvenu de la façon attendue. J'ai pris cette habitude après avoir trop souvent hérité de codes qui renvoyaient le bon résultat par hasard, ne libéraient pas leurs ressources, créaient des effets de bord etc. Le débogueur est aussi très pratique pour faire l’ingénierie à rebours d'une librairie dont la documentation est insuffisante. Il l'est plus encore quand on doit déboguer le code bien sûr non commenté de son prédécesseur.

    Retour au sujet du thread : l'enseignement du débogage. A l'évidence, un développeur doit être capable de corriger les problèmes d'un programme. Ce n'est pas simplement important, c'est indispensable. A moins d'imaginer un génie capable d'écrire des millions de lignes de code sans la moindre erreur, qui ne travaillerait qu'avec d'autres génies ne commettant jamais d'erreur, et ne travaillerait qu'avec des outils n'ayant aucune erreur. (Déjà, il faudrait un OS sans aucune faille.)
    Maintenant, est-ce la compétence la plus importante à enseigner? Je ne pense pas. Tout d'abord, on ne peut pas déboguer sans comprendre l'algorithmie, ce qui rend cette dernière automatiquement plus importante. Ensuite, même sans compétence spécifique, déboguer peut s'improviser. Ce n'est pas le cas d'autres activités indispensables du métier de développeur comme la conception et l'écriture du code, qui implique de connaitre le langage de programmation.

    En revanche, je suis tout à fait d'accord avec CodeUnion pour dire que sa place dans la formation des informaticiens devraient être plus grande. Le débogueur, mais aussi les logs, la gestion des exceptions, etc. sont des outils précieux auxquels les développeurs devraient être formés. Il y a également des bonnes pratiques à connaître pour rendre un code plus facile à déboguer. Ceci dit, pour le débogage, rien ne vaut la pratique. C'est probablement pour ça que son enseignement est négligé : le débogage ne s'apprend pas tant en classe que devant un code qui refuse de fonctionner. C'est avec l'expérience qu'on apprend à trouver les causes d'un problème mystérieux, et, plus important, à écrire un code dont les problèmes ne soient pas mystérieux parce que générant des messages d'erreur clairs.

    En résumé : la formation des développeurs devraient en effet se consacrer davantage aux outils et aux bonnes pratiques du débogage. En revanche, y passer une quantité de temps proportionnelle au temps qu'on y passe est exagéré, car le débogage s'apprend essentiellement par la pratique et repose également sur les autres compétences du développeur.

  9. #9
    Expert confirmé Avatar de psychadelic
    Profil pro
    Inscrit en
    Mai 2010
    Messages
    2 529
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2010
    Messages : 2 529
    Points : 4 739
    Points
    4 739
    Par défaut
    Primo, personne n’est parfait, et des erreurs on en fait tous.
    Ceux qui prétendent le contraire sont des mégalos.

    Bien sur, avec le temps, l’expérience, la pratique, on peut atteindre le zéro Bugs dès la première écriture, mais c’est un peu comme au Golf, le « trou en un », ça existe, mais c’est pas mal de la chance.

    Je vais pas rentrer dans les conditions préalables (et déterminantes) pour écrire du bon code dès le départ, car en fin de compte elles son plutôt rares, les cahiers des charges et d’analyse sont bâclées ou incomplets, les utilisateurs ne savent pas trop ce qu’ils veulent, ou à quoi s’attendre, etc…
    Il y a milles et une raisons, qui font qu’au bout du compte, le code ne tiennne plus la route.

    Par exemple, j’ai travaillé sur des programmes écrits en 198x, en COBOL pour machines Wang mais émulé sur des systèmes IBM (Quand Wang à été racheté par IBM, le Pentagone à imposé à IBM de créer cet émulateur), le tout pour ajouter des retours d’informations vers des smartphones via des encapsulations en Java…

    Tout séparément, en test unitaires, fonctionnait parfaitement, mais une fois « packé » ça partait en sucettes…
    Alors Oui, le debuging, c’est vital !

    Du reste, c’est en étudiant le code des autres que j’ai le plus appris (mais c’est une autre histoire).

    Au passage, pour ceux que ça intéresse, il y a un excellent article sur la résolution d’un Bug (surconsommation de CPU) chez Netflix, utilisant notamment des « graphes de flammes » en SVG…
    http://techblog.netflix.com/2014/11/...in-flames.html
    «La pluralité des voix n'est pas une preuve, pour les vérités malaisées à découvrir, tant il est bien plus vraisemblable qu'un homme seul les ait rencontrées que tout un peuple.» [ René Descartes ] - Discours de la méthode

  10. #10
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    Le debug est une activité de diagnostic post-incident fortement consommatrice de temps. Le recours au debug peut être largement réduit si on utilise des techniques de conception maximisant la fiabilité du code dès son écriture :

    • Système de types riche et plus strict
    • Immuabilité
    • Tests unitaires automatisés
    • Programmation par contrats
    • etc.



    On devrait apprendre en priorité à concevoir des applications robustes, et ensuite à diagnostiquer les éventuels problèmes quand ça se passe mal à l'exécution (debug mais aussi lecture de logs, outils d'analyse, etc.)

  11. #11
    Membre averti
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    187
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 187
    Points : 434
    Points
    434
    Par défaut
    En lisant les commentaires ça donne l'impression que certains parlent des phases de dev et d'autres des phases de maintenance...?

  12. #12
    Membre confirmé Avatar de bruneltouopi
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2010
    Messages
    308
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Ile Maurice

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

    Informations forums :
    Inscription : Janvier 2010
    Messages : 308
    Points : 466
    Points
    466
    Par défaut
    J'ai constaté qu'une fois j'ai montré le debug aux Stagiaires ils passent le plus clair de leur temps à debugger.Et ils ne prennent pas le temps de bien réfléchir pour coder proprement.
    En plus dans un environnement JEE avec un projet assez lourd le temps de débug est assez long donc ils perdent plus de temps.
    Moi Le debug est essentiellement surtout lorsque des événements non contrôlés surviennent ou pour contrôler le code repris.
    Ce qui ne me tue pas me rend plus fort.

  13. #13
    Expert confirmé Avatar de psychadelic
    Profil pro
    Inscrit en
    Mai 2010
    Messages
    2 529
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2010
    Messages : 2 529
    Points : 4 739
    Points
    4 739
    Par défaut
    Citation Envoyé par Washmid Voir le message
    En lisant les commentaires ça donne l'impression que certains parlent des phases de dev et d'autres des phases de maintenance...?
    Il y a aussi les phases d'analyse, avant.
    Mais elles passent souvent à la trappe, et les jeunes codeurs sont souvent impatients de se jeter sur la programmation, et du coup ils passent trop de temps en debug...

    Dans ce cas, perso, je parle de bug d'analyse préalable, ça simplifie ensuite les débriefings...

    Et que ce soit du Dev pure, ou de la maintenance, quand écrit du code, ben, on programme…

    Faire du bon code ne dépend pas du moment ou se met à l’écrire.

    Du reste, il à des dev qui des le départ fonctionnent plutôt bien, mais qui par la suite se révèlent de véritables plaies à maintenir.

    Et ça aussi sa devrait rentrer dans les critères de qualité du code.

    Comme par exemple les noms de fonctions avec des prénoms féminins, les noms de variables avec des chiffres (v01, v02…), les commentaires avec la météo du jour, et j’en passe…

    La ce sont des Bugs d’écriture en fait ??
    Et c’est marrant les tests unitaires ne les détectent pas !!
    «La pluralité des voix n'est pas une preuve, pour les vérités malaisées à découvrir, tant il est bien plus vraisemblable qu'un homme seul les ait rencontrées que tout un peuple.» [ René Descartes ] - Discours de la méthode

  14. #14
    Membre expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    Août 2010
    Messages
    1 653
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations forums :
    Inscription : Août 2010
    Messages : 1 653
    Points : 3 773
    Points
    3 773
    Par défaut
    Citation Envoyé par Washmid Voir le message
    En lisant les commentaires ça donne l'impression que certains parlent des phases de dev et d'autres des phases de maintenance...?
    Au final cela reste de la résolution de bugs.

    Non là où ce thread a un petit problème c'est sur le cadre du débogage.

    Qu'appelle-t-on le débogage ? J'ai l'impression que pour certains "débogage" rime avec "utilisation d'un débogueur". Or ceci est faux. L'écriture très temporaire dans le code de trucs style printf("a = %d", a); ou encore println("plop"); est déjà une forme de débogage. Idem avec une simple relecture du code pour s'apercevoir qu'il y a une erreur. Qui ne l'a jamais fait ? Celui qui ne débogue jamais est donc un fieffé menteur ou un très mauvais développeur qui devrait considérer l'arrêt de la programmation informatique. Il est donc primordial de savoir déboguer et de le faire.

    Ne confondons pas non plus tests et débogage. Les tests sont là pour chercher les bugs, avec de préférence avec "aucun résultat" à la clé, et le débogage est là pour les résoudre. Mais ce n'est pas pour autant que les tests ne sont pas importants, entendons-nous bien. Il est important que les anciens bugs ne reviennent pas et il faut pour cela avoir des tests pour guetter leur retour. Il est aussi important de faire un minimum de recherche de bugs sur ce que l'on code au moment du codage.

    Parallèlement à cela il y a aussi le débat sur l'utilisation d'un outil de débogage pour déboguer. Perso je pense que tout le monde devrait savoir utiliser au moins un débogueur utilisable sur le projet à déboguer. Qu'il soit graphique ou en CLI importe peu, le meilleur logiciel étant avant tout celui que l'on connait et maîtrise. Il faut savoir aussi quand utiliser le débogueur. Utiliser un débogueur prend quand même un minimum de temps. Les traditionnels print("salut"); suffisent pour résoudre un petit bug alors qu'un débogueur est plus adapté pour les gros bugs.

    Certains parlent des logs mais au final ce ne sont que des print rassemblés dans un fichier. Certes on y indique au moins la criticité de ce qui se passe, ce qui s'y passe et l'heure à laquelle cela se passe. Mais cela ne reste que des infos que l'on utilisera pour traquer un bug et le résoudre. On n'écrit pas les logs pour le plaisir de les lire. Après est-ce que les logs sont importants ? Ils peuvent l'être mais ce n'est pas le plus important. Cela ne sert à rien de faire des logs au petits oignons au détriment du reste pour ensuite se retrouver avec une palanquée de warning et de error, au lieu des info indiquant a priori une situation normale.

    Citation Envoyé par Amine Horseman Voir le message
    Pensez-vous aussi que le débogage est la compétence la plus importante à enseigner ?
    Non. Apprendre à déboguer ne dispense pas non plus d'apprendre à coder proprement comme le dit bruneltouopi, bien au contraire. Apprenons déjà à faire moins de bugs avant de perdre du temps à les résoudre.

    Il est aussi important de connaître le langage que l'on utilise. Il faudrait déjà que ça compile pour pouvoir ensuite déboguer, non ? Quoiqu'une erreur de compilation est plus ou moins un bug de codage en soi.

    Citation Envoyé par Amine Horseman Voir le message
    Pensez-vous que le débogage est négligé dans les formations en informatique ?
    Non dans l'absolu. Tous les enseignants donnent bien à un moment donné des astuces à leurs élèves pour qu'ils sachent trouver ce qui ne marche pas quand ça ne marche pas, et donc pour qu'ils déboguent. Après le débogage est aussi une énième variation de "cherchez l'erreur" et pour ça il n'y a pas besoin d'enseignant en informatique.

    Par contre je n'en dirai pas autant sur l'utilisation d'outils de débogage. Le seul "cours" que j'ai eu sur les outils de débogage était un tutoriel au verso d'une feuille de TP de langage C qui donnait à l'occasion les bases de l'utilisation de gdb en ligne de commande. Autant dire pas grand chose, surtout pour celui qui n'a pas lu le TP. Plus tard un autre prof a demandé qui savait utiliser un débogueur et j'ai été l'un des rares à répondre oui car j'avais fait l'effort pour gdb. Je vous laisse donc deviner ce que j'en pense.

    Citation Envoyé par Amine Horseman Voir le message
    Quels sont les critères qui font de quelqu'un « un expert du débogage » ?
    Un débogage efficace rime souvent avec une bonne pose des marques de débogage (prints, breakpoints, messages de logs ou autre). Or pour bien poser ses marques encore faut-il déjà savoir où les poser. Un « expert du débogage » serait donc avant tout quelqu'un qui sait bien cibler les bugs auxquels il a affaire. Je ne pense donc pas qu'il y ait « d'experts en débogage » dans l'absolu mais que cela dépend de la connaissance du projet et de ses technologies. Celui qui connaît le projet, et donc son code et le programme final, saura plus facilement cibler ce qui ne marche pas comme prévu. Certains bogues seront caractéristiques d'un techno et qui connaîtra cette techno saura d'où ils viennent. À la limite le seul élément qui pourrait faire la différence entre un bon débogueur et un mauvais débogueur est de savoir quels moyens de débogage mettre en place selon la situation et le projet (logs, prints basiques, outils de débogage avec breakpoints). Exemple : utiliser des logs sur un produit en production mais on peut utiliser des breakpoints quand on résout le bug en local.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  15. #15
    Invité
    Invité(e)
    Par défaut
    debugger c'est jamais inutile ya toujours un moment ou ca casse..
    mais à mes yeux faire des tests unitaires est plus important.

    Je me souviens à mes débuts le temps passé à refactorer par ci par là..(ou à me faire dessus parce qu'il faut une refacto) puis runner puis fixer ci et là alors qu'une simple couverture stupide aurait permis de pas avoir à runner 5 fois pour fixer et à pouvoir cerner plus rapidement les ... bugs.

    PS: sur wiki, débugger c'est pas que le debugger, c'est aussi les logs, toute méthode pour résoudre les bugs...

    autrement dit écrire des tests unitaires nécessite de debugger (quand ils ne passent pas), mais on devrait plus mettre l'accent sur ça que sur les techniques de debugging ya pas besoin d'être un surdoué pour écrire des printf.

    Les debuggers graphiques sont une plaie, et sont particulièrement repoussant à mes yeux, click click click click
    et utiliser un debugger prend du temps.

    Du temps qu'on a pas envie de perdre quand on débute (mais qui devient intéressant après avoir acquis un certain niveau), mais pas quand on débute...

  16. #16
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 347
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 347
    Points : 20 347
    Points
    20 347
    Par défaut
    Citation Envoyé par AoCannaille Voir le message
    Je viens d’atterrir sur un projet en 20 ans d'age (MFC ) ou ceux qui savent où ont su ont disparu. 1,5 million de ligne de code sur 900 classes, avec une 15aine de tâches qui discutent entre elles.
    évidement, très peu de doc existe et celle qui existe est souvent obsolète.

    Bien maîtriser le débogage est essentiel, même si cela s'apparente finalement a du rétro engineering...
    salut est-ce que les 900 classes soient justifiées ?
    Si ça se trouve il faudrait faire un bon refactoring du projet et remettre à plat l'architecture.
    Sinon l'héritage entre classes ça existe aussi.
    Mais ça sort un peu du cadre de ce fil de discussion

  17. #17
    Membre chevronné Avatar de nirgal76
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2007
    Messages
    902
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

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

    Informations forums :
    Inscription : Septembre 2007
    Messages : 902
    Points : 2 115
    Points
    2 115
    Par défaut
    Je ne sais pas si c'est primordial mais j'avoue aimer ça plus que le reste. Traquer un bon bug pendant des jours et finir par lui régler son compte, ça fait un bien fous

  18. #18
    Expert confirmé Avatar de AoCannaille
    Inscrit en
    Juin 2009
    Messages
    1 409
    Détails du profil
    Informations forums :
    Inscription : Juin 2009
    Messages : 1 409
    Points : 4 713
    Points
    4 713
    Par défaut
    Citation Envoyé par Mat.M Voir le message
    salut est-ce que les 900 classes soient justifiées ?
    Si ça se trouve il faudrait faire un bon refactoring du projet et remettre à plat l'architecture.
    Sinon l'héritage entre classes ça existe aussi.
    Mais ça sort un peu du cadre de ce fil de discussion
    alors oui ça sort complétement du cadre de la discussion.

    C'est l'esprit MFC qui fait faire des classes partout. Et si tu calcule le nombre de lignes par classe dit toi qu'un refactoring augmenterait le nombre de classe plutôt que le réduire.
    Bref, ce genre d’appli ne sera jamais "refactoré", il est issu d'une techno obsolète, mal maîtrisée par ceux qui ont maintenu. Pire, par facilité (et manque de temps (d'argent en fait), comme toujours), il y a (beaucoup) de fonctionnel dans les classes d'IHM, autant dire que d'une part il ne sera jamais "refactoré" mais ne subira jamais de changement de techno pour la partie "Vue" du modèle.

    Pour la petite histoire, notre client nous a fait faire un devis pour un portage sous Linux, bizarrement on n'a plus de nouvelles de ce portage

  19. #19
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    Citation Envoyé par nirgal76 Voir le message
    Je ne sais pas si c'est primordial mais j'avoue aimer ça plus que le reste. Traquer un bon bug pendant des jours et finir par lui régler son compte, ça fait un bien fous
    +1 car on a je pense tous eu ce sentiment un jour Mais avec le recul, je préfère la satisfaction de traquer un bon bug pendant quelques minutes seulement car ma suite de tests m'a indiqué assez précisément où il était (ou mieux, pendant quelques secondes le temps que le compilateur pointe le problème).

    Je ne dis pas que c'est toujours possible et il y a parfois des défauts qui passent entre les mailles du filet, mais c'est quand même plus efficace.

    Pour forcer le trait, dire que le debug est le skill le plus important à développer, c'est un peu comme s'entraîner principalement à chasser l'ours géant de l'Himalaya plutôt que le lapin de garenne. Certainement excitant, mais pas forcément optimal point de vue rendement/risque.

  20. #20
    Membre éprouvé

    Homme Profil pro
    Développeur PHP/Symfony // Mentor OpenClassrooms
    Inscrit en
    Octobre 2014
    Messages
    203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hautes Alpes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur PHP/Symfony // Mentor OpenClassrooms
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Octobre 2014
    Messages : 203
    Points : 1 264
    Points
    1 264
    Billets dans le blog
    3
    Par défaut
    Honnêtement je pense que le concept de débogage doit être enseigné tôt dans l'apprentissage de la programmation, savoir comment écrire un programme est une chose mais savoir trouver l'erreur et l'arranger en est une autre, certains ne savent pas forcément réfléchir à cette logique de vérification.

    Personnellement je ne lance pas de développement sans penser aux erreurs, je les étudies durant l'écriture puis je corrige au fur et à mesure en ajoutant via des commentaires un suivi précis des erreurs rencontrés, cela n'est pas forcément bien compris par certains et le temps peut s'allonger selon l'erreur d'écriture mais je trouve le texte final plus précis qu'un vague fichier .txt avec quelques erreurs lancés comme ça dans le vent.

Discussions similaires

  1. Quelle est la place d’un développeur dans le monde de la robotique ?
    Par Stéphane le calme dans le forum Robotique
    Réponses: 7
    Dernier message: 13/08/2016, 02h07
  2. Quelle est l’importance de la journalisation dans le débogage ?
    Par Amine Horseman dans le forum Débats sur le développement - Le Best Of
    Réponses: 26
    Dernier message: 30/05/2015, 23h06
  3. Quelle est la place du débogage dans la programmation ?
    Par Amine Horseman dans le forum Actualités
    Réponses: 21
    Dernier message: 28/11/2014, 12h59
  4. [ZF 1.8] [débutant] Quelle est la place des objets métier dans zf ?
    Par Trycias dans le forum Zend Framework
    Réponses: 3
    Dernier message: 21/05/2009, 20h14
  5. Réponses: 11
    Dernier message: 02/11/2006, 18h12

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