Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 à enseigner

Le , par Amine Horseman

0PARTAGES

7  0 
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 » ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de air-dex
Membre expert https://www.developpez.com
Le 27/11/2014 à 20:25
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.
5  0 
Avatar de nirgal76
Membre chevronné https://www.developpez.com
Le 28/11/2014 à 8:03
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
5  0 
Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 28/11/2014 à 11:22
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.
5  0 
Avatar de CodeurPlusPlus
En attente de confirmation mail https://www.developpez.com
Le 03/12/2014 à 20:59
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 !
5  0 
Avatar de Logan Mauzaize
Rédacteur/Modérateur https://www.developpez.com
Le 08/12/2014 à 14:02
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é ...
5  0 
Avatar de OButterlin
Modérateur https://www.developpez.com
Le 10/12/2014 à 9:20
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 )
5  0 
Avatar de BugFactory
Membre expérimenté https://www.developpez.com
Le 27/11/2014 à 13:54
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.
4  0 
Avatar de
https://www.developpez.com
Le 27/11/2014 à 20:44
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...
4  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 04/12/2014 à 10:53
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à....
4  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 05/12/2014 à 14:05
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)
4  0