Discussion :

[ypicot]

(1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?
Il me semble comme un défi ou une erreur de frappe (c'était sur une calculatrice programmable, il y a plus de 25 ans)

(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?
plus de 2 semaines. Je cherchais à afficher un pixel VGA en asm, et la doc était très pauvre. Et puis, un jour, j'ai augmenté la luminosité de mon écran... Il m'a fallu 3 jours pour commencer à m'en remettre.

(3) Et depuis, comment voyez-vous les bogues ?
Comme un exercice de logique, version "jeu des erreurs"

(4) De quelle manière concevez-vous à présent vos programmes ?
Au maximum en XP/TDD, comme cedricgirard (et qques autres)

(5) Employez-vous une technique particulière pour concevoir vos programmes ?
XP / TDD

(6) De quelle manière déboggez-vous vos programmes ?
Suivant l'environnement : print (python) ou débogguer (VB, Delphi, C#)

(7) Employez-vous une technique particulière pour déboggez vos programmes ?
Un point qui me parrait important : anticiper la valeur des variables (dans la tête ou sur un bout de papier), puis vérifier si la valeur est conforme à ce qu'on attend.
Sinon, on peut passer 20 fois avec le déboggueur sur l'erreur, en regardant d'un oeil bovin (et le cerveau vide) ce qui se passe à l'écran.

(8 ) Quels outils personnels ou non utilisez-vous pour gagner du temps (ou autres) dans la réalisation de vos programmes ?
Papier - crayon - neurones - parfois Poseidon ou WinDesign

(9) En quoi consistent t'ils ?
Parfois Windesign ou Poseidon - neurones - papier - crayon

Yvan

[plaineR]

(1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?
Comme un défit, il fallait que je le trouve absolument.

(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?
Plus d'une semaine, je sais plus exactement, il s'agissait d'un problème conceptuel, il fallu "casser" tout une partie du code.

(3) Et depuis, comment voyez-vous les bogues ?
Cela dépend de l'origine des bogues. Si c'est un bogue "technique" cela m'ennerve, le développeur aurait pu faire attention... Si c'est un bogue "fonctionnelle", je suis plus zen (on ne peut pas toujours penser à tout), même si ce ne sont toujours les plus simples à corriger.

(4) De quelle manière concevez-vous à présent vos programmes ?
Sur papier d'abord pour bien penser à toutes les implications (il n'y a rien de pire que des erreurs de conceptions). Cela me permet également de voir les parties qui seront utilisées plus d'une fois pour étudier l'intérêt de créer des unités de programmes (procédures, fonctions, ...) pouvant être appelés (diminution des risques de bogues et simplification des tests et des corrections).
Ensuite avant de commencer à taper le code, j'écris tout le programme sous forme de commentaire, il ne me reste plus qu'à traduire par la suite.

(5) Employez-vous une technique particulière pour concevoir vos programmes ?Méthode XP (en général). On fait une base simple qui fonctionne, puis on la complète. Cela passe comme précisé dans la question précédente par des unités de programme. Il est plus facile de tester n unités de programmes qu'un énorme programme.

(6) De quelle manière déboggez-vous vos programmes ?
J'essaie de reproduire le bogue, puis de le cerner.

(7) Employez-vous une technique particulière pour déboggez vos programmes ?
J'ajoute des traces (insertion dans une table de debogage) de toutes sortes (étape, valeur d'une variable, ...) dans mon programme. Et à partir de ces traces, j'essaie de comprendre où cela pose problème et qu'est-ce qui pose problème.

(8 ) Quels outils personnels ou non utilisez-vous pour gagner du temps (ou autres) dans la réalisation de vos programmes ?
Une procédure qui inscrit dans une table de debogage.

(9) En quoi consistent t'ils ?
cf . 8

Si la méthode de programmation et de debogage peut-être sensiblement identique à tous les langages, les outils de debogage sont propres au langage que l'on utilise, du moins me semble-t-il...

Pour moi les 2 règles essentielles à respecter pour un debogage efficace sont :
- un code bien commenté (toujours plus facile à comprendre ce que le développeur a voulu faire)
- un découpage en entité simple (ainsi on trouve plus facilement où est le problème et on ne corrige qu'à un seul endroit)

[Thierry Chappuis]

(1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?

Je me suis tappé la tête contre les murs, tellement je ne trouvait pas ou était le problème. C'était mon tout premier programme (en C) et c'était une bête erreur de synthaxe.

(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?

plus d'une semaine, je crois...

(3) Et depuis, comment voyez-vous les bogues ?

Comme une erreur de programmation dont j'assume la responsabilité.

(4) De quelle manière concevez-vous à présent vos programmes ?

J'utilise fréquemment des techniques de preuve formelle pour valider l'algorithme proposé avant d'écrire le code. J'essaie de concevoir les tests pour chaque bout de code avant d'écrire le code lui même et valide chacun de ces morceaux avant de les insérer dans le tout.

(5) Employez-vous une technique particulière pour concevoir vos programmes ?

Je structure mes programme en hiérarchisant mes programmes en utilisant la puissance des concepts de la POO (encapsulation maximale, héritage et polymorphisme). J'utilise les méthodes de développement AGILE et eXtreme Programming, avec UML.

(6) De quelle manière déboggez-vous vos programmes ?

Avec gdb sous Linux. J'essaie dans un premier temps de faire une analyse de reproductibilité de l'erreur et d'évaluer son domaine d'occurence. Je définit des points d'arrêt. Puis PAS-à-PAS sur les morceaux de code suspects.

J'utilise assez peu de printf.

(7) Employez-vous une technique particulière pour déboggez vos programmes ?

voir ci-dessus

(8 ) Quels outils personnels ou non utilisez-vous pour gagner du temps (ou autres) dans la réalisation de vos programmes ?

rien d'autre que emacs et gcc/gdb

(9) En quoi consistent t'ils ?

-

Très intéressant ce post! Meilleures salutations

Thierry

[mis_dj]

(1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?
j'ai débuté en programmation "sérieuse" a l'université, mon premier prog était un mini logiciel pour le calcul rapide des réducteurs de vitesse ( visual C++ )
pour mon premier bug j'était perdu, heureusement qu'il y avais les camarades plus expérimenté pour donner un coup de main
(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?
environ une semaine a s'arracher les cheveux
(3) Et depuis, comment voyez-vous les bogues ?
les bugs c'est inévitable dans un prog, le tout c'est de mettre assez d'info dans ses prog pour svoir ou ca bug et la provenance
(4) De quelle manière concevez-vous à présent vos programmes ?
j'ai adopté depuis longtemps l'approche modulaire, des petites fonctions indépendantes courtes et simples ( je programme principalement des algo scientifiques et numériques et ca marche bien)
(5) Employez-vous une technique particulière pour concevoir vos programmes ?
il faut toujours mettre les idées sur papier ( écrire l'algo qu'on veut coder ) une fois bien définis on commet moins de fautes
(6) De quelle manière déboggez-vous vos programmes ?
execution pas a pas ou avec des "breakpoint" bien choisis, avec controle des variables et du comportement.
(7) Employez-vous une technique particulière pour déboggez vos programmes ?
nan pas vraiment
(8 ) Quels outils personnels ou non utilisez-vous pour gagner du temps (ou autres) dans la réalisation de vos programmes ?
j'ai appris une chose primordiale "ne jamais réinventer la roue" en claire chercher des bibliothèques sérieuse qui font ce qu'on veut faire et ne les coder que si elles n'existent pas !!! ( moins d'erreurs et du code plus optimisé )

[gangsoleil]

(1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?
Appréhendé ?
Je ne dirai pas que je l'ai appréhendé. Comme je débutais en programmation, je savais que j'allais en avoir. le plus difficile reste lorsqu'on relit le programme de savoir où est ce fichu bug.

(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?
Difficile à dire.
Ca dépend si tu comptes depuis la découverte d'un éventuel problème non reproductible dans le code, ou bien depusi le moment où le bug est identifié, et "qu'il ne reste plus qu'à le corriger".

(3) Et depuis, comment voyez-vous les bogues ?
Comme des erreurs. Comment les voir autrement ?

(4) De quelle manière concevez-vous à présent vos programmes ?
Ca dépend du programme. Celui dont le but est d'afficher "Hello world", je le fais comme ca, sans réfléchir. Sinon, j'essaye de bien penser à toute l'architecture du programme en fonction du résultat attendu.

(5) Employez-vous une technique particulière pour concevoir vos programmes ?
Non.

(6) De quelle manière déboggez-vous vos programmes ?
Tests unitaires, tests de non-reg, vérification des algorithmes, et logiciels de vérification de code.

(7) Employez-vous une technique particulière pour déboggez vos programmes ?
Identifier l'erreur dans le code, puis voir d'où elle vient, et la corriger...

(8 ) Quels outils personnels ou non utilisez-vous pour gagner du temps (ou autres) dans la réalisation de vos programmes ?
Rien de bien spécial.

(9) En quoi consistent t'ils ?
...

[AjJi]

(1) Si mes souvenirs sont bons l'un des premiers "bug" que j'ai eu, c'est quand j'oubliais le main()
On peut dire que ce n'est pas un bug, mais après qd je voyais que j'avais oublié, j'étais mort de rire.
Maintenant, le main() c'est dans la source par défaut, comme ça je suis tranquille
(2) hmm, p-ê 2 ou 3h, pour l'instant, je n'ai jamais travaillé sur des projets de milliers de lignes, donc je n'ai pas trop de problème
Mais, les bugs les plus difficiles que j'ai rencontré c'est avec des pointeurs
(3) Hmm, je pense que les bugs c'est une "étape" important dans la vie d'un developpeur
Si tu rencontres un bug, et que tu trouves un solution.. la prochaine fois tu résoudera le problème plus rapidement, tu pourras même l'éviter.

(4) Pour l'instant je programme essentiellement en C, donc j'essaye surtout d'adopter une programmation procédurale et d'éviter tout ce qui est contraire à cette logique (comme les goto-like).
(5) hmm, ca depend, des fois j'ai besoin d'un papier crayon pour élaborer un algo, mais en général je programme directement sur machine, pas à pas, en compilant à chaque fois, comme ca j'évite l'accumulation des erreurs

(6) printf(); power
Quelques fois, j'essaye d'utiliser le debugger de dev-c++.
(7) goto (6)
oops, je le ferai plus

(8 ) dvp.com
non, à part mon compilateur, rien d'interessant
(9) ...

[hansaplast]

(1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?
bein, j'ai relut ma premiere ligne...
non en fait j'etait paumé (autodidacte, sans bouquin)
(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?
4 mois...
... et il est toujours pas resolut... une composante trop ambitieuse qu'on m'a imposé...
(3) Et depuis, comment voyez-vous les bogues ?
cela depend, je voit assez bien les complexe (y'a une limte) mais je reste tres souvent bloqué sur, par exemple une invertion de lettre (j'inverse toujours les lettres :'( )

(4) De quelle manière concevez-vous à présent vos programmes ?
detruire pour mieux reconstruire : je maquette a la va vite, et au fur et a mesure, je recode en dur... j'a pas la formation, ni le niveau pour fair mieux
(5) Employez-vous une technique particulière pour concevoir vos programmes ?
cf : 4
pour les partie plus ambitieuses : modelisation a donf, sur papier, meme si on suit pas la logique au final, vraiment commencer par apprehender les pb qu'on va rencrontrer, meme si on peut pas tous les prevoir. de meme eviter de faire des ofnctions foure tout... avec 9 parametres...

(6) De quelle manière déboggez-vous vos programmes ?
php : j'ai une classe de debug que je reutilise + var_dump
c++ : deboggueur (que je maitrise tres mal) (dev-cpp)
(7) Employez-vous une technique particulière pour déboggez vos programmes ?
l'acharnement

(8 ) Quels outils personnels ou non utilisez-vous pour gagner du temps (ou autres) dans la réalisation de vos programmes ?
reutilisation do'bjets generiques, mes propres "design patterns" => suiivre toujours plus ou moins la meme logique de nommage, de fonctionnement, et commenter, bcp de commentaires
(9) En quoi consistent t'ils ?
cf :8
Si vous voyez d'autres questions de bases ou astuces qui permettent d'augmenter les connaissances techniques, n'hésitez pas à en faire-part.

===> lire les post sur dvp.com, meme si on peut pas les resoudre, ca ouvre l'esprit

[jobherzt]

(1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?
comme quelque cose de normal.. je m'etais planté quelque part, quoi..
(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?
je ne sais plus.. ca doit etre de l'ordre de 2 semaines
(3) Et depuis, comment voyez-vous les bogues ?
ca depend. je n'ai pas la hantise du bug qui surviendra dans un cas tres particulier, vu que je ne programme pas en genereal pour un utilisateur final plus ou moins vague et incompetent.
(4) De quelle manière concevez-vous à présent vos programmes ?
je ne fais pas de schema, mais j'ai appris, a force, aprevoir le coup de pouvoir modifier les algo facilement : je separe clairement les choses, je cree beaucoup de fonction, je reflechis beaucoup aux strcutures que j'utilise (je pense que c'est la base de tout), et j'utilise rarement les types tels quels : j'ai souvent un typedef qui traine, par exemple.
(5) Employez-vous une technique particulière pour concevoir vos programmes ?
non
(6) De quelle manière déboggez-vous vos programmes ?
a coup de cout en general, je me retrouve avec un defilement cryptique de données absconnes, et je dois reperer ce qui cloche.. apres je remonte, plus ou moins par dichotomie.. la technique ultime : je met des cout << "jusqu'ici tout va bien" un peu partout, et quand ca va plus, j'ai localisé le pb :-)
(7) Employez-vous une technique particulière pour déboggez vos programmes ?
non... sauf quand j'ai des segmentation fault, la technique des cout devient caduque, la je passe a un debugger.

(8 ) Quels outils personnels ou non utilisez-vous pour gagner du temps (ou autres) dans la réalisation de vos programmes ?
scite pour l'editeur de texte. octave, vu que je fais dans la science, pour generer des données de test
(9) En quoi consistent t'ils ?
octave c'est un equivalent Matlab libre.

[mathk]

(1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?

Avec l'envie irésistible d'aller voir ce qui ce passe

(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?
1, 2 jr

(3) Et depuis, comment voyez-vous les bogues ?
Avec des testes unitaires

(4) De quelle manière concevez-vous à présent vos programmes ?
Little step by little step. Really

(5) Employez-vous une technique particulière pour concevoir vos programmes ?
Le refactoring

(6) De quelle manière déboggez-vous vos programmes ?
Avec un bon debuggeur genre celui dans squeak (Smalltalk)

(7) Employez-vous une technique particulière pour déboggez vos programmes ?
J'inspect tout car c'est facile en squeak (Smalltalk)

(8 ) Quels outils personnels ou non utilisez-vous pour gagner du temps (ou autres) dans la réalisation de vos programmes ?

None

(9) En quoi consistent t'ils ?

NA

[souviron34]

(1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?

franchement je me souviens plus (il y a 25 ans).. Je pense juste en me disant "ben merde où ça peut bien ne pas marcher ?"

(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?
Environ 3 semaines.


(3) Et depuis, comment voyez-vous les bogues ?
quelque chose de normal ... En petit nombre ;-). Mais en gros en général il y en a 2 sortes :
a) on s'est trompé dans le type d'un paramètre de fonction
b) on a oublié qu'il se passait autre chose autre part..

(4) De quelle manière concevez-vous à présent vos programmes ?
euh....
Longue longue réflexion..... d'où analyse, et conception...
Puis allez hop...

(5) Employez-vous une technique particulière pour concevoir vos programmes ?
non. Voir ci-dessus

(6) De quelle manière déboggez-vous vos programmes ?
tests opérationnels, d'abord par moi-même, puis par plusieurs personnes (dont des utilisateurs finaux)

(7) Employez-vous une technique particulière pour déboggez vos programmes ?
Comme je fais beaucoup d'IHM, un valideur officiel national m'a dit un jour (pour un logiciel médical) : "si vous cliquez une journée entière sans regarder et que ça n'a pas crashé, vous avez déjà passé 80%". Donc déjà j'applique ça. Ensuite je teste chaque fonctionalité, en essayant les cas les plus pervers. Mais (et c'est pour ça qu'au point 6 j'ai dit avec plusieurs personnes) étant le concepteur j'ai forcément des à-priori. Donc les tests par d'autres, y compris les utilsateurs finaux, sont indispensables.

(8 ) Quels outils personnels ou non utilisez-vous pour gagner du temps (ou autres) dans la réalisation de vos programmes ?

ddd
printf
#define

[edit] : je relis la question et je m'aperçois que ce n'est pas pour le debug.

Donc je dirais : aucun outil. Je trouve qu'apprendre autre chose (qui ne fera que rajouter une couche supllémentaire) n'est pas forcément un gain de temps. Bien sûr, suivant les langages et les projets, il y a des outils (Delphi, NetBeans, etc..). Mais si je m'en sers, je ne m'en sers que comme démarrage..

[/EDIT]

(9) En quoi consistent t'ils ?

* si j'ai un crash (coredump) je prends un debugger (style ddd sous linux) pour savoir où ça se passe
* si je sais à peu près où ça se situe, je mets des "printf" aux endroits stratégiques (extrêmement rapide)
* enfin, si le problème semble complexe (pas d'évidence de mauvaise fonction, de dépassement de tableaux, etc..) je mets des parties de code en commentaires par des "ifdef MONTEST". Je peux arriver à 98% du code en commentaire. Et là petit à petit je remets des parties

[Rakken]

Pour ma part, je programme principalement en php, mais j'ai fait pas mal de C également.

(1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?
Aucun souvenir ce que qu'était mon premier bogue. Je garde de ca juste une espece de frustration parce que je ne comprennais pas ce qui se passait (et je n'avais pas encore les méthodes de débuggage pour comprendre).

(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?
Plusieurs jours, parce qu'il a fallu le traquer a travers un framework avec des tonnes de couches d'abstractions.
(3) Et depuis, comment voyez-vous les bogues ?
Comme des trucs à erradiquer.

(4-5) De quelle manière concevez-vous à présent vos programmes ?
Je commence avec une feuille et un crayon. Je commence par poser ce que visuellement je veux obtenir au final, ensuite, je crée mon modèle de donnée, puis je me fait mentalement une architecture globale de mon programme.
Une fois que c'est fait, je commence a coder.

(6-7) De quelle manière déboggez-vous vos programmes ?
Il faut trouver "le fil", et le remonter. Quand il y a un bug, je part de son effet visible, et je le traque, je remonte de fonction en fonction pour trouver la source.
Pour ca, je blinde mon code de echo, print_r, var_export, log, die...
Si j'ai les outils sous la main, j'utilise un programme pas a pas avec des breakpoints.

(8-9) Quels outils personnels ou non utilisez-vous pour gagner du temps (ou autres) dans la réalisation de vos programmes ?
Eclipse avec le plugins qui va bien pour le langage.
Des debuggeurs quand j'en ai sous la main. Pas de préférence particulière.
PhpMyAdmin ou autre pour pouvoir lancer des requêtes "a la main" et les tester.

[freemac]

(1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?
J'arrose le tout de printf avec des gros-mots car c'est une source d'inspiration rapide et inépuisable (pour ne mettre 2 fois le même mot et pouvoir localiser celui qui ne s'affiche pas...)
(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?
Une semaine : inspiration de codage à la rache effectué, on lance et on débug, c'était plus rapide pour coder en fait... avant la méthode propre ^^'
(3) Et depuis, comment voyez-vous les bogues ?
Comme pour développer, ça fait partie du jeu.
(4) De quelle manière concevez-vous à présent vos programmes ?
J'écrit les algo en français, je met en commentaires le tout, je code => j'obtiens du code commenté
(5) Employez-vous une technique particulière pour concevoir vos programmes ?
(4)==(5) fatal error;
(6) De quelle manière déboggez-vous vos programmes ?
je trace : j'entoure l'appel d'une fonction avant et après de ##########
en partant des fonctions globals, je trace parfois aussi les + appelés.
log, mode debug... et autres belles fonctions perso pour tirer des info d'une variable
(7) Employez-vous une technique particulière pour déboggez vos programmes ?
je copie la ligne de déclaration de la fonction avec les paramètre et je le colle en première ligne et je l'entoure d'un printf (plus besoin d'inspiration )
(8 ) Quels outils personnels ou non utilisez-vous pour gagner du temps (ou autres) dans la réalisation de vos programmes ?
J'ai un ami qui transformait la profondeur de la pile des fonctions en une note de musique, ça fait des ultrasons quand ça bug...
Principalement des outils de traçage : grep... ou injections brutal pour les projets perso (sed d'un (if param1="mot cherché" log nom fonction))
(9) En quoi consistent t'ils ?
(8)==(9) 2 fatal error => die();

[screetch]

(1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?

non, ca doit marcher, je comprend pas ! il y a pas de bug la ! c'est la machine qui a tort !

(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?
2 heures environ. car j'avais plus d'experience en debuggage.
ensuite si c'est au niveau du temps passé pour mesurer la difficulté, les bugs les plus difficiles sont les bugs a retardement : ils sont posés et activés quelque part, puis, dans un autre endroit qui n'a rien a voir, a un moment qui n'a rien a voir, BAM! ca pète. Ca peut prendre du temps de trouver la cause.

(3) Et depuis, comment voyez-vous les bogues ?
en s'approchant tres tres pres je commence a les voir ^^


(4) De quelle manière concevez-vous à présent vos programmes ?
je ne comprend pas trop cette question, ni la suivante !
(5) Employez-vous une technique particulière pour concevoir vos programmes ?
je ne comprend pas trop cette question, ni la precedente !

(6) De quelle manière déboggez-vous vos programmes ?
tout depend du bug. il y a de nombreuses techniques differentes :
- dichotomie : desactiver completement un bout de code, si le bug a disparu, reactiver et desactiver un bout plus petit, jusqu'a cerner la portion qui declenche le bug
- reflexion : analyser sans executer le code jusqu'a comprendre comment on peut faire echouer
- printf : lorsqu'i lest dur de savoir ou ca plante, cerner le code avec des printf jusqu'a voir lequel ne s'execute pas. afficher la valeur d'un compteur, etc.
- debuggage a la hache : quand ca marche vraiment pas, on coupe et on attend que ca repousse! quand quelqu un se plaindra du code manquant il le reecrira!!!
(7) Employez-vous une technique particulière pour déboggez vos programmes ?
en general je pars toujours de la consequence (le bug) pour retrouver la cause.
Access violation => quelle est l'adresse => d'ou vient cette adresse => pourquoi est elle invalide => correction.
Double deletion => qui appelle les delete => qui devrait avoir la propriété... etc etc


(8 ) Quels outils personnels ou non utilisez-vous pour gagner du temps (ou autres) dans la réalisation de vos programmes ?
(9) En quoi consistent t'ils ?
mon cerveau. il consiste en un enchevetrement de neurones qui... ah pardon. serieusement, quand un probleme de memoire est detecté il m'est possible 9 fois sur 10 de le resoudre grace aux codes de remplissages de la memoire allouée/libérée/non initialisée que l'allocateur de Visual Studio utilise.

[fenkys]

1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?
Aucune idée, ça fait 25 ans quand même

(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?
3 jours, le bug ne se produisait que sur une seule machine à laquelle je n'avais pas accès.

(3) Et depuis, comment voyez-vous les bogues ?


(4) De quelle manière concevez-vous à présent vos programmes ?
En reflechissant avant de coder.

(5) Employez-vous une technique particulière pour concevoir vos programmes ?
Un cahier et un crayon

(6) De quelle manière déboggez-vous vos programmes ?
De toutes les manières possibles : debuggeur, analyse du code, trace dans des logs, etc.

(7) Employez-vous une technique particulière pour déboggez vos programmes ?
Voir 6

(8 ) Quels outils personnels ou non utilisez-vous pour gagner du temps (ou autres) dans la réalisation de vos programmes ?
Pour gagner du temps aucun. Les outils que j'utilise permettent aux autres de gagner du temps en rendant mon code accessible ou permettent de gagner en fiabilité. En pole position CVS et doxygen.

Accessoirement cela permet 2 ans après de reprendre un programme sans se demander pourquoi on a fait tel truc et pas un autre.

(9) En quoi consistent t'ils ?
En outils

[_vince_]

(1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?

Je ne me rappelle plus.

(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?

Ca fait plusieurs mois que je fais de la maintenance corrective. Il faut bien distinguer les deux phases:
- la premiere ou tu cherches le bug et tu ne comprends pas ou il se cache
- la deuxieme ou tu as trouves la cause et tu cherches a le corriger.
En general, la premiere phase est beaucoup plus longue que la deuxieme.

Le plus long bug a corriger m'a bien pris deux semaines. Je lisais, relisais et relisais sans cesse le code pour essayer de comprendre ce qu'il se passait. Et un beau jour, la lumiere est apparue. Finalement, ca ne sert a rien de rester bloque la tete sur l'ecran pendant des heures. Il faut passer a autre chose, revenir apres et c'est la qu'on voit le probleme.

(3) Et depuis, comment voyez-vous les bogues ?
Comme des caracteristiques inevitables des programmes. Mais pour moi le plus gros bug est le programmeur qui n'est pas conscient qu'il inserera toujours des bugs et qui n'utilise pas de techniques de programmation defensive pour s'en proteger. Les bugs sont inevitables mais il existe des techniques qui permettent de les identifier plus rapidement, comme la programmation defensive.

(4) De quelle manière concevez-vous à présent vos programmes ?
Avec ce qui me sert de cerveau, papier, crayon. Et en essayant d'anticiper les cas particuliers. Car un programme se resume a faire ce qu'on attend de lui mais surtout a gerer des cas particuliers, dit non-nominaux. Ces cas ne sont bien sur pas specifier clairement et tombe sous le coup du : "ah! le logiciel n'est pas robuste a tous les cas possibles et inimaginables qu'on n'aurait jamais pu imaginer!!!"

(5) Employez-vous une technique particulière pour concevoir vos programmes ?
UML, POO.
Programmation defensive. Des assertions
Je dirais qu'il faut aussi etre discipline et rigoureux et penser a ceux qui reliront le code dans 1 ou 2 ans.
Je suis peut etre pointilleux mais quand je vois qu'on stocke une valeur positive dans un entier signe au lieu de non signe, ca m'enerve. Celui qui passe derriere, se demande pourquoi ce blaireau de pseudo informaticien n'a pas ete plus scrupuleux.

(6) De quelle manière déboggez-vous vos programmes ?
Avec un debogueur en pas a pas, avec des printf.

Avec des assertions. Pour avoir deboguer des programmes ecrits par d'autre, je suis toujours etonne de voir un programme sans aucune assertion. Plusieurs de ces bugs auraient pu etre evite par une simple assertion.
Je suis un grand fan des assertions. C'est comme jeter un filet de peche. Plus les mailles sont petites, plus vous attrapez de poissons. Plus il y a d'assertions, plus vite vous trouvez les bugs.
Il faut aussi faire attention aussi a ne pas introduire de bugs avec trop de programmation defensive. ;-)

Pour finir, j'aimerais dire aux professeurs de programmation dans les ecoles d'ingenieur ou a la fac qu'il faudrait aussi qu'ils apprennent a leurs eleves les bases de la programmation defensive. Mais ce sujet necessite un cours a lui tout seul tellement il est vaste.

Et pour finir vraiment, je conseille a tous ceux qui veulent s'ameliorer le bouquin "tout sur le code" de steve mcconnell. Il est un peu cher mais il vaut le coup je pense.

[NikoGJ]

J'ai 23 ans (l'heure ou j'écris ce message :p), commencé la prog vers 11-12 ans et je programme depuis 4-5 ans principalement avec des langages web (javascript (x)html et php pour ne citer que ça..)

(1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?

Les joies des premiers programmes ^^

(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?

Ca a du bien durer plusieurs heures, voir une journée entière.

(3) Et depuis, comment voyez-vous les bogues ?

Quand il y a pas de bugs au premier lancement d'un programme, c'est louche...très louche ^^

(4) De quelle manière concevez-vous à présent vos programmes ?

Un rapide diagramme de classe, un schéma relationnel, beaucoup de papier brouillons avec des schémas dans tous les sens, puis code..

(5) Employez-vous une technique particulière pour concevoir vos programmes ?

Coder, repenser l'architecture, re-coder, re-repenser l'architecture, re-re-coder. C'est un peu de l'XP mais en repartant de zéro à chaque fois

(6) De quelle manière déboguez-vous vos programmes ?

Déjà, trouver le bug. En passant par un utilitaire de déboguage, un gestionnaire d'erreurs

(7) Employez-vous une technique particulière pour déboguez vos programmes ?

Isoler le bug: mettre des commentaires les lignes de code un peu de partout pour garder le strict minimum de code exécuté (ça c pour les gros gros bug, ceux qu'on trouve pas au premier coup d'œil)
Utilisation des print, echo, alert en tout genre pour afficher les valeurs des variables à tel moment de l'exécution
Utilisation des exceptions pour remonter des cas non traités et juger de la nécessité de traiter ces cas individuellement ou pas.
Pour résoudre le bug: 2 choix:

• le choix caca: on met un 'if' pour contourner le bug
• le choix plus propre: on recode la fonction ou la méthode plus proprement

(8 ) Quels outils personnels ou non utilisez-vous pour gagner du temps (ou autres) dans la réalisation de vos programmes ?

Firebug, Webdevelopper, console de certains frameworks...

(9) En quoi consistent t'ils ?

Ben...à afficher les bugs...

[g_tarik0010]

J'ai commencé à programmer depuis 4 ans et ceux avec des differents langages (c++ cli ,c#, java, javascript)

(1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?

J'ai copié la solution de mon ami

(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?

Tout un weekend(problème de référence croisée en c++) c'était mes débuts en c++.

(3) Et depuis, comment voyez-vous les bogues ?

Un mal necessaire . Car un prog sans bogues est un bogue

(4) De quelle manière concevez-vous à présent vos programmes ?

Parfois un schema suffit mais la plupart du temps une bonne conception OO s'impose

(5) Employez-vous une technique particulière pour concevoir vos programmes ?

Partir d'une fonctionalité elementaire et qui s'enrichit au fur et à mesure tout en respectant les normes de la POO

(6) De quelle manière déboguez-vous vos programmes ?

En passant en premier lieu par une relecture du code puis du pas à pas et les fichiers logs. En principe ca résoud un bogue mais ca dengendre un autre

(7) Employez-vous une technique particulière pour déboguez vos programmes ?

J'utilise une technique apprise en cours de communication (proceder par elimination des doutes (je met en commentaire à chaque fois un bout de code et je verifie son impacte sur le déroulement du programme

(8 ) Quels outils personnels ou non utilisez-vous pour gagner du temps (ou autres) dans la réalisation de vos programmes ?

IDE (Eclipse, VS.2005) parfois du block notes afin de corriger des bugs en prod

(9) En quoi consistent t'ils ?

J'ai pas compris votre question

[fdejaigher]

Précision : type de développement : Intra/extra et internet (serveurs LAMP)

(1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?

"Chouette mon premier bug, ça va devenir interessant !"
Je programais en Basic sur un Amstrad CPC 464, des petites applications persos, donc pas de panique, au contraire.

(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?

Pas loin de 2 jours...

(2bis) Comment avez-vous, finalement, résolu ce bug ?

Faute de trouver, j'ai commencé à discuter de ce bug à une collègue qui n'y connait rien en dev. J'ai expliqué globalement, en lui faisant voir la structure globale, et là d'un coup c'était sous mes yeux

(3) Et depuis, comment voyez-vous les bogues ?

Assez mitigé, dans un sens je préfère tomber tout de suite dessus plutôt que de voir que tout semble fonctionner jusqu'à la mise en production.

(4) De quelle manière concevez-vous à présent vos programmes ?

Par bloc. J'adapte un nouveau bloc, je teste au fur et à mesure du possible.
Puis un test complet avant mise en production.

(5) Employez-vous une technique particulière pour concevoir vos programmes ?

Grande réflexion, puis sur papier je note ce que j'ai compris de la demande, je la schématise et la valide avec la demande. Et quand tout est validé, là je commence à faire une approche post-pissage de code.

(6) De quelle manière déboggez-vous vos programmes ?

j'ai testé différents outils de debug pour le PHP, mais bon ça ralentissait mes tests. (Voir 4)

(7) Employez-vous une technique particulière pour déboggez vos programmes ?

La structure de base sur laquelle je m'appuie étant toujours la même j'y ai intégré une zone Debug dans laquelle sont affichés ce dont je peux avoir besoin.

(8 ) Quels outils personnels ou non utilisez-vous pour gagner du temps (ou autres) dans la réalisation de vos programmes ?

Voir 7, et Eclipse PDT est très pratique aussi (popup sur les éléments attendus de fonctions crées, alerte de bugs de base comme un ; ou une accolade oublié par exemple)

(9) En quoi consistent t'ils ?

Voir 8

[dba01]

(1) A l'époque de vos débuts en programmation, comment avez vous appréhendé votre premier bogue ?
> Impressionnant ! C'était un portable dans lequel l'alimentation ne s'éteint jamais. Et je suis tombé sur une boucle sans fin.
Alors 1/Echap , pas de réaction ; 2/Maj+Ctrl+... pas de réaction ; 3/extinction de la machine , pas de réaction elle continuait ; 4/panique, puis je trouve un petit bouton qui ne se fait plus mais qui m'a sauvé : le reset du processeur. Ouf !

(2) Combien de temps avez-vous passer à résoudre votre plus difficile bogue ?
> Deux jours. Des trous dans le re-calcul rétroactif d'un solde de compte. Mais c'est en touillant mon café au lait le matin que j'ai des idées, au calme avec des neurones tout frais (et les croissants aussi).

(3) Et depuis, comment voyez-vous les bogues ?
> Un jeu, un défi. Un programme qui marche ne m'intéresse pas, à moins qu'il ne me soit utile bien sûr. C'est comme aux échecs : il est passionnant de chercher, mais quand c'est fini on passe à autre chose.

(4) De quelle manière concevez-vous à présent vos programmes ?
> Sur le papier. Lister les données, les procédures, les transformations, les sorties, les questions. Puis recopier dans l'ordre logique, jusqu'à ce que ça tienne sur une seule page et, surtout, dans ma tête. Tant que je n'ai pas une vue d'avion de tout mon fourbi, je ne peux pas commencer, d'autant que je ne sais pas par où attaquer.
> Et puis, surtout, beaucoup de commentaires entre les lignes, voir même des paragraphes dans les cas tordus. Il m'est arrivé de reprendre un programme 10 ans après : pas triste !

(5) Employez-vous une technique particulière pour concevoir vos programmes ?
> Voir ci-dessus

(6) De quelle manière déboggez-vous vos programmes ?
> Ca dépend. Les erreurs d'écriture, fautes de frappe, syntaxe, fautes de déclarations : ça se reconnaît, il suffit de bien relire, avec la doc à la main pour certains cas. Pour les erreurs logiques, j'affiche des données en cours ou des repères de ligne en haut de l'écran, sans oublier un arrêt du genre input ou inkey ou pause etc... et même une sortie sauvage. Il m'est quand même arrivé d'éditer un paquet de papier pour trouver où l'enchaînement était rompu, dans quel(s) cas.
> Cas particulier : le parallèle. Exceptionnellement, un jour, j'ai programmé dans mon micro la simulation d'un truc développé dans un gros serveur. Si les deux n'affichaient pas les mêmes résultats, on pouvait considérer qu'au moins un des deux était faux. Dans ce cas on relit les deux jusqu'à ce que ça marche. Bien évidemment, les tests étaient soigneusement ciblés, car mon micro aurait mis des jours à faire les calculs que la grosse bébête passait chaque minute, et mon disque de l'époque n'aurait pas supporté la base de 500 Gigas sur une trentaine de tables Oracle.

(7) Employez-vous une technique particulière pour déboggez vos programmes ?
> Voir ci-dessus

(8 ) Quels outils personnels ou non utilisez-vous pour gagner du temps (ou autres) dans la réalisation de vos programmes ?
(9) En quoi consistent t'ils ? (correction : en quoi consistent-ils)
> En conservant des petits bouts récupérables : fenêtres de saisie de dates ou de fourchettes de dates, fabrication de fichiers ou de bases, menus déroulants, déclarations de formats ou de librairies, modules de calcul ou transformation usuels. Ensuite copié collé, quelques modifs, et ça devrait rentrer. De plus, je reconnais mes modules habituels facilement dans le texte du programme, rien qu'à la forme, sans même les lire.


Si vous voyez d'autres questions de bases ou astuces qui permettent d'augmenter les connaissances techniques, n'hésitez pas à en faire-part.

> Dans les cas limite, quand c'est vraiment très mal barré, vaut mieux tout jeter et recommencer que d'accumuler des rustines de recadrage. On a perdu des semaines sur des traitements mal foutus, jusqu'à investir trois jours pour réécrire le morceau. On aurait mieux fait de prendre les trois jours dès le début. Surtout quand le patron ne nous paye même pas l'aspirine !

[tasna]

(1) J'ai trouvé ça normal puisque je débutais.

(2) Je ne l'ai jamais résolu et je ne sais pas si j'aurais pu le résoudre.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
int LineLen=strlen(Line);
//Autres opérations sur le chaîne de caractères Line
if(LineLen>=15)
{
     //Suite normale des opérations
}
else
{
     printf("Invalid parameter\n");
}

J'obtenais le message "Invalid parameter" alors que LineLen était strictement supérieur à 15. Et j'ai vérifié ça avec un printf("%i\n",LineLen); juste après strlen() et dans le bloc else.

Depuis ça j'ai vu les bogues comme des problèmes pouvant survenir n'importe quand, même quand tout est logique. Et je n'ai plus envie de concevoir de programmes.

Pour trouver d'où vient le problème je mets des appels de fonctions du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
printf("[DEBUG]\n");

un peu partout dans le code puis j'en ajoute d'autres dans une zone plus ciblée. Ou des fois j'affiche les données manipulées pour voir si c'est le bon résultat des opérations.

Sous Linux j'utilise un simple éditeur de texte et je compile en ligne de commande et sous Windows j'utilise en environnement de développement intégré. Soit Visual C++ Express soit Code::Blocks.