Recherche:

Oui, mais pas en automatique. C'est ça, que je voulais dire. il FAUT tester, ne pas le faire relève de la faute professionelle. Mais ça n'est pas possible de manière automatique. Donc, quand on...

Je suis d'accord avec tout le reste de ton discours. Mais pas avec ça. On ne progressera pas en se jetant à la gueule des "mon métier est plus difficille que le tien" mutuels. Nous avons TOUS des...

Mais nous vivons dans un monde réel. Shit happens. Et il faut la nettoyer.



c'est probablement possible dans un monde peuplé uniquement de développeurs. et encore : de développeurs ayant tous...

Pour le GC, j'en sais rien. Je n'ai pas fait assez de java pour avoir un avis pertinent. Je sais juste que celui de VBA pour excel contient un trou(quand une collection d'objets contient elle-même...

Et même là, ça dépend. Pour du transactionnel, ça peut se comprendre. J'ai plein de batches qu'on préfère planter en cas de doute, histoire de prendre le temps de tout vérifier avant de le laisser...

C'est clair. Mais j'ai quand même des doutes. Je pense que c'est à adapter en fonction des circonstances.

Pour des applications "techniques"(je ne sais plus qui nous a parlé de son compilateur),...

Là, par contre, 100% d'accord avec toi, Nemek. Quand le système d'information devient très complexe, exiger la perfection de tous les intervenants, c'est aller au casse-croute. Perso, j'ai tendance à...

C'est plus que gênant, c'est impensable. Des centaines d'applis dépendent du batch comptable de la nuit.



Non, parceque le reste du monde en dépend(on est dans une banque, hein, la compta,...

Je ne dis pas que c'est impossible de tester un batch. Je dis que tester automatiquement une transaction qui dépend d'un batch qui, quel que soit l'environnement, tourne une fois par jour, est à la...

C'est l'éternel combat de l'abstraction contre la maitrise. L'abstraction augmente la productivité, parfois de manière drastique, mais possède toujours des fuites.



Euh, voyons, la compta d'une...

Tu bosses sur des trucs 100% techniques, manifestement. Dans ce cadre, tu as surement raison. Quand on fait essentiellement du fonctionnel(dans le sens "métier", pas dans le sens "langage...

+1, mais ça dépend aussi des outils qu'on a. J'utilise très souvent le débuggueur sur VBA pour Excel, quasiment jamais sur Cobol. Essentiellement parceque le débuggueur cobol qu'on a ne correspond...

+1, mais celà suppose que l'ancienne application soit fiable, et que les données soient comparables. Et que la hiérarchie comprenne ce que ça veut dire. Y'en a qui m'ont donné 5 semaines pour...

J'ai l'impression que Souviron blaguait sur le fait que le rôle de l'armée, précisément, est de tuer des gens.....

Celà étant, il est probable que ce genre d'approche méthodique et systémique...

En d'autres termes, ce sont des méthodes hors de portée du commun des mortels. Il est bien possible qu'elles rendent le débugging obsolète. Mais le prix me parait prohibitif, en termes de...

Je suis globalement d'accord avec toi, mais je ne suis pas sur de ce que tu appelles l'overhead. Si c'est une fuite de mémoire, alors en COBOL, c'est impossible. Ce qui pose pas mal de problème pour...

+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...

En même temps, le TDD ne permet pas forcément d'avoir une vision globale d'un projet gigantesque. Et le cas bizarre que l'on ne sait pas prévoir tant qu'il ne nous est pas tombé sur le râble, c'est...

En fait, je dirais que la représentation de la situation est différente. Le déboggueur fait du pas à pas, permet de voir le bug en direct, là ou le printf donne une vision globale du problème....

Je programme en COBOL et en VBA. En VBA, j'utilise abondamment le debuggeur. En COBOL, je n'en ai pas, je mets des DISPLAY(équivalent du print) partout. Donc j'alterne entre les deux

Eh bien ça se...