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. #21
    Expert éminent sénior
    Homme Profil pro
    Ingénieur d'Etude Mainframe/AS400
    Inscrit en
    novembre 2012
    Messages
    1 632
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'Etude Mainframe/AS400
    Secteur : Finance

    Informations forums :
    Inscription : novembre 2012
    Messages : 1 632
    Points : 10 082
    Points
    10 082
    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...?
    On dirait aussi ... pour moi debugger c'est de la maintenance. Et il s'agit généralement de cas tordus sur des programmes tournant depuis de nombreuses années. alors que "debugger" un programme qui vient d'être écrit relève du test unitaire et est censé être simple puisqu'il s'agit de son code, donc connu et compris.

  2. #22
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 158
    Points : 7 829
    Points
    7 829
    Par défaut
    Oui, le débogage doit être mieux enseigner mais de là à dire que c'est le plus important, pas sûr du tout

    Par exemple, la factorisation du code est essentielle car elle permet d'isoler les tâches dans des fonctions dédiées
    Nous seulement, cela permet de tester individuellement chaque tâche unitaire (et facilite le débogage) mais améliore également la robustesse et la maintenabilité du code (la modification d'une tâche ne se fait qu'à un seul endroit, ça évite les oublis)

    Apprendre le débogage : oui
    Apprendre à bien structurer son code pour éviter / simplifier le débogage : oui et oui

    Le développement est une tâche complexe qui implique de multiple compétences qui ont toutes leur importance
    Affirmer que l'une est plus importante que l'autre n'a pas grand sens

  3. #23
    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 607
    Points
    4 607
    Par défaut
    Citation Envoyé par Darkzinus Voir le message
    On dirait aussi ... pour moi debugger c'est de la maintenance. Et il s'agit généralement de cas tordus sur des programmes tournant depuis de nombreuses années. alors que "debugger" un programme qui vient d'être écrit relève du test unitaire et est censé être simple puisqu'il s'agit de son code, donc connu et compris.
    Complétement faux...

    quand on travaille dans la qualité logiciel, on relis le code de ses petits copains.

    Ce qui est quasiment la règle pour tous logiciels destiné à la vente grand public, mais c'est encore pire pour les logiciels embarqués, ou millions peuvent être en jeux, voir des vies humaines.

    Bien sur dans le secteur Banque finance, ils peuvent jouer avec l'argent des autres, c'est moins grave (ironique), mais normalement, avant qu'un code soit livré en exploitation, il est au moins relu par le chef de projet

    Et que penser des dépots libres sur GitHub et autre, destinés à la communauté des développeurs, si tu tiens à ta réputation, t'as plutôt intérêt à lécher ton code...

    Ah, et j'oubliais, et ceux qui travaillent ensemble sur des gros projets libres, genre Apache (qui entre nous soit dit, sont plutôt des pointures) je crois pas non plus qu'ils ajoutent du code avec un simple commit, sans prévenir les autres...

    Non, Le Debugging fait partie de la programmation, dès le départ !
    «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

  4. #24
    Membre actif
    Inscrit en
    août 2005
    Messages
    307
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 307
    Points : 255
    Points
    255
    Par défaut
    Les tests unitaires ne permettent pas de debugger, je serais vraiment très reconnaissant si quelqu'un me montre sur un exemple simple comment il peut localiser un bug qu'on a détecté en production grâce aux tests unitaires. Les tests unitaires permettent juste de détecter la présence des bugs prévisibles dans classe, mais ils ne permettent pas de localiser le bout de code précis qui cause le bug. Si par exemple une méthode f1 retourne un "bug" et que cette méthode appelle des méthodes privés f2, f3, f4, le test unitaire ne va pas vous dire qui de f2, f3, ou f4 est à l'origine du bug, le test unitaire signale simplement un bug, mais il ne le localise pas avec précision.

    En plus 95% des bugs que je rencontre sont des bugs d'intégrations, les bugs issues des tests unitaires sont très rares, et sont très facile à détecter

  5. #25
    En attente de confirmation mail

    Profil pro
    Inscrit en
    septembre 2013
    Messages
    640
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2013
    Messages : 640
    Points : 2 346
    Points
    2 346
    Par défaut
    Il y a un autre problème, différent du déboggage mais qui lui est néanmoins connexe : le code écrit pour gérer les erreurs à l'exécution.

    Il ne suffit évidemment pas de blinder son code d'assertions, ni de passer son temps à lever et à catcher des exceptions. Une bonne gestion d'erreur nécessite beaucoup plus de réflexion que cela (même si les exceptions peuvent être un outil précieux) et a sans doute besoin d'être abordée différemment selon les types de projets.

    Petit problème : comment ENSEIGNER la gestion d'erreur ? Ou le déboggage ? Ou la maintenance ?

    Je pense que ce sont des choses que l'on ne peut pas trop enseigner, et qu'il ne suffit pas de croire à une telle idée pour en faire quelque chose.

    Remarquez qu'il est peut-être facile d'"enseigner" la maintenance... demander aux étudiants de la promo N+1 de faire de la maintenance évolutive et / ou corrective des projets des étudiants de la promo N... avec l'interdiction stricte de tout réécrire from scratch. Voilà un bon exercice pour ceux qui n'ont peur de rien !

  6. #26
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 158
    Points : 7 829
    Points
    7 829
    Par défaut
    Citation Envoyé par CodeurPlusPlus Voir le message
    Je pense que ce sont des choses que l'on ne peut pas trop enseigner, et qu'il ne suffit pas de croire à une telle idée pour en faire quelque chose.

    Remarquez qu'il est peut-être facile d'"enseigner" la maintenance... demander aux étudiants de la promo N+1 de faire de la maintenance évolutive et / ou corrective des projets des étudiants de la promo N... avec l'interdiction stricte de tout réécrire from scratch. Voilà un bon exercice pour ceux qui n'ont peur de rien !
    J'adhère bien à l'idée de gérer des projets sur plusieurs promo avec de mettre en pratique la maintenance.
    Sinon, la gestion des exceptions s'enseigne très bien (en tout cas, j'ai eu un bon prof pour ça lors de mes études)
    De même, il existe des design pattern pour gérer les exceptions...

    Ce qui manque surtout, c'est d'avoir des prof qui soient proche de la réalité du travail en entreprise
    En ce qui me concerne, j'ai étudié à la fac et l'intégralité de mes prof étaient des enseignants chercheurs et la plupart étaient totalement déconnectés des réalités du marché
    Pour ceux qui étaient membres de communautés open source, ça allait
    Mais certains étaient auto centrés sur leurs domaines et là....

  7. #27
    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 931
    Points
    2 931
    Par défaut
    Citation Envoyé par kisitomomotene Voir le message
    Les tests unitaires ne permettent pas de debugger, je serais vraiment très reconnaissant si quelqu'un me montre sur un exemple simple comment il peut localiser un bug qu'on a détecté en production grâce aux tests unitaires.
    Normal, ce n'est pas leur but. Les TU (mais aussi un typesystem riche et strict, des assertions/pré ou postconditions dans le code) ne traquent pas les problèmes ou régressions apparus en production mais les signalent dès le développement. D'où, moins de bugs qui atteignent la production. Le debug devient une compétence moins primordiale, car on utilise autre chose en dev, et il y a moins de problèmes qui atteignent la prod. CQFD

    Citation Envoyé par kisitomomotene Voir le message
    Les tests unitaires permettent juste de détecter la présence des bugs prévisibles dans classe, mais ils ne permettent pas de localiser le bout de code précis qui cause le bug. Si par exemple une méthode f1 retourne un "bug" et que cette méthode appelle des méthodes privés f2, f3, f4, le test unitaire ne va pas vous dire qui de f2, f3, ou f4 est à l'origine du bug, le test unitaire signale simplement un bug, mais il ne le localise pas avec précision.
    On a déjà au moins la méthode publique où se trouve le bug, ainsi qu'une description du problème, les valeurs attendues par rapport aux valeurs réelles. Ce qui est bien mieux que de partir d'un comportement anormal constaté à travers une exécution manuelle de l'application, où on essaie plus de deviner et de tâtonner. Par ailleurs, il vaut mieux externaliser les responsabilités dans des petites classes séparées et testables unitairement, que de recourir à de longues méthodes publiques qui font appel à beaucoup de méthodes privées.

    Citation Envoyé par kisitomomotene Voir le message
    En plus 95% des bugs que je rencontre sont des bugs d'intégrations, les bugs issues des tests unitaires sont très rares, et sont très facile à détecter
    Si on a conçu une application valide et fiable dès le départ, bien sûr que 95% des bugs seront liés à la configuration et à l'environnement, et c'est tant mieux. Pour ceux-là, le diagnostic via du debugging est long, fastidieux et parfois hasardeux (on ne peut pas toujours recréer entièrement les conditions de la prod en débuggant).

    On ne dit pas qu'il ne faut pas débugger, juste que mettre la priorité sur l'apprentissage d'une technique consommatrice de temps, pénible et dont on peut significativement réduire l'utilisation, n'est pas forcément une bonne idée.

  8. #28
    Expert éminent
    Avatar de Matthieu Vergne
    Homme Profil pro
    Consultant IT, chercheur IA indépendant
    Inscrit en
    novembre 2011
    Messages
    2 198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant IT, chercheur IA indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 2 198
    Points : 7 439
    Points
    7 439
    Billets dans le blog
    3
    Par défaut
    Pour faire court, je suis de l'avis de Luckyluke34, air-dex, Saverok. Pour ceux qui aiment les pavés, lisez la suite. {^_^}

    Et pour ceux qui se diront tout au long de leur lecture "ouais mais ça c'est la théorie, la pratique c'est pas comme ça" ou "tu connais rien à la vie", qu'ils se disent qu'il y a ceux qui passent leur temps à critiquer la théorie, et ceux qui passent leur temps à l'appliquer. Choisissez votre camp. {^_°}

    Citation Envoyé par Amine Horseman Voir le message
    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.
    Je fais partie du "presque". On peut-être suffisament rigoureux pour avoir un truc qui marche du premier coup. Et là je parle d'expérience perso, pas de principe. Ça m'est déjà arrivé, et si on reste flexible sur la notion de "premier coup" (correction de quelques ';' ou '"' manquants, dire que ça compile), alors ça m'est arrivé plus d'une fois et ça m'arrive encore. C'est tout à fait possible et ça n'a rien de miraculeux ni de l'ordre du génie. C'est d'autant plus faciles si on se limite de 100 à 1000 lignes de code, et quand on fait de la programmation modulaire c'est plusieurs modules de 100-1000 lignes sur chacun desquels on peut réitérer l'exploit.

    Quand tu sais découper ton gros problème en sous problèmes, qui deviennent suffisamment simples pour être codés bons du premier coup (tous tes tests dédiés passent au vert direct), et que tu fais ça dans l'ordre, y'a pas de raison que tu ais à passer un temps significatif en débogage. Mais bien entendu, ça demande de prendre le temps de comprendre le problème, de le formaliser, de le découper proprement, de restreindre ses envies d'optimiser à tout bout de champ, etc. Ce temps que tu ne passeras pas en débogage à générer de la sueur froide, tu le passeras en préparation à générer de l'expertise, qui se traduira en code propre et robuste.

    @psychadelic : Non faire un code qui marche du premier coup c'est pas qu'un coup de chance. Soit on fait ce qu'il faut pour que ça marche du premier coup, soit on ne s'en soucie pas (ça n'empêche pas d'avoir d'autres critères de qualité en tête) et là c'est effectivement un coup de chance. Si tu veux quelque chose, organise-toi pour l'avoir, c'est aussi simple que ça. Découper en sous-problèmes et faire preuve de rigueur sont deux façons de favoriser le "test vert dès le premier coup". Contrairement au golf où tu ne contrôles ni le vent ni le terrain et dois faire uniquement avec des approximations, le codage est bien plus contrôlé et donc facile à maîtriser. Le tout étant de faire l'effort d'être méthodique. Ça ne préserve pas des erreurs, mais ça réduit notablement le temps passé en débogage (initial comme maintenance).

    Citation Envoyé par Amine Horseman Voir le message
    Pensez-vous aussi que le débogage est la compétence la plus importante à enseigner ?
    Importante, oui mais pas en tant que telle, donc la plus importante, non. Avant de savoir déboguer, il faut savoir coder et connaître le contexte de l'application. Et c'est quand on a intégrer tout ça qu'on peut remettre en cause le code. Déboguer c'est savoir identifier ce qui ne vas pas, trouver une solution et l'implémenter, ce qui n'est rien de plus que savoir coder.

    Citation Envoyé par Amine Horseman Voir le message
    Pensez-vous que le débogage est négligé dans les formations en informatique ?
    Dire que le débogage est négligé dans le sens "on n'apprends pas assez à régler des problèmes", je suis d'accord. Mais le codage c'est pareil, ça se limite pas au débogage. Dans le sens "on ne passe pas assez de temps à s'entrainer à des tâches de maintenance", là par contre je suis contre. Je préfère de loin un enseignement qui m'apprend à faire du code propre et correct plutôt qu'un enseignement qui prend le code sale pour la norme inévitable. Quand tu sais faire du code propre, tu reprends un code sale en le nettoyant, pas en minimisant tes modifs.

    Citation Envoyé par Amine Horseman Voir le message
    Quels sont les critères qui font de quelqu'un « un expert du débogage » ?
    Pour moi c'est quelqu'un qui passe beaucoup de temps à faire évoluer une appli mais peu à la déboguer. Déboguer, c'est savoir se poser les bonnes questions pour remettre en doute le code. Quand on se pose les bonnes questions avant de coder, le débogage on n'en a quasiment plus besoin. Et ces questions se transforment en tests qui passent au vert.

    Pour répondre à BugFactory, utiliser le débogueur souvent aujourd'hui est soit un choix (parce que tu préfères faire des tests en manuel plutôt que de les implémenter, clin d'oeil à nirgal76) soit le symptôme d'un manque de maitrise :

    - si c'est seulement pour vérifier que son propre code marche, c'est soit un manque de maitrise du langage en lui-même (t'es pas sûr de comment interpréter telle syntaxe), soit un manque de maitrise du problème (concepts peu clairs, grosse fonction intestable venant d'un manque de découpe du problème en sous-problèmes, etc.). Et pour ce genre de cas, mieux vaut je pense prendre le temps de maitriser le problème, le découper proprement pour faire des fonctions dédiées et leurs tests associés, qu'on peut rejouer plus tard et fournissent un filet de sécurité. On ne joue plus avec le débogueur, qui reste du manuel et donc un effort supplémentaire récurrent.

    - si c'est seulement pour comprendre le code d'un autre, c'est un manque de maitrise du langage aussi, dans le sens où il suffit de lire le code pour savoir ce qu'il fait. Ça ne nous dit pas pourquoi il le fait, mais ce qu'il fait. Et comprendre le pourquoi ne doit pas venir du code mis en défaut, mais du contexte (où et comment il est utilisé). Toute déduction du pourquoi d'une fonction par l'étude de son code n'étant qu'interprétation perso sujette à caution (je me suis déjà fait avoir). Et si le code est "trop complexe", utiliser le débogueur ne te donnera que des informations supplémentaires sur des exécutions précises, donc pas forcément généralisables et donc des interprétations biaisées. Plutôt que d'utiliser le débogueur (et comme le mentionne Mat.M), mieux vaut je pense faire du refactoring qui préserve la sémantique du code mais améliore sa lecture : changer les noms des variables et fonctions, extraire les parties indépendantes du code dans des fonctions dédiées (et bien nommées), etc. Ce n'est pas toujours facile, et parfois infaisable (des tas de dépendances inutiles sont ajoutées, ce qui t'empêche de trouver des parties indépendantes à factoriser), mais tu peux le pousser jusqu'à être bloqué pour te donner la meilleure vision que possible. Après, soit tu altères le code sur la base d'interprétations pour le factoriser davantage, soit tu prends les morceaux monolithiques comme des boites noires.

    - si c'est pour régler un problème (et là je ne dis rien de neuf, cf. toutes les discussions qui parlent de l'origine des bogues), ça implique que le codeur initial (toi ou un autre dont tu auras repris le code) n'avait pas une idée assez claire/fiable de ce qu'il devait faire. Dans le cas de plusieurs devs, qu'au moins certains d'entre eux n'avaient pas une idée claire/fiable de ce qu'ils devaient faire, ou que l'intéraction de leurs différents modules n'était pas claire/fiable. Après on pourra se demander à qui la faute, mais c'est une autre discussion déjà lancée.

    Quand tu codes une application, même complexe (complexe ne veut pas dire compliqué), pour obtenir un code dont tu es convaincu qu'il fonctionne il faut passer par des étapes nécessaires (qui dépendent de beaucoup de choses, mais dans l'ensemble qui se résument à comprendre le problème, le formaliser, déduire la solution et l'implémenter, la notion de test étant transversal à tout ça). Pour s'assurer que ces étapes soient faites, il faut bien organiser le processus d'implémentation, et pour s'assurer qu'elles soient validées, il faut bien organiser le code pour pouvoir tester chaque partie concernée. Quand tu as une deadline trop courte, tu pourras jouer des pieds et des mains, tu ne pourras pas faire une appli complète ET correcte. Dès lors, il faut faire des choix, le tout étant de les assumer derrière.
    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 {^_^})

  9. #29
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 158
    Points : 7 829
    Points
    7 829
    Par défaut
    Citation Envoyé par Matthieu Vergne Voir le message
    @psychadelic : Non faire un code qui marche du premier coup c'est pas qu'un coup de chance. Soit on fait ce qu'il faut pour que ça marche du premier coup, soit on ne s'en soucie pas (ça n'empêche pas d'avoir d'autres critères de qualité en tête) et là c'est effectivement un coup de chance. Si tu veux quelque chose, organise-toi pour l'avoir, c'est aussi simple que ça. Découper en sous-problèmes et faire preuve de rigueur sont deux façons de favoriser le "test vert dès le premier coup". Contrairement au golf où tu ne contrôles ni le vent ni le terrain et dois faire uniquement avec des approximations, le codage est bien plus contrôlé et donc facile à maîtriser. Le tout étant de faire l'effort d'être méthodique. Ça ne préserve pas des erreurs, mais ça réduit notablement le temps passé en débogage (initial comme maintenance).
    On peut être amener à déboguer un code propre (règle de gestion mal comprise, par exemple).
    La maintenance c'est à la fois l'analyse et la correction de bug mais aussi de l'optimisation de code et la mise en place de petites évolutions.
    Ces tâches représentent le quotidien d'énormément de développeurs.
    Je dirai même que dans la majorité des cas, on part rarement d'une feuille blanche, il y a toujours de l'existant qu'on doit comprendre et développer voir le modifier afin d'y insérer son propre code.
    Une bonne formation qui prépare à la vie professionnelle doit tenir compte de cela.
    Tjrs développer à partir de zéro ne prépare pas à la vie réelle en entreprise.
    De même, il faut bien s'entraîner à analyser et déboguer des programmes mal codés car ce n'est pas en ayant appris uniquement avec du code propre qu'on est armé pour faire face à un programme codé avec les pieds.
    Je dirai même que comprendre en première lecture un code bien structuré, c'est facile.
    Alors que comprendre un code "pourri", même en s'y prenant à plusieurs fois, c'est nettement plus complexe.

    Une bonne formation doit préparer à la réalité de la vie pro.
    Et dans la vie pro, on est souvent confronter à du code pas propre.
    Y être confronté durant sa formation ce n'est pas le prendre pour norme, c'est au contraire, en tirer des enseignements pour savoir s'y retrouver et prendre conscience des choses à ne pas faire car on en a les conséquences directs (écrire du code naze est une chose, reprendre celui d'un autre est une toute autre expérience)

  10. #30
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 646
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 646
    Points : 30 766
    Points
    30 766
    Par défaut
    Citation Envoyé par Saverok Voir le message
    (.../...)
    Une bonne formation doit préparer à la réalité de la vie pro.
    Et dans la vie pro, on est souvent confronter à du code pas propre.
    (.../...)
    +1

    j'ai eu en 2008 à réécrire entièrement un code COBOL codé avec les pieds en 1972. Et ma spec était : "on c'est que c'est sale, mais ça marche. Tu nous fait la même chose, qui marche pareil, mais propre et documenté"(bon, y'avait un pretexte, le format de sortie était chamboulé. Mais les données devaient rester les mêmes). Sauf que nous n'avions des outils de déboguage qu'en transactionnel, et que c'était du batch. J'ai dansé. Avec des codes du genre :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    A122.
        MOVE 1 TO II
    A12.
        ADD 1 TO II
        MOVE ZZZ(II) TO ZZZZ(II)
        IF II > JJ GO TO A121                                                                       .
        GO TO A12
    A121.
    (.../...)
    le tout, dans un langage qui permet de faire des boucles propres, qui permet des libellés long et parlants, qui permet de mettre des END-IF au lieu d'un atroce point en bout de ligne qui le ferme alors qu'on ne le voit pas, qui connait le else, etc... Et il y avait des boucles beauuuuuuucoup plus complexes que ce bête garnissage de tableau. J'aurais vraiment aimé, dans ces conditions, avoir un debugger, et pas juste une trace.

    dans ce cadre, l'argument "si c'est seulement pour comprendre le code d'un autre, c'est un manque de maitrise du langage aussi" ne passe pas. Un code crade est crade, point. Et tout ce qui permet de mieux l'appréhender est le bienvenu. Et c'est quand même horriblement fréquent. J'attire l'attention du lecteur sur l'ordre apparemment aléatoire des labels(cibles des GO TO). Quand on est confronté à ça(et ça m'est arrivé dans plusieurs endroits), il ne s'agit plus de maitrise. Il s'agit de survie. Et tous les coups sont permis - tant que le résultat, lui, est lisible.

    pour les curieux, la boucle "propre" en COBOL :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
        PERFORM VARYING I FROM 2 BY 1 UNTIL I > TAILLE-TABLEAU
            MOVE TABLEAU-ENTREE(I) TO TABLEAU-SORTIE(I)
        END-PERFORM
    Sans être aveuglant d'élégance pour les aficionados du Python, J'ose espérer que ça vous parait quand même plus civilisé...
    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.

  11. #31
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    février 2014
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : février 2014
    Messages : 18
    Points : 18
    Points
    18
    Par défaut Le débogage partie importante du développement
    Quel que soit le projet il convient de de prendre un papier et un crayon de noter le but de son élaboration, sa structure et les points important importants qu'il faut avoir à l'esprit. Ensuite passer à l'écriture et enfin tester l'appli pour la déboguer. Cette dernière étape étant incontournable. En effet, qui peut dire avoir penser à tout avant l'écriture du code. Le débogage contribue, nécessairement, à parfaire la formation personnelle de chacun.

  12. #32
    Membre du Club
    Homme Profil pro
    Formateur en informatique
    Inscrit en
    décembre 2005
    Messages
    35
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Formateur en informatique

    Informations forums :
    Inscription : décembre 2005
    Messages : 35
    Points : 44
    Points
    44
    Par défaut
    Si on applique la démarche TDD, écrire les tests avant le code, le test est la pour s'assurer du bon fonctionnement, moins besoin de débuguer.

    Si on code en appliquant les bonnes pratiques : SOLID, DRY, YAGNI, KISS, qui mènent à une faible complexité cyclomatique, et donc la possibilité de tester facilement et de tester en découplé.

    On va éviter pleins de debugages qui prennent du temps.

  13. #33
    Membre du Club
    Homme Profil pro
    Formateur en informatique
    Inscrit en
    décembre 2005
    Messages
    35
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Formateur en informatique

    Informations forums :
    Inscription : décembre 2005
    Messages : 35
    Points : 44
    Points
    44
    Par défaut
    Citation Envoyé par Jujubegood Voir le message
    Quel que soit le projet il convient de de prendre un papier et un crayon de noter le but de son élaboration, sa structure et les points important importants qu'il faut avoir à l'esprit. Ensuite passer à l'écriture et enfin tester l'appli pour la déboguer. Cette dernière étape étant incontournable. En effet, qui peut dire avoir penser à tout avant l'écriture du code. Le débogage contribue, nécessairement, à parfaire la formation personnelle de chacun.
    Les tests unitaires et automatisés diminuent cette incontournable que vous sitez...
    La démarche RED, GREEN, REFACTOR permet aussi d'avancer plus simplement vers l'objectif...

  14. #34
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 894
    Points : 7 195
    Points
    7 195
    Par défaut
    Citation Envoyé par le_tisseur Voir le message
    Si on applique la démarche TDD, écrire les tests avant le code, le test est la pour s'assurer du bon fonctionnement, moins besoin de débuguer.
    Moins ne veut pas dire qu'on en a pas besoin. Et comme souligner par une autre personne, un test auto c'est presque du debuggage. Avec TDD, le premier reflexe suite à l'apparition d'un bug (en dev, en prod ou autre), sera de recréer le cas dans les TU, comme quand tu lanceras ta séance de débuggage.
    L'avantage c'est qu'avec TDD, les TUs ainsi créés pourront être gérer en conf et ratisseront surement beaucoup plus large que de poser une garde (TU + assertions) sur uniquement la/les classes en cause après avoir trouvé le bug.

    Citation Envoyé par le_tisseur Voir le message
    Si on code en appliquant les bonnes pratiques : SOLID, DRY, YAGNI, KISS, qui mènent à une faible complexité cyclomatique, et donc la possibilité de tester facilement et de tester en découplé.
    Attention, ces sigles sont le reflet d'important concept mais il ne faut pas oublier ce qui en découle :
    SOLID revient à créer beaucoup de classe avec de petits rôles. Cela complexifie la navigation et parfois la représentation que l'on a du système. Idem pour DRY.
    YAGNI tend dans certains cas à créer des bugs. En effet dans le monde des bisounours tous les cas sont prévus et ont été spécifiés. Dans la vraie vie tu vas remonter le problème à un responsable qui ne tranchera jamais ou qui balancera un "ca n'arrivera jamais", en d'autres mots "tu n'en auras jamais besoin".

    Sinon je connais un moyen d'éviter les bugs (dans le code) : la méthode B. Mais cela n'empêchera pas un bug de spécification. Sauf le jour où on saura spécifier formellement le monde et son évolution ...
    Donc on a encore devant nous de nombreuses heures à traquer les anomalies qu'elles soient dans une méthode/procédure/macro/..., dans l'intégration de classes/librairies/systèmes/..., dans une spécification/cahier des charges/mail/.. ou ...

    Les matières purement informatique n'ont pas à vocation à apprendre l'esprit d'analyse. Les matières plus générales sont bien mieux adaptées. Car le débogage n'est rien d'autre que de l'analyse (au sens purement "cognitif", et non "conception de système"). La seule leçon utile qui s'applique éventuellement à l'informatique, je peux la donner 5 minutes : "Réduire le problème à sa plus simple expression" et ensuite décrire le problème. Rien qu'avec ça, 75-80% du travail est fait.
    Le débogueur, les logs, les "print" etc. n'étant que des moyens de feedback (une vue sur ce qui et quoi se passe).

    Après ce sera surtout l'expérience qui parle. Inutile de dédier des cours à cela. Du code écrit, compilé, exécuté, analysé et ... débogué les étudiants en verront plein durant leur apprentissage de l'écriture de code.
    Ce n'est pas non plus parce qu'une chose prend du temps qu'elle est complexe, ni même qu'on y consacre une part importante de l'enseignement. Dormir prend beaucoup de temps, pourtant personne ne nous l'a enseigné ...
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  15. #35
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 158
    Points : 7 829
    Points
    7 829
    Par défaut
    Logan Mauzaize
    Je partage ton commentaire sauf la fin

    Citation Envoyé par Logan Mauzaize Voir le message
    Ce n'est pas non plus parce qu'une chose prend du temps qu'elle est complexe, ni même qu'on y consacre une part importante de l'enseignement. Dormir prend beaucoup de temps, pourtant personne ne nous l'a enseigné ...
    Par contre, il existe des méthodes pour optimiser son sommeil
    Les objets connectés permettent d'analyser son sommeil pour l'optimiser et c'est des techniques largement utilisées par les navigateurs en solitaire, notamment.

    C'est la même chose pour le débogage
    Il existe des outils dédiés qui permettent d'optimiser cette phase et des trucs et astuces qui le facilite bien...
    Consacrer 1 ou 2 TP au débogage au cours du cursus ne me paraît pas déconnant.

    Ce n'est pas parce que l'on sait faire quelque chose qu'il n'est pas possible de l'optimiser (d'autant plus quand on est autodidacte sur le sujet)

  16. #36
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 894
    Points : 7 195
    Points
    7 195
    Par défaut
    Citation Envoyé par Saverok Voir le message
    Par contre, il existe des méthodes pour optimiser son sommeil
    Les objets connectés permettent d'analyser son sommeil pour l'optimiser et c'est des techniques largement utilisées par les navigateurs en solitaire, notamment.
    [...]Ce n'est pas parce que l'on sait faire quelque chose qu'il n'est pas possible de l'optimiser (d'autant plus quand on est autodidacte sur le sujet)
    Attention à ne pas vouloir créer une "usine à expert". Il faut être conscient qu'en sortant d'une école, un jeune diplômé soit encore en friche.
    Le diplôme n'ouvre qu'une voie sur une multitude de métier et donc une grande diversité de compétence et de manières de les utiliser.

    Citation Envoyé par Saverok Voir le message
    C'est la même chose pour le débogage
    Il existe des outils dédiés qui permettent d'optimiser cette phase et des trucs et astuces qui le facilite bien...
    Consacrer 1 ou 2 TP au débogage au cours du cursus ne me paraît pas déconnant.
    Le problème avec le débogage c'est que tous les débogueurs ne disposent pas des mêmes fonctionnalités. Et que son fonctionnement est fortement lié à la représentation du code dans un langage donné. Après tout c'est bien son rôle, coller l'exécution du programme à sa représentation en code source.
    Je n'ai qu'une expérience en débogage Cobol (sous Windows avec AcuBench), avec le C++ (avec ???) et Java (avec Eclipse/Netbeans). Mais de mes souvenirs, ce fut à chaque fois expérience différente. L'art du débogage me semble plus lié à la capacité de faire le lien entre le code et son fil d'exécution. Ce qui me semble important avant tout c'est d'avoir une bonne représentation de ses lignes de code.

    Après il est vrai qu'abordé ce travail au cours de quelques TPs ne feraient surement pas de mal. Mais seulement ne mérite peut-être pas des TPs exclusivement dédié à cette notion. Par exemple, la robustesse (dans son ensemble : gestion des erreurs, de bonnes traces, reprise, etc.) mérite surement plus d'attention.

    Bref, de toutes façons mes propos faisaient écho à :
    Citation Envoyé par Amine Horseman Voir le message
    Les formateurs de CodeUnion pensent qu’elle est la compétence la plus précieuse que nous pourrions enseigner.
    « 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?
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  17. #37
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    7 184
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 184
    Points : 9 310
    Points
    9 310
    Billets dans le blog
    1
    Par défaut
    Plutôt surprenant comme discussion, on dirait en regardant les réponses qu'on ne fait pas tous le même métier...

    Pour ma part, on pourrait aborder le debug en cours mais sans approfondissement parce que les outils de debug ne se valent pas tous et n'ont pas les mêmes fonctionnalités.

    Ceux qui disent que faire du debug ne sert à rien me font doucement rigoler ! Ou il travaille sur des codes ne dépassant pas les 50 lignes et avec une seule classe qui les utilise, ou eux et leur égo ne passent pas les portes

    Dans les applications modernes (conséquentes), les interactions entre différents modules, bibliothèques, api diverses, couches... sont telles qu'il est presque impossible de tout prévoir. Même les tests unitaires ne peuvent garantir le bon fonctionnement du tout...
    Il me paraît plus important que les cours mettent l'accent sur les tests unitaires que sur le debug, le minimum qu'on puisse (et qu'on devrait) garantir est que la brique logicielle fonctionne correctement de manière autonome... pour le reste, il y aura le debug, ou la vieille méthode à base de log (la misère quoi )
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  18. #38
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 158
    Points : 7 829
    Points
    7 829
    Par défaut
    Citation Envoyé par OButterlin Voir le message
    Plutôt surprenant comme discussion, on dirait en regardant les réponses qu'on ne fait pas tous le même métier...
    C'est effectivement le cas
    DVP est un site des professionnels de l'informatique et l'informatique est un domaine très vaste qui regroupe pas mal de métiers différents
    Tout le monde ici ne fait pas du dev, ou pas exclusivement
    Et même dans le dev, il y a énormément de variantes et de sensibilités différentes.


    Citation Envoyé par Logan Mauzaize Voir le message
    Ce qui me semble important avant tout c'est d'avoir une bonne représentation de ses lignes de code.
    Je suis parfaitement d'accord avec ça
    Il est évident qu'avec un programme parfaitement construit, une granularité des méthodes bien dosée, des variables bien nommées et des TU en veux-tu en voilà, le débogage est rarement utile et lorsque cela arrive, il est aisé

    Malheureusement, la réalité est souvent très différente
    Quand on débute, on a rarement une conception aux petits oignons
    De même, en entreprise, pressé par les délais, les TU passent parfois (voir souvent) à la trappe et lorsqu'ils sont écrits, ils ne sont pas forcément ultra complet
    Pour finir, le pus important, on débogue rarement ses propres lignes de codes mais souvent celles écrites par d'autres
    Nos lignes de code entrent souvent en interaction avec le code existant et c'est souvent là que ça coince.

    L'expérience fait énormément mais cela ne remet pas en cause la nécessité d'une bonne formation adaptées aux réalités du terrain

  19. #39
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 894
    Points : 7 195
    Points
    7 195
    Par défaut
    Citation Envoyé par Saverok Voir le message
    Je suis parfaitement d'accord avec ça
    Il est évident qu'avec un programme parfaitement construit, une granularité des méthodes bien dosée, des variables bien nommées et des TU en veux-tu en voilà, le débogage est rarement utile et lorsque cela arrive, il est aisé
    Attention, je parle bien de représentation et non de présentation. J'évoque plus une carte mentale (mind map) que la forme que l'on donne au code. Ceci dit c'est peut-être l'exercice de construction de carte mentale qu'il faut développer chez les étudiants ?
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  20. #40
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    7 184
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 184
    Points : 9 310
    Points
    9 310
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Saverok Voir le message
    Il est évident qu'avec un programme parfaitement construit, une granularité des méthodes bien dosée, des variables bien nommées et des TU en veux-tu en voilà, le débogage est rarement utile et lorsque cela arrive, il est aisé
    Tout ceci est largement subjectif, ce qui va te paraître clair, limpide, sera un véritable merdier pour un autre...
    Rien que pour les noms de variables c'est déjà la foire d'empoigne entre développeurs, pour ce qui est de la structure du code c'est pareil, la "norme" en java veut que l'accolade ouvrante d'une classe ou méthode se trouve sur la même ligne que son nom, chez nous on préfère à la ligne (perso, je trouve ça bien plus lisible), etc...

    Dans tous les cas, je ne place pas le debug au même niveau, on l'utilise pour suivre l'exécution pas à pas lorsqu'on n'a pas d'idée sur l'origine du dysfonctionnement... et ça arrive souvent avec le nombre de boites noires qu'on assemble ou la manie de certains de faire des try catch de tout et n'importe quoi
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

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, 01h07
  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, 22h06
  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, 11h59
  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, 19h14
  5. Réponses: 11
    Dernier message: 02/11/2006, 17h12

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