Envoyé par
Washmid
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.
Envoyé par
Amine Horseman
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.
Envoyé par
Amine Horseman
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.
Envoyé par
Amine Horseman
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 |