Discussion :

[Fabllot]

Purée les gars ! Je vous trouve violents dans vos propos !
Je crois qu'il faut essayer de s'ouvrir et de comprendre que nos propres méthodes de travail et nos domaines d'applications ne sont pas les mêmes partout !

Alors oui il y a des cas ou le débogueur est inutile, avec une bonne connaissance du langage du code, de la structure du programme, pleins de tests et tout et tout.

Et puis il y a aussi d'autres cas comme par exemple :
- Les IHM : c'est rare de rester très longtemps sur une même technologie. Elles ont toutes leur manière de fonctionner et prévoir tous les cas possible est impossible...
- La téléphonie mobile : tous les 6 mois, un nouveau téléphone, un nouveau framework et qui là encore fonctionne à chaque différemment...
- Le travail d'équipe ou fait par un tiers : tout le programme n'a pas forcément été écrit par nous... mais pourtant il faut le débugger...

Et je crois que je pourrais encore citer d'autres cas dans lequels un debugger PEUT ÊTRE utile. Il ne fera pas tout, mais il peut permettre d'aller plus vite dans la correction des erreurs en ayant une vue d'ensemble des variables, de la pile d'appels, etc... à un moment précis du programme.

Mais tout ne se règle pas au débogueur je suis d'accord, et tous les systèmes ne proposent pas un IDE ou débogueur de qualité.

[gl]

Car tu as l'habitude de mettre en exploitation des programmes complétements bogés !

Parce que ce n'est surtout pas moi qui décide quand mettre en production certains programmes. Il m'arrive de travailler sur du code écrit bien avant que j'arrive dans l'entreprise, voire bien avant que je ne commence à travailler (je suis tombé sur du code écrit à une époque où j'avais une dizaine d'année).

Car parfois les programmes fonctionne bien jusqu'au jour où ... . J'ai par exemple eu le cas d'un programme, que je n'avais pas écrit, qui fonctionnait (ou plutôt semblait fonctionner) parfaitement bien jusqu'au jour où ça à péter lors d'une évolution. L'erreur n'était absolument pas dans l'évolution mais localisé à un tout autre endroit (sans rentrer dans les détails, c'était du à une subtile erreur dans la gestion de l'alignement de structure en mémoire).

Le débogage d'un programme commence, QUAND TOI tu viens de le modifier et que tu fais des tests.

Le problème c'est que je ne suis pas tout seul à travailler dans mon coin. Et que les programmes ont un historique.

Je suppose que tu n'as jamais entendu parlé de recettes techniques, ni fonctionnelle, ni d'intégration ?

Probablement au moins autant que toi.

Si un programme a été écrit par un tiers, je ne vois pas en quoi cela pose un problème ? Le seul problème est de comprendre sa logique qui n'est pas la tienne. Et tu as besoin d'un débogueur pour cela ?

Non, j'ai besoin d'un débogueur quand son code ne fait pas ce qu'il est censé faire dans un cas particulier, que la personne qui l'a écrite n'est pas disponible pour en assurer la maintenance à l'instant t et que je n'ai pas assez de temps pour prendre en main l'intégralité de son code avant de corriger le problème (surtout qu'il n'est pas rare de trouver des codes bien immonde) voire que je n'ai pas les sources.


Bref, ta position est probablement totalement applicable lorsqu'on travaille seul ou avec une équipe de niveau relativement homogène sur un code neuf ou dont l'existant est parfait à tout point de vue. Ou pour résumer si le code (et les dépendances) est nickel-chrome lorsque tu le récupères et que tu ne te préoccupe que de ce que toi tu écris[1].

Malheureusement, on n'est pas tous dans ce cas.



[1] Personnellement, je n'ai jamais eu besoin d'un debogueur pour corriger mon code. Par contre quand je récupère du code de quelqu'un d'autre, quand le bug est dans la lib X ou Y, oui il m'arrive d'y avoir recours.

[el_slapper]

+1 avec gl, mais j'ai fait mieux en 2008 : refonte partielle d'une chaine et de programmes initiés en 1972. Soit 4 ans avant ma naissance. Et ça avait reçu plusieurs couches de maintenance chaque année entre 72 et 2008. Autant dire que j'ai dansé.

Et comme c'était du Cobol, je n'avais PAS de débuggueur. Eh bien ça m'a fichtrement manqué. Il y avait des logiques perverses d'embranchements un peu partout, et je n'ai jamais compris vraiment comment certaines parties marchaient. D'ailleurs, il y a un bout de code qui est resté tel quel, avec ses boucles en GO TO, parceque je n'y ai rien compris, et personne d'autre non plus.

L'autre cas ou l'utilisation du débuggueur a été vraiment utile(et là j'en avait un), c'est quand j'ai fait des scripts de test automatique d'interface. Des scripts qui tournent en 6 heures(et qui doivent tourner tous les jours, parcequ'il y a une compil par jour). Et que quand ça plante au bout de 5 heures, vaut mieux corriger "à chaud" et continuer, sans quoi on perd, ben, 5 heures. Les délais montent très vite, sinon.

[yan]

Ce qui m’étonne c'est les extrêmes. Le tout ou rien. Que Débogueur ou que printf.
A mon avis la question de base est un troll. Et je n'ai vue nulle part où les gourous des langages ont dit que le Débogueur ne sert à rien. A mon avis ils ont juste dit qu'en générale ils n'en éprouvent pas le besoin. Et cela ne veux pas dire qu'ils n'en utiliseront pas un au besoin. C’est une question d'habitude.

Dans mon cas, j'ai changé régulièrement de langage (C, C++, JAVA, C#, AS3, HTML/JS, fortran ) et travaillé sur plusieurs plateforme (SGI, linux, Windows, Android, Windows mobile, bada, flex).

Et quand j'ai la chance d'avoir un débogueur utilisable (même à moitié) ça me simplifie la vie.

Si je trouve le débogueur aussi important c'est surtout parce qu'il m'aide à la relecture de code. Je dois relire un bout de code que j'ai du mal à comprendre. Je fais un break point et je fais un coup de pas à pas. Je peux regarder la call stack et les valeurs des instances. Et mieux comprendre le contexte.

Au printf, tu lis le code, tu suppose une erreur ici et tu l'affiche pour voire. Si ce n'est pas cela, tu recommence. Et c'est pour cela que je préfère un débogueur. Je peux vérifier plusieurs choses sans polluer le code de printf. C'est pour moi plus propre et plus rapide.

Je m'en sers aussi sans break point pour tester les applications. S'il y a un crash, j'ai potentiellement plus d'info pertinente. Si je voie que ce n'est pas normal, je peux faire un break point et regarder en détaille ce qui ne va pas. Quand tu te trouve à un bug qui se produit qu’une fois toutes les 100 exécutions, le printf ne va pas vraiment t'aider.

Et si je ne trouve pas je passe au printf. Car certains bugs sont vicieux et se manifesteront qu'en release dans une exécution normale.

Entre les deux y as les logs.

Je ne pense pas en abuser en faisant cela.

Le débogueur est un outil comme un autre qui pour certains rentre dans leurs logique et pas pour d'autre. C'est comme les langages, on a de l'objet, fonctionnel, ... et faut mieux utiliser celui ou en se sent le mieux.

Y en as qui disent que les testes unitaire suffisent. Pour moi un teste unitaire ne permet que de valider une brique. Et non une application. C'est comme une maison, t'as des briques de super qualité mais ce n'est pas pour cela que ta maison sera bien construite.

Chaque outils (débogueur, printf, log, teste unitaire, méthodologie, valgrind, ...) sont là pour aider. Et chacun ses points positives et négatives. Je ne trouve cela dommage de cracher dessus.

[Guardian]

A mon avis la question de base est un troll.

Mais non, mais non. C'est un forum sérieux ici

Ce qui compte c'est de sortir un logiciel qui fonctionne, avec le moins de bugs possible (et aucun bug fonctionnel), facile à utiliser et qui satisfait le client.
La méthode, chaque développeur à la sienne et elle dépend de l'outil utilisé. On ne gère pas son code de la même façon pour tous les langages et la seule vraie bonne méthode est celle qui donne de bons résultats pour le langage concerné pour un développeur donné.
Le reste... Ha bin si, c'est du troll

[TropMDR]

Réponse à TropMDR :
[...]
b) Je crois que vous confondez l'écriture d'un programme et sa mise au point. Une telle erreur en C ne nécessite pas un débogueur. L'anomalie détectée lors de l'exécution, vous savez automatiquement la nature de cette erreur.

Euh non, un dépassement de tampon ou un double free, justement, on ne sait pas "automatiquement la nature de cette erreur". Et même si on sait que c'est un double free, dans un programme de 10 000 lignes, 100 000 lignes, ou encore plus, ça ne veut pas pour autant dire qu'on sait où il se trouve...

d) Je crois que vous n'avez pas une grande expérience dans la recherche des anomalies.

Je l'admet, puisque quand je prouve mes programmes, quand il y a un problème, je vois exactement où il se trouve.

Il arrive qu'une erreur est détectée à un endroit précis du programme mais que la cause est ailleurs.

D'où l'intérêt du débuger et de sa pile d'appel, voir même de sa capacité à remonter dans le temps !

Le débogueur ne vous sera d'aucune utilité pour son identification. Vous constaterez simplement le fait.

J'ai un peu l'impression que pour vous, débuger == le message "segmentation fault"... En vrai, c'est un peu plus informatif que ça...

e) Pour un "length" au lieu d'un "length -1", ce sont les tests fonctionnelles qui vous dirons la nature du problème. Je ne vois pas à quoi sert dans ce cas un débogueur.

Pour la n-ième fois, les tests permettront de détecter qu'il y a un problème, pas forcément où il se trouve.

Un gros programme est un peu plus que la somme de ses partie. Ont ne peut pas écrire toutes les sous parties d'un programme de façon parfaitement modulaire et indépendante. Il y a bien un moment où il va falloir que ça communique hein ! Alors tester chaque sous partie indépendement, c'est bien sur indispensable, et comme ça, quand un tête fait claquer une assertion ou fait segfaulter, on sait où on est. Mais il y a aussi un moment où il va falloir tester l'ensemble. Et là, bizarrement, c'est moins précis.

Je ne sais pas dans quel langage vous programmez, mais il me semble que par exemple dans les langages à gestion manuelle de la mémoire, il est assez facile de se tromper dans la politique de désallocation. Pour peu qu'un module A ait habilement conservé un pointeur vers une structure qu'un module B pense pouvoir supprimer, on aura un problème uniquement une fois que les deux modules seront "ensemble" dans le programme global.

f) Ah OUI ! Alors expliquez moi, gros malin que vous êtes, pourquoi les concepteurs de langage n'utilisent pas les débogueurs ? Puisque c'est le thème de ce thread !

Plein de raisons ont été proposés. Peut être qu'ils ont la chance de travailler dans des milieux calmes, où ils n'ont pas obligations de pondre un code énorme en un temps microscopique, ce qui les obligerait à utiliser des lib extérieurs dont les invariants sont malheureusement implicites. Peut être qu'ils sont tout simplement tellement meilleurs que le commun des mortels qu'ils ne font plus jamais de double free, de dépassement de buffer, de fuite de pointeur vers stackframe, mais que des bugs "fonctionnels", où le débugger est éventuellement moins utile. Ou peut être même qu'ils sont les créateurs de langages beaucoup plus sûr, où le débugger est encore moins utile. Voir même juste inexistant (par exemple en Coq, je n'ai pas de débugger, mais je n'ai pas non plus de printf ) Et puis ce n'est pas parce qu'un maitre n'utilise pas un outil que ceux qui l'utilise sont des débiles ou des incompétents. Ca veut peut être dire qu'ils ne sont pas des maîtres. Et encore.

[super_bus]

J'ai l'impression d'halluciner en vous lisant ?!?!?!? Sommes-nous sur la même planête ?

Je vais faire une mise au point. D'abord je travail sur gros système en IBM avec COBOL & PACBASE, JCL et DB2. Lorsque je veux modifier un programme, je dois en faire la demande. Ce qui fait qu'à partir du moment où je récupère ce programme, je suis le seul à pouvoir le modifier. D'autre part, je le récupère de la production, donc en aucune façon il est bogué. Ce n'est pas possible, puisque ce programme est opérationnel. Ensuite, il est recopié dans mon environnement de travail qui est un environnement de test d'informaticien et non un environnement de test d'utilisateur. Par exemple, je le modifie, suite à une maintenance. Et ensuite je le teste. Je n'ai pas besoin d'un débogueur car je sais forcément ce que je viens de faire puisque dans le programme nous indiquons toujours nos intervention. De plus, nous avons la possibilité de comparer l'ancien code (celui de la production) avec le nouveau code (ce que je viens de modifier). Si j'ai un bogue, je sais forcement l'origine de celui-ci.

Donc en principe je sais ce que je fais et je peux toujours revenir en arrière puisque j'ai à ma disposition la version de la production.

Admettons que je n'arrive pas à localiser l'origine de mon erreur par la simple logique de mes modification. Alors j'utilise, par encadrement les DISPLAY. A ma connaissance, toutes les personnes qui travailles procèdent de cette façon. Et pourquoi donc ? Car déboguer un programme en cobol consiste soit à récupérer l'adresse de plantage du programme et par encadrement à trouver le lieu du plantage où soit à faire une trace du déroulement de l'exécution du programme. Dans ce cas nous récupérons dans un fichier sysout (un fichier d'impression au format texte) toutes les étiquettes (nom des paragraphes) par lesquelles nous sommes passés.

Donc voila comment nous procédons ! Nous avons, soit par encadrement avec des DISPLAY, soit à partir d'une adresse système le lieu du plantage, ou soit le lieu du plantage après la dernière étiquette lors du traçage. Ensuite c'est au petit bonheur la chance pour comprendre pourquoi le programme s'est planté. Donc un débogueur ne me sert à rien car trop compliqué à utilisé et par un encadrement sous la forme de DISPLAY, je trouve le lieu du plantage.

Ensuite si tu connais un débogueur de qualité sur gros système, fait-le moi savoir car je n'en connais aucun, ni mes collègues de boulots.

J'ai travaillé aussi en UNIX, avec le C, et par simplicité, nous avons procédé par des encadrements de PRINTF.

Peut-être que toi tu as la chance d'avoir un débogueur de qualité et qu'en plus on t'a formé dessus, mais dans beaucoup d'entreprises, les débogueurs n'existent pas et en plus, ceux qui existent sont trop compliqués à l'usage.

Donc si je n'ai pas de débogueur à ma disposition, je dois trouver un moyen de résoudre mes problèmes. Et la seule solution, c'est l'encadrement par DISPLAY ou PRINT selon le langage et la compréhension du code.

Si tu as une meilleure solution que celle-là, je suis tout ouïe ! ! !

[yann2]

oui bah le printf/dysplay/sysout... c'est du debug, non ? (j'aime radoter)

un programme sans bug

[TropMDR]

Sommes-nous sur la même planête ?
[...]
D'autre part, je le récupère de la production, donc en aucune façon il est bogué. Ce n'est pas possible, puisque ce programme est opérationnel.

La réponse est clairement "non". Parce que sur la mienne, "être en production" n'implique clairement pas "ne pas être bugué"

Et ensuite je le teste. Je n'ai pas besoin d'un débogueur car je sais forcément ce que je viens de faire puisque dans le programme nous indiquons toujours nos intervention. De plus, nous avons la possibilité de comparer l'ancien code (celui de la production) avec le nouveau code (ce que je viens de modifier). Si j'ai un bogue, je sais forcement l'origine de celui-ci.

Il ne t'arrive donc jamais de déclencher un bug dans une partie A en modifiant une partie B, soit parce que tu as cassé une logique (un invariant) implicite et non documenté de la partie A, soit parce que tu es tombé sur un corner case non précédemment testé ?

Ensuite c'est au petit bonheur la chance pour comprendre pourquoi le programme s'est planté. Donc un débogueur ne me sert à rien car trop compliqué à utilisé et par un encadrement sous la forme de DISPLAY, je trouve le lieu du plantage.

Là encore, nous ne vivons pas sur la même planète. Parce que chez moi, entre "sans débogueur, c'est au petit bonheur la chance" et "donc un débogueur est inutile", encore une fois, il n'y a pas de lien logique... Il y aurait presque même une franche contradiction...

[zaventem]

D'autre part, je le récupère de la production, donc en aucune façon il est bogué.

Bien sur

Que la version en production ne contienne aucun bug identifié, je veux bien te croire, de là à dire qu'il n'y en a pas...

Les seuls qui peuvent se targué d'être zero-bug sont les programmes mathématiquement prouvés et je crois comprendre que tu es loin de travailler dans un domaine qui emploie ces techniques...

[yan]

Je vais faire une mise au point. D'abord je travail sur gros système en IBM avec COBOL & PACBASE, JCL et DB2. Lorsque je veux modifier un programme, je dois en faire la demande. Ce qui fait qu'à partir du moment où je récupère ce programme, je suis le seul à pouvoir le modifier. D'autre part, je le récupère de la production, donc en aucune façon il est bogué. Ce n'est pas possible, puisque ce programme est opérationnel.

Je ne connais aucun logiciel qui peux être certifié sans BUG. Regarde Ariane, linux, windows, office, ...
C'est très robuste mais çà arrive que cela plante. Et parfois ça explose

Donc un débogueur ne me sert à rien car trop compliqué à utilisé et par un encadrement sous la forme de DISPLAY, je trouve le lieu du plantage.

Ensuite si tu connais un débogueur de qualité sur gros système, fait-le moi savoir car je n'en connais aucun, ni mes collègues de boulots.

J'ai travaillé aussi en UNIX, avec le C, et par simplicité, nous avons procédé par des encadrements de PRINTF.

Dans ton cas je ferais pareil, et je comprend mieux ton point de vue. Pour mon premier projet, j'ai développé sur SGI. gdb était bien trop compliqué à utiliser et j'ai fait du printf. Cela ne m'as pas empêché de corriger le programme et d'ajouter des fonctionnalités. Dans cette environnement, le débogueur n’était pas si utile. Au contraire. Par contre j'éditais les sources sous windows avec source insight (très bon outils pour parcourir entre les sources) qui m'as grandement sauvé la vie pour relire et comprendre ce qui est fait.
Avec le recul, je pense que je serais allé 2-3 fois plus vite si j'avais eu un EDI avec un débogueur intégré.

Mais il y as eu beaucoup d'évolution. En COBOL je ne sais pas. Mais Si tu repasse à du C,C++ ou un des nouveau langage, les débogueurs sont devenu plus simple et plus performant. Déjà ils sont intégrées au EDI ce qui permet de lire le code en même temps.

[Fabllot]

Donc un débogueur ne me sert à rien car trop compliqué à utilisé et par un encadrement sous la forme de DISPLAY, je trouve le lieu du plantage.

On ne dit pas le contraire ! C'est juste le raccourci "Je n'utilise pas de débogueur pour une bonne raison" donc "les débogueurs c'est nul et ceux qui les utilisent sont des fainéants, des écervelés, des développeurs du dimanche" (dure cette dernière insulte ! ) qui est un peu vite fait.

Je comprends que sur ton domaine, ton système l'usage d'un débogueur est difficile, et sans doute qu'à ta place on ferait la même chose. Je travaille parfois aussi sur des systèmes sans débogueurs car trop pénibles à utiliser (ex: BADA), et du coup là j'utilise le "printf" (ou équivalent).

Par contre j'avoue (je revendique même !) que j'utilise des débogueurs quand je peux, quand le système le permet...
Ce qu'on (je) dit est juste : l'usage d'un débogueur est intéressant dans certains cas, et il ne faut pas avoir peur de l'utiliser car il peut grandement aider.

[B.AF]

Ce qu'on (je) dit est juste : l'usage d'un débogueur est intéressant dans certains cas, et il ne faut pas avoir peur de l'utiliser car il peut grandement aider.

Oui.

Ton raisonnement est très juste (pour moi)

Moi je pointe juste le petit supplément qui est de dire qu'il n'est pas nécessairement possible pour tous en fonction de son expérience d'arriver à cette conclusion.

[Guardian]

J'ai l'impression d'halluciner en vous lisant ?!?!?!? Sommes-nous sur la même planête ?

Il me vient aussi une question : es-tu réellement développeur ?

je le récupère de la production, donc en aucune façon il est bogué. Ce n'est pas possible, puisque ce programme est opérationnel.

Ha pardon, tu avais déjà répondu à la question.
Clairement, c'est non

[super_bus]

C'est bien ce que je dis, j'hallucine ?!?!?!?!? On ne vit pas sur la même planète !

réponse à Yann2 : bien sûre que DISPLAY, PRINTF ou COUT sont des méthodes archaïques pour déboguer un programme, mais lorsqu'on n'a pas un environnement pour débogueur, comme en VISUAL C++, tu fais comment ?

Réponse à TropMDR : a) le gros de notre travail n'est pas de faire du développement mais du recettage. Et c'est ce qui prend le plus de temps et de patience. Nous recettons grandeur nature dans un environnement dédié à ca (identique à la production). Et je confirme qu'en fonction du cahier des charges, nous devons respecter les spécificités demandées. Et donc je confirme que l'on ne peut pas mettre un programme bogué en production. Car au recettage on détectera ce bogue et on le corrigera immédiatement. Donc je ne sais pas comment tu travailles mais on ne procède pas comme toi.

b) Bien sur que OUI pour les parties A et B, mais NON pour l'autre cas. Car je suis dans une phase de maintenance et de recettage. L'autre cas n'arrive pas, car si en production cela plante alors c'est le dernier qui a modifié le programme qui doit corriger l'erreur, mais en général c'est un cas qui arrive que très rarement car nous n'aurions pas vu cette anomalie durant le recettage de mise au point, ni dans le recettage fonctionnel, ni dans le recettage d'intégration. Au fait, je ne sais pas en combien de temps tu passes de la récupération d'un programme pour maintenance à la mise en procduction, mais il arrive couramment que nous mettions plusieurs semaine car nous ne livrons pas un programme mais une nouvelle version de l'application.

c) Relis mon post et tu comprendras que nous n'avons pas de débogueur en gros système. Si tu ne me crois pas renseigne toi. Tu verras !

Réponse à zaventem : non, je confirme aucun bogue connu et testé. Maintenant si pour une raison inconnue, dans un fichier en entré d'une application, il y a une zone numérique non renseignée correctement et qui provoque un ILLEGAL DECIMAL DATA, si ton programme plante, ce n'est pas lui qui est responsable mais bien le programme qui devait fournir un fichier sans cette anomalie. Les mauvaises manipulations à l'exploitation, ça existe, mais ce n'est pas du recourt des études, mais bien un problème d'exploitation.

Si tu pars de ce principe, aucun programme même le plus simple ne peut tourner. Il ne faut quand même pas exagérer. Mathématiquement prouvé ne veut rien dire. Un programme fonctionne ou ne fonctionne pas. Faite des tests grandeur nature et là vous serez capable de dire si il est bogué ou pas. Mais si vous ne vérifiez pas votre travail alors OUI il existera toujours un doute.

Réponse à yan : je ne développe pas des logiciels mais des applications. Un système d'exploitation est un logiciel. Un ensemble de programmes répondant à un besoin spécifique d'utilisateur est une application. Tous tes exemples sont des logiciels et je ne suis pas ingénieur système mais ingénieur d'étude en gros système sous IBM, MVS TSO/ISPF avec le COBOL, JCL, DB2 et CICS. Ce n'est pas le même métier. De plus je suis d'accord avec toi sur ton exemple, plus le logiciel est gros et plus il risque d'avoir des bogue non décelable.

Je précise encore une fois qu'en gros système nous n'avons pas de débogueur. Alors nous avons notre expérience et le système D.

Réponse à Fablot : Je dis simplement que si tu veux évoluer dans ton métier tu dois apprendre à développer selon des normes de méthodologies. Sinon le débogueur sera pour toi une béquille et tu ne pourra plus t'en passer. Mais alors comment tu feras, pour déboguer ton programme si tu n'as pas de débogueur. Explique moi comment tu fais ?

Réponse à B.AF : Oui je suis d'accord avec toi, à la condition d'en avoir un de débogueur. Mais si tu n'en as pas, tu fais comment ?

Réponse à ArielD : je suis ingénieur confirme en informatique. Je pratique l'informatique depuis trente ans environ, j'ai débuté en 1979 lors de mon entré à l'IUT. Mais à l'inverse de vous je ne fais pas de la micro mais du gros système. Mais si tu ne connais pas la façon de travailler en gros système tu ne peux pas affirmer que je ne suis pas développeur et encore moins que la production ne contient que des programmes bogués.

[B.AF]

Ce que tu dis finalement c'est juste. Il y a toujours la théorie qui est optimale et forcémment supérieure et la pratique qui est forcémment mauvaise parce que les "gens" ne comprennent rien où n'ont pas compris.

Moi l'histoire m'a toujours prouvé que le développeur qui te fait les plus grands discours sur la méthode et la qualité est souvent celui qui fait le code le plus crade. Pour la simple et bonne raison que quand tu as travaillé sur des systèmes complexes, tu sais que tu ne fais pas de la bonne pratique mais de l'optimisation de contraintes.

L'essentiel étant que finalement, on se rend compte que d'avoir un contrôle possible sur les états et les contenus est constant, et que parfois, faute de grives, on mange des merles.

[super_bus]

Alors si je comprends ce que tu dis , utiliser une méthodologie est contre productive ?

[TropMDR]

Réponse à TropMDR : a) le gros de notre travail n'est pas de faire du développement mais du recettage.

Ha bah là tout de suite, ça en jette plus.

Et donc je confirme que l'on ne peut pas mettre un programme bogué en production.

Non, encore une fois, tu ne peux pas mettre en production de programme avec un bug... connu. Ca n'a tristement jamais voulu dire "sans bug" :-\


En fait ce que je ne comprends pas dans toutes tes histoires de recettage et tout c'est: vu qu'il n'y a pas de bug, ça consiste en quoi la maintenance ?

c) Relis mon post et tu comprendras que nous n'avons pas de débogueur en gros système. Si tu ne me crois pas renseigne toi. Tu verras !

Alors arrête de dire que ça ne sert à rien, juste que tu n'as pas la chance de pouvoir t'en servir !@#

Maintenant si pour une raison inconnue, dans un fichier en entré d'une application, il y a une zone numérique non renseignée correctement et qui provoque un ILLEGAL DECIMAL DATA, si ton programme plante, ce n'est pas lui qui est responsable mais bien le programme qui devait fournir un fichier sans cette anomalie.

Après, moi, un programme qui plante sur une donnée corrompue, j'appèle ça un programme bogué. "Nan mais comprenez, il y a une injection SQL sur le site de prod, mais c'est pas un bug, c'est parce que le mec il a mis "'; delete * from talbledelamort --", c'est pas de notre faute !"

Mathématiquement prouvé ne veut rien dire.

Euh, si, ça veut dire qu'il existe une preuve mathématique que le programme satisfait à 100% sa spécification, et ce sur toutes les entrées possibles.

Un programme fonctionne ou ne fonctionne pas.

Il faut arrêter l'informatique, tu commences à tout voir en binaire

je ne suis pas ingénieur système mais ingénieur d'étude en gros système sous IBM, MVS TSO/ISPF avec le COBOL, JCL, DB2 et CICS.

T'as une carte de visite format A4 ?

[Fabllot]

Réponse à Fablot : Je dis simplement que si tu veux évoluer dans ton métier tu dois apprendre à développer selon des normes de méthodologies. Sinon le débogueur sera pour toi une béquille et tu ne pourra plus t'en passer. Mais alors comment tu feras, pour déboguer ton programme si tu n'as pas de débogueur. Explique moi comment tu fais ?

Quelles normes ? Celles de mettre des printf ? C'est une norme ça ? Déjà pour jouer sur les mots c'est peut-être un "standard" parce-que beaucoup font comme ça, mais je considère vraiment pas cela comme une norme !
Et puis qui t'as dit que je travaillais sans normes de méthodologies ? Mes collègues te diront que je suis certainement un des plus "chiant" sur les normes de codages et les procédures.
Mais je vois pas là le conflit entre utiliser un débogueur et respecter des normes ?

Ensuite pour me répéter, je développe régulièrement sur des plateformes mobiles (type BADA) où le débogueur est tellement minable que je ne l'utilise pas, ou en web avec du PHP. Et dans ce cas j'utilise le "printf", et malgré cela je continue tout autant à trouver les bugs dans mes programmes ou à d'autres...

Ce que je dis c'est pourquoi ne pas utiliser un débogueur quand les conditions optimales de son utilisation sont réunies (qui ne sont pas les tiennes - j'ai bien compris), alors qu'il peut être utile et te faire gagner du temps ? Ou pourquoi creuser un (gros) trou à la petite cuillère alors que tu as une pelle ?

[super_bus]

En fait ce que je ne comprends pas dans toutes tes histoires de recettage et tout c'est: vu qu'il n'y a pas de bug, ça consiste en quoi la maintenance ?

La maintenance est soit évolutive ou soit corrective. Évolutive signifie que nous avons soit à ajouter de nouvelles fonctionnalités afin de perfectionner l'application, soit ce sont des changement de réglementations.

Pour la maintenance corrective, il ne s'agit pas de réparer quelque chose qui ne fonctionne pas dans la version actuelle mais de rendre compatibilité l'application avec une nouvelle version. Exemple : un programme accède à une table DB2 dont on a ajouté un nouveau champs. Ce programme n'utilise pas ce champs, mais l'emplacement de ce champs dans le passage des informations au programme utilisateur provoque un décalage qui rend tous les autres champs inexploitable.

Alors arrête de dire que ça ne sert à rien, juste que tu n'as pas la chance de pouvoir t'en servir !@#

OUI d'accord, mais nous procédons autrement. Et de ce fait je dis que cela ne nous sert à rien.

D'après, moi, un programme qui plante sur une donnée corrompue, j'appèle ça un programme bogué.

Non pas forcément. La cause peut-être diverse. Tu ne peux pas garantir que les données qui te sont fournies en entrée de ton application ne soit pas corrompue. Exemple d'un transfert de fichier entre deux sites qui plante. Le fichier étant disponible, on lance l'application (en batch). Il plante. Et après identification de l'erreur (en exploitation, par les comptes-rendu du traitement et non par un débogueur) on s'aperçoit que le transfert ne sait pas fait correctement. Alors on recommence le transfert et tout ce passe bien.

Euh, si, ça veut dire qu'il existe une preuve mathématique que le programme satisfait à 100% sa spécification, et ce sur toutes les entrées possibles.

Mais pourquoi mathématique ? Détail ce que tu entends part mathématique !