17 créateurs de langages de programmation disent ne pas utiliser de débogueurs interactifs

Concernant le débat "clavier vs souris", il faudra toujours les deux. Un clavier permet de faire rapidement de multiples actions (grâce aux combinaisons) par contre pour ce qui est sélection et navigation ca sera toujours approximatif.
Cependant je plussoie tout de même la puissance des éditeurs textes faussement simples. J'ai pratiqué un peu Emacs à l'IUT et je dois dire que quand on connaît bien on fait des trucs sorti de l'espace, faut juste apprendre à avoir une bonne organisation des buffers.

A la défenses des IDE moderne, ils sont quasi capables de mes prouesses si on fait le même effort de configuration et d'apprentissage ou pour les plus feignants il existe très souvent des mode vi ou emacs.

---------------------

Pour le debugger sur des systèmes temps réels (ou pour les problèmes de synchro), c'est bel et bien possible. Il suffit pour cela d'arrêter tous les systèmes synchronisés et de faire le pas à pas en synchrone.
Je me sers souvent de cette technique quand je veux vérifier que j'ai bien codé mes synchronisations/locks/sémaphores/etc.

---------------------

Les tests automatiques (surtout unitaires) sur des batchs sont tout à fait possible, JCL ou pas. Ayant participé à l'intégration des données A380 dans les chaînes du calcul du Bureau d'Etude, je peux te dire que sans des tests automatiques ca aurait été impossible de faire la recette. Surtout grâce aux utilitaires fournis par IBM z/OS (lien).

Concernant la programmation (schedule) en test unitaire, on n'attend pas la nuit et on déclenche manuellement la chaîne : soit en invoquant le premier script de la chaîne en dev, soit en exprimant la demande au scheduler en recette.

Pour chaque batch, on génère les entrées, on exécute, on compare les fichiers générés avec des fichiers de référence. Ensuite on peut réitérer avec des morceaux plus grand et ainsi de suite.

8-)

Citation:

---

Envoyé par el_slapper

C'est l'éternel combat de l'abstraction contre la maitrise

---

Sais pas, suis de la vieille école, si on peut faire des choses "formidables" aujourd'hui, il ne faut pas pour autant perdre de vue que ce n'est qu'une construction d'opérations élémentaires. Les "vieux" comme moi sont toujours horrifiés de l'insouciance et du gaspillage des plus jeunes :mouarf:, c'est bien souvent le petit détail qui vient ébranler l'édifice.

Citation:

---

Envoyé par el_slapper

Euh, voyons, la compta d'une banque, c'est des centaines de JCL...

---

Condoléances :D j'avais bien précisé, pas toujours possible! Pour ma part je parlais d'interco type protocole trucmuch, web services, flux de données ... où on te fournit une spec, parfois béton, parfois torchon ... et pas toujours les moyens de test.

Citation:

---

Envoyé par el_slapper

Moi aussi...

---

Toujours le problème des environnements, toujours des surprises à prévoir en exploitation. J'ai eu le cas tordu de l'implémentation de prod qui divergeait de celles de tests, a une virgule près, mais qui t'imposait le rollback, on a d'ailleurs finit par monter des environnements de test connectables à la prod :D

Dans le monde du web, tu vas toujours tomber sur la "petite modif" qui va te planter un autre truc a l'autre bout de ton service que tu avais bien sûr sorti de ton scope de test, erreur une fois trouvée qui se termine par le grand classique du "mais c'est bien sûr!". Disons que si tu as semé quelques petits cailloux de ci de là, ça te permet de réagir plus vite.

Citation:

---

Envoyé par Nemek

Pour le debugger sur des systèmes temps réels (ou pour les problèmes de synchro), c'est bel et bien possible. Il suffit pour cela d'arrêter tous les systèmes synchronisés et de faire le pas à pas en synchrone.
Je me sers souvent de cette technique quand je veux vérifier que j'ai bien codé mes synchronisations/locks/sémaphores/etc.

---

Comme nimram31, je suis "de la vieille école", et je n'ai rien trouvé de mieux que des "fprintf ( stderr, ...)" :)

Citation:

---

Envoyé par rimram31

Toujours le problème des environnements, toujours des surprises à prévoir en exploitation. J'ai eu le cas tordu de l'implémentation de prod qui divergeait de celles de tests, a une virgule près, mais qui t'imposait le rollback, on a d'ailleurs finit par monter des environnements de test connectables à la prod

---

Moi j'ai eu le cas de 1 (oui, une seule) machine de prod sur laquelle le soft plantait.. Alors qu'il marchait sur toutes les machines de test et toutes les autres de prod...

Tout ça pour finir par s'apercevoir, au bout de ..... 1 mois !!!! ... de recherches approfondies, partout - en en particulier dans le code :aie: .. que un patch d'une bibliothèque DLL "de base" de l'OS n'avait pas été appliqué sur CETTE machine....

Après avoir passé un mois à commenter/décommenter des parties, voir quasiment tout le code, tout re-re-re-re-lire, etc etc etc... :arf:

Citation:

---

Envoyé par souviron34

Comme nimram31, je suis "de la vieille école", et je n'ai rien trouvé de mieux que des "fprintf ( stderr, ...)" :)

---

Moi aussi. Enfin ca s'appelle Showmessage(s : String); en Delphi mais bon...

Citation:

---

Envoyé par souviron34

Tout ça pour finir par s'apercevoir, au bout de ..... 1 mois !!!! ... de recherches approfondies, partout - en en particulier dans le code :aie: .. que un patch d'une bibliothèque DLL "de base" de l'OS n'avait pas été appliqué sur CETTE machine....

Après avoir passé un mois à commenter/décommenter des parties, voir quasiment tout le code, tout re-re-re-re-lire, etc etc etc... :arf:

---

Je crois que tu lèves ici un autre débat : les environnements de DEV/Pre-PROD/PROD.
On a beau faire tous les tests du monde, avoir toutes les usines de développement, tous les gestionnaires de versions et tous les protocoles de tests, si on fait pas les test sur des environnments iso-prod, ça sert pas à grand chose, si ce n'est de faire perdre du temps.
Tester un composant, ça veut dire tester CE composant, et pas tout le reste. Si les bases sur lesquels il s'appuie ne sont as les mêms, le resultat n'est pas concluant.

J'ai le souvenirs d'une utilisatrice qui m'accusait de faire un programme "aléatoire" (ça ça serait du pur génie) parce que les résultats de valos de portefeuilles n'étaient pas corrects. Pour s'apercevoir après 4 jours de tests-débuggage-recompil et autres pointages qu'elle avait modifié une des opérations du portefeuille de test...

Je pense aussi que si on respectait un peu plus les principes suivants on aurait moins de problèmes :

• modularité : une fonction (ou ojet ou n'importe quoi d'autre) fait UNE chose et UNE seule : ce pour quoi il a été conçu
• un module a en charge de s'assurer que ce qu'il produit est BON et COHERENT avec les entrées et le cahier des charges
• un module informe de son résultat
• Le concepteur du module doit savoir qui utilise son module (ca s'appelle l'impact) et avertir lesdits utilisateurs de tout changement pouvant modifier les données en sortie
• Le concepteur du module doit connaitre ses entrées, et connaitres les impacts des changemetns en amont (cf ci-dessus).

Il me semble qu'avec les POO et autres développements AGILE (entre autres) on a oublié les base de la programmation, du moins celles qui facilitent la vie.

Citation:

---

Envoyé par souviron34

Comme nimram31, je suis "de la vieille école", et je n'ai rien trouvé de mieux que des "fprintf ( stderr, ...)" :)

---

J'utilise pas mal aussi enfin de manière tout de même un peu plus évolué avec un système de log qui permet pas mal de chose comme dispatcher les messages sur plusieurs fichiers ou d'ajouter des messages de contexte récupérables plus loin dans la pile.

Cependant le débugueur permet aussi de jouer les commandes dans l'ordre que l'on souhaite. Par exemple des locks, comment vérifier que ce n'est pas l'ordonnanceur plutôt que le lock qui empêche l'exécution entrelacée de deux séquences ?

Citation:

---

Envoyé par souviron34

Moi j'ai eu le cas de 1 (oui, une seule) machine de prod sur laquelle le soft plantait.. Alors qu'il marchait sur toutes les machines de test et toutes les autres de prod...

Tout ça pour finir par s'apercevoir, au bout de ..... 1 mois !!!! ... de recherches approfondies, partout - en en particulier dans le code :aie: .. que un patch d'une bibliothèque DLL "de base" de l'OS n'avait pas été appliqué sur CETTE machine....

Après avoir passé un mois à commenter/décommenter des parties, voir quasiment tout le code, tout re-re-re-re-lire, etc etc etc... :arf:

---

Je compatis :calim2: Dans un projet web, on avait une personne de la recette chez qui ca ne fonctionnait pas. Des mois à chercher le problème avec CETTE personne. Au final, elle utilisait un build introuvable de IE6.

Citation:

---

Envoyé par arkhamon

Je crois que tu lèves ici un autre débat : les environnements de DEV/Pre-PROD/PROD.
On a beau faire tous les tests du monde, avoir toutes les usines de développement, tous les gestionnaires de versions et tous les protocoles de tests, si on fait pas les test sur des environnments iso-prod, ça sert pas à grand chose, si ce n'est de faire perdre du temps.
Tester un composant, ça veut dire tester CE composant, et pas tout le reste. Si les bases sur lesquels il s'appuie ne sont as les mêms, le resultat n'est pas concluant.

---

Je dirais même "pas concluable", un peu comme le YES/NO/NULL de SQL. Cependant ce n'est pas toujours facile, que ce soit les données ou bien l'architecture (DMZ, machine propriétaire, VPN).

Citation:

---

Envoyé par arkhamon

Je pense aussi que si on respectait un peu plus les principes suivants on aurait moins de problèmes :

1. modularité : une fonction (ou ojet ou n'importe quoi d'autre) fait UNE chose et UNE seule : ce pour quoi il a été conçu
2. un module a en charge de s'assurer que ce qu'il produit est BON et COHERENT avec les entrées et le cahier des charges
3. un module informe de son résultat
4. Le concepteur du module doit savoir qui utilise son module (ca s'appelle l'impact) et avertir lesdits utilisateurs de tout changement pouvant modifier les données en sortie
5. Le concepteur du module doit connaitre ses entrées, et connaitres les impacts des changemetns en amont (cf ci-dessus).

---

Un jour j'ai fait un rêve, celui ou les deux derniers points étaient respectés. Car pour les premiers points ca reste facile, ca reste interne à l'équipe. Mais pour le reste tes dépendants des autres et impossible de deviner ce qui se passe à côté si on te le dit pas !

Citation:

---

Envoyé par Nemek

(.../...) Les tests automatiques (surtout unitaires) sur des batchs sont tout à fait possible, JCL ou pas. Ayant participé à l'intégration des données A380 dans les chaînes du calcul du Bureau d'Etude, je peux te dire que sans des tests automatiques ca aurait été impossible de faire la recette. Surtout grâce aux utilitaires fournis par IBM z/OS (lien).

---

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 limite de l'impossible.

Citation:

---

Envoyé par Nemek

Concernant la programmation (schedule) en test unitaire, on n'attend pas la nuit et on déclenche manuellement la chaîne : soit en invoquant le premier script de la chaîne en dev, soit en exprimant la demande au scheduler en recette.

---

Non. Je ne vais pas mettre 500 applis dans le zag parceque je fais tourner la compta pour mon usage personnel. On ne fait pas le même métier, manifestement(et je ne foute pas que le tien est difficille aussi).

Citation:

---

Envoyé par Nemek

Pour chaque batch, on génère les entrées, on exécute, on compare les fichiers générés avec des fichiers de référence. Ensuite on peut réitérer avec des morceaux plus grand et ainsi de suite.

---

Ben oui, mais c'est pas le batch que je dois tester.

Je sais tester un batch, merci. Avec ceci de tuant que généralement, les référentiels dont je dépend sont souvent variables, que je n'ai pas la main dessus, et que je dois faire un test "adaptatif", qui regénère sa propre référence en fonction de ce que le référentiel est devenu.

Mais quand la transaction dépend d'un batch(en fait de plusieurs centaines), que ce batch dépend d'autres transactions, qui eux mêmes dépendent d'autres batches, et que tout ceci représente le travail de milliers de personnes qui toutes vérifient leurs trucs en même temps sur le même environnement, euh, comment dire, tes automatismes, on les oublie.

Citation:

---

Envoyé par souviron34

Tout ça pour finir par s'apercevoir .. que un patch d'une bibliothèque DLL "de base" de l'OS n'avait pas été appliqué...

---

Pour moi c'était pire que ça, sciemment le client avait fait développer ses outils de tests par un fournisseur, ceux de prod par un autre, je te le donne Emile ... Au final, j'ai compris l'intérêt des tests d'interopérabilité ;) et sait depuis relativiser, tout en les exigeant, les standards.

Citation:

---

Envoyé par Nemek

Un jour j'ai fait un rêve, celui ou les deux derniers points étaient respectés. Car pour les premiers points ca reste facile, ca reste interne à l'équipe. Mais pour le reste tes dépendants des autres et impossible de deviner ce qui se passe à côté si on te le dit pas !

---

Sans me mettre hors sujet pour déborder sur un autre débat, c'est tout le problème de l'abstraction, elle pose un vrai problème de maîtrise de la complexité et, désolé, nous ne sommes que des hommes. On a beau se la raconter, le fait est que notre cerveau a ses limites.

Citation:

---

Envoyé par el_slapper

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 limite de l'impossible.

---

Dans cette expression je vois deux choses : la transaction et le batch. Je peux tester unitairement les deux, ou bien les tester ensemble.
Si tu me dis que c'est gênant de bloquer l'environnement de recette pour recetter la transaction "complète", alors je comprends ton désarroi. Ceci dit un tel comportement pourrait expliquer le genre de problème que je peux rencontrer.

Citation:

---

Envoyé par el_slapper

Non. Je ne vais pas mettre 500 applis dans le zag parceque je fais tourner la compta pour mon usage personnel. On ne fait pas le même métier, manifestement(et je ne foute pas que le tien est difficille aussi).

---

Tu ferais juste tourner la chaîne "compta" pour la recette de la "compta" ... Voir remarque ci-dessus.
Sinon j'ai changé d'activité depuis, fini MVS et le BE, maintenant je suis à l'autre bout de la chaîne (J2EE et "Service client") et maintenant je dois faire avec les données de merde qu'on m'envoie en amont :aie:

Citation:

---

Envoyé par el_slapper

Mais quand la transaction dépend d'un batch(en fait de plusieurs centaines), que ce batch dépend d'autres transactions, qui eux mêmes dépendent d'autres batches, et que tout ceci représente le travail de milliers de personnes qui toutes vérifient leurs trucs en même temps sur le même environnement, euh, comment dire, tes automatismes, on les oublie.

---

On ne doit pas parler de la même chose ^^ Unitairement, tu te génères tes entrées soit des fichiers, soit des mocks, etc.
Pour ce qui est des chaînes (à plus ou moins grande échelle), elles sont sous la responsabilité de quelqu'un qui doit recetter cette partie du système (et uniquement celle-ci). Ce type débranche ce qui dépasse et testes. Ou sinon c'est du test grandeur nature ^^

Citation:

---

Envoyé par Nemek

Dans cette expression je vois deux choses : la transaction et le batch. Je peux tester unitairement les deux, ou bien les tester ensemble.
Si tu me dis que c'est gênant de bloquer l'environnement de recette pour recetter la transaction "complète", alors je comprends ton désarroi. Ceci dit un tel comportement pourrait expliquer le genre de problème que je peux rencontrer.

---

JE ne vois pas en quoi ca pose problème : si deux composants sont à tester, alors on teste chacun séparément, sinon comment savoir ce qui fait masse ! De plus, si on teste que la partie transactionnelle remplit bien sa tache ensuite on peut tester les batches (qui en général traitent les saisies en transactionnel) et tout roule. Encore une fois, un module une fonction, des entrées et des sorties clairement définies... Et plus, des bases de test et des bases répliquées ça existe...

Citation:

---

Envoyé par Nemek

On ne doit pas parler de la même chose ^^ Unitairement, tu te génères tes entrées soit des fichiers, soit des mocks, etc.
Pour ce qui est des chaînes (à plus ou moins grande échelle), elles sont sous la responsabilité de quelqu'un qui doit recetter cette partie du système (et uniquement celle-ci). Ce type débranche ce qui dépasse et testes. Ou sinon c'est du test grandeur nature ^^

---

Oui c'est marrant le grandeur nature... Toujours dans le même registre, chacun est responsable de sa m.... A chacun de s'assurer qu'elle est correcte avant de la balancer dehors.

Règle d'or d'un module : Un module ne doit JAMAIS devoir vérifier la validité des données qu'il reçoit, cela impliquerait qu'il embarque une partie de "l'intelligence" du module précédent, ce qui serait une hérésie... PAr contre, il doit repecter une autre règle d'or : respecter les regles de calcul !
Je m'explique (sur le premier point, le second est assez trivial pour tout le monde) :

un batch traite des écritures comptables et les ventile sur des comptes. Il n' pas à vérifier qu'un numéro de compte existe ou pas, ça n'est pas son rôle. Et si il le fait, ça veut dire que le jour ou on veut modifier le plan comptable, il faut AUSSI modifier ce petit module, ce qui est une perte de temps. On doit uniquement vérifier le référentiel. Donc mon module DOIT considérer que le numero de compte fourni existe bel et bien. En fait, dans l'absolu, un module doit toujours considérer que ce qu'il reçoit est bon (nature et structure des données) tout en étant capable bien sur de traiter un code retour du précédent...

Sinon on se retrouve avec des modules qui font tout et n'impore quoi, et là effectivement les analyses d'impact, bonjour ! Sans aprler des 50 vérifications successives d'une info, c'est pas comme si ça prenait du temps...

Plutôt pas d'accord ! Un module doit faire un minimum de contrôle afin de s'assurer que le process ne va pas partir dans les choux.
Après ca dépend également des contraintes de robustesse. Si tu as une donnée invalide, tu peux rejeter uniquement la donnée (ie un champ), l'entrée complète (ie un enregistrement), les enfants, les parents ou tout l'entrée.

Ensuite à voir ce que tu mets dans les logs ou les messages d'erreur que tu renvoies. Plus c'est précis et moins on aura besoin de redescendre dans les niveaux de support ou bien ce sont les responsables d'exploitation qui te remercieront.

Citation:

---

Envoyé par Nemek

Dans cette expression je vois deux choses : la transaction et le batch. Je peux tester unitairement les deux, ou bien les tester ensemble.
Si tu me dis que c'est gênant de bloquer l'environnement de recette pour recetter la transaction "complète", alors je comprends ton désarroi. Ceci dit un tel comportement pourrait expliquer le genre de problème que je peux rencontrer.

---

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

Citation:

---

Envoyé par Nemek

Tu ferais juste tourner la chaîne "compta" pour la recette de la "compta" ... Voir remarque ci-dessus.

---

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

Citation:

---

Envoyé par Nemek

Sinon j'ai changé d'activité depuis, fini MVS et le BE, maintenant je suis à l'autre bout de la chaîne (J2EE et "Service client") et maintenant je dois faire avec les données de merde qu'on m'envoie en amont :aie:

---

Je suis pas mal en aval aussi, même sous MVS. Je connais ton problème. Etre en amont, je l'ai été, ça n'est pas évident non plus.

Citation:

---

Envoyé par Nemek

On ne doit pas parler de la même chose ^^ Unitairement, tu te génères tes entrées soit des fichiers, soit des mocks, etc.
Pour ce qui est des chaînes (à plus ou moins grande échelle), elles sont sous la responsabilité de quelqu'un qui doit recetter cette partie du système (et uniquement celle-ci). Ce type débranche ce qui dépasse et testes. Ou sinon c'est du test grandeur nature ^^

---

Je reprends mon exemple. Nous avons une transaction de saisie sur compte du client pour le compte de l'état.
(1)L'opérateur, via la transaction JAVA, saisit la saisie(jeu de mot volontaire). Le système emet, immédiatement, un fluc comptable.
(2)La nuit, le batch comptable créée le compte qui va bien, fait les mouvements, et met à disposition de la transaction un fichier qui liste les comptes qu'il a créé.
(3)Au petit matin, un batch lié à la transaction met à jour la base avec les comptes créés.
(4)Dans la journée(ou un autre jour), l'opérateur se connecte, et vérifie via la transaction qu'il a bien sous la main un compte créé par le batch comptable. Il peut alors déboucler l'opération.

Tu peux tester automatiquement chaque point. Le point 2 par la compta, les autres par la saisie. Mais faire un cas de test complet de l'application saisie, qui commence par la saisie de la saisie, en passant par le débouclage, ça nécéssite un automatisme asynchrone. J'ai comme qui dirait un doute.

Citation:

---

Envoyé par Nemek

Plutôt pas d'accord ! Un module doit faire un minimum de contrôle afin de s'assurer que le process ne va pas partir dans les choux.
Après ca dépend également des contraintes de robustesse. Si tu as une donnée invalide, tu peux rejeter uniquement la donnée (ie un champ), l'entrée complète (ie un enregistrement), les enfants, les parents ou tout l'entrée.

Ensuite à voir ce que tu mets dans les logs ou les messages d'erreur que tu renvoies. Plus c'est précis et moins on aura besoin de redescendre dans les niveaux de support ou bien ce sont les responsables d'exploitation qui te remercieront.

---

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 à refuser le fichier complet si il a une seule erreur, mais il peut arriver que d'autres options soient sur la table, je ne suis pas doctrinaire.

Faire confiance, euh, ça m'a valu 3 jours de cauchemar par mois pendant deux ans. En fait, d'autres on décidé pour moi que les entrées seraient fiables, et qu'on ne me donnerait pas les 5 jours qu'il fallait pour fiabiliser les entrées.

Donc non, quand j'ai le choix, je ne fais pas confiance aux applis en amont. Des milliards de trucs peuvent déconner. Il y a une dizaine d'années, une grande banque française a créé un nouveau type de carte de retrait privative(du bas de gamme). Le chef de projet, tout fier, est allé retirer 20 roros avec sa carte prototype. Il avait juste oublié de prévenir la compta. Pendant la nuit, 11 alertes ont sonné. 11 applis, comptas ou proches, ne faisaient pas confiance aux applis en amont, et avaient bien raison. Ils ont évidemment corrigé tout ça assez vite, et le lendemain soir, le compte du chef de projet a été débité de 20 roros.

L'insistance que tu fais sur les logs est importante aussi. Des années de maintenance m'ont appris l'importance de logs complètes. Spécialement des compteurs précis. Si tous les mois on a "200 entrées, 199 sorties", et qu'un mois on a "200 entrées, 21 sorties", on va avoir un doute.
Si tous les mois on a "200 entrées, 199 sorties, 21 sorties marketing, 178 sorties restitutions", et qu'on se retrouve avec "200 entrées, 199 sorties, 21 sorties marketing, 0 sorties restitutions" alors on sait déjà qu'on a perdu les restitutions.

Et si en plus on a un message "178 entrées restitutions rejetées pour code agence non numérique", eh bien on sait déjà exactement quelle est la donnée qui a été pourrie, il ne reste plus qu'à corriger les données et à relancer.

Citation:

---

Envoyé par arkhamon

Règle d'or d'un module : Un module ne doit JAMAIS devoir vérifier la validité des données qu'il reçoit, cela impliquerait qu'il embarque une partie de "l'intelligence" du module précédent, ce qui serait une hérésie... PAr contre, il doit repecter une autre règle d'or : respecter les regles de calcul !
Je m'explique (sur le premier point, le second est assez trivial pour tout le monde) :

un batch traite des écritures comptables et les ventile sur des comptes. Il n' pas à vérifier qu'un numéro de compte existe ou pas, ça n'est pas son rôle. Et si il le fait, ça veut dire que le jour ou on veut modifier le plan comptable, il faut AUSSI modifier ce petit module, ce qui est une perte de temps. On doit uniquement vérifier le référentiel. Donc mon module DOIT considérer que le numero de compte fourni existe bel et bien. En fait, dans l'absolu, un module doit toujours considérer que ce qu'il reçoit est bon (nature et structure des données) tout en étant capable bien sur de traiter un code retour du précédent...

---

Citation:

---

Envoyé par Nemek

Après ca dépend également des contraintes de robustesse. Si tu as une donnée invalide, tu peux rejeter uniquement la donnée (ie un champ), l'entrée complète (ie un enregistrement), les enfants, les parents ou tout l'entrée.

---

Vos exemples sont de la banque..

Un exemple contraire à ce que vous dites, dans un grand SIG temps réel critique :

d'une part les modules et les fonctionalités s'interpénètrent (par exemple j'ai une boucle d'affichage temps réel, qui avance en foncgion du temps, mais des données entrent au fur et à mesure, et certaines modifient des données déjà existantes, ou bien les statistiques sont faites par exemple toutes les 10 minutes et l'utllisaeur modifie en cours de boucle pour dire toutes les 15 minutes, et puis en plus il veut sauvegarder ce qu'il a l'écran en mpeg,et reprendre là où il en était)

d'autre part, par exemple je veux les données invalides, mais je ne dois pas m'en servir pour des calculs... Et cette donnée invalide peut être invalide pour quelques mois... et réémise toutes les heures.. Mais ces données invalides peuvent être invalides de sens par rapport aux vosiines) ou de valeurs (température au sol > 1000 degrés par exemple)...


Enfin, je n'ai pas droit au crash : 24/24, 7/7..


Bref, tout ceci pour dire que même dans le bancaire, ça apparait difficile, mais c'est quasi impossible à faire dans beaucoup d'environnements industriels réels..

D'où d'ailleurs les échecs / retards et erreurs autant qu'avant des méthodologies diverses et variées, nouvelles ou non... Les modélisations et "découpages" de responsabilité sont des vraies constructons théoriques, mais il est peu fréquent, selon mon expérience, d'en avoir des exemples vraiment indépendants...

La plupart du temps les reponsabilités sont "relativement" circonscrites, mais cependant un peu dispersées par la force des choses

Je n'aime pas l'utilisation de termes absolus comme les utilise arkamon.. (les règles d'or et autres...)

Autant que faire se peut est à mon avis une ligne directrice nécessaire et suffisante...

Citation:

---

Envoyé par souviron34

Je n'aime pas l'utilisation de termes absolus comme les utilise arkamon.. (les règles d'or et autres...)

Autant que faire se peut est à mon avis une ligne directrice nécessaire et suffisante...

---

Arkhamon y a un "H". Je sais il se prononce pas, il rompt la sérénité, mais il est là... :ccool:

Pour les règles, je pense justement qu'à force de s'en affranchir, on en arrive à des situations ubuesques : des personnes n'ayant aucune vraie formation qui font de l'informatique en en ignorant les règles qui ont été baties par des pros... J'avais longuement débattu de ce point dans un autre sujet et je maintiens et persiste dans mon conception de l'informatique : un beau métier qui demande des règles come dans tout autre métier. Une poutre ca se fabrique dans les règles un mur ça se monte suivant les règles ou ca se casse la gueule, pourquoi toujours considérer qu'en informatique on peut faire n'importe quoi ? Etonnant ça...


Pour ma conception des modules, je n'ai visiblement pas été assez clair. Ce que je voulais dire c'est qu'un module est conçu pour une chose, et qu'il ne devrait pas faire autre chose. Et qu'il ne peut pas passer son temps à revérifier le travail des autres. Le maçon doit pouvoir considérer que la dalle est correcte pour monter son mur, il ne va pas cresuer autour pour voir si elle a la bonne épaisseur. Le constructeur d'une pile de pont ne va pas revérifier les analyse géologiques du terrain pour deux raisons : la première c'est qu'il est pas là pour ça, la seconde est que si il était capable de le faire correctement (i.e. en ayant toutes les infos et toutes les compétences), ben il serait ingénieur géologue et pas constructeur de piles de pont. Vous voyez ou je veux en venir ?
Votre module, s'il doit vérifier ses entrées, ne peut le faire que s'il a toutes les infos et tous les algo pour le faire. Dans ce cas, il a de quoi faire le boulot du module précédent. Donc il y a duplication et donc perte (d'argent, de temps machine, d'accès BDD...). Et si un jour l'algo en question doit évoluer, c'est deux modules et non un seul qui doit être modifié. Et en reproduisant ce paradigme (j'adore ce mot), on se retrouve effectivement avec une analyse d'impact quasiment impossible à faire.

Je reste intimement convaincu que si chacun s'assure que ce qu'il produit est correct en amon, l'aval a moins de soucis. Toyota a découvert ça il y a 30 ans et ce concept, lui, a survécu à toutes les modes de le production...

Il n'en reste pas moins qu'un module peut très bien (et devrait) s'étonner dans une log (là pour le coup les logs c'est capital) que d'habitude il reçoive un fichier de 200 lignes et que d'un coup il n'en reçoit que 30. Mais à mon avis il ne devrait pas être responsable de vérifier ses entrées.

C'est plus clair et moins "brouillon" ?

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), c'est sans doute applicable quasiment sans se poser de questions.

Mais nous avons des domaines fonctionnels dont les exigences varient grandement, Souviron34 l'a justement remarqué. Lui bosse dans le médical, moi dans le bancaire. Et ça a des conséquences importantes sur la manière de penser.

En bancaire, ce qui me parait frappant, c'est la quantité de règle appliquée absolument à tous les niveaux. Peu sont compliquées, mais l'ensemble est d'une complexité assez inmaitrisable. De plus les budgets sont pas mal limités par application(en raison du nombre gigantesque d'applications). Par exemple, nous sommes deux et demi à maintenir, faire évoluer, voire rajouter de nouveaux traitements, sur un domaine applicatif qui couvre 30 applications, plus de 1000 JCL(scripts), plus de 2000 programmes/modules(moyenne : 1500 lignes chaque). Lundi matin, j'ai rajouté 400 lignes en catastrophe : les 3 coordinateurs de la bascule n'avaient pas su anticiper qu'il faudrait, sur un fichier bien précis, basculer une dizaine de comptes(en plus des 350 000 enregistrements de niveau agence).

Dans une volumétrie pareille, il est carrément impossible de faire confiance, ne serait-ce qu'à nos propres composants, pris unitairement. Des tests unitaires aideraient beaucoup, mais ne suffiraient pas. Faire confiance à une appli externe, celà sous-entendrait que l'intégralité des interactions possibles entre leur monstre et le nôtre aient été anticipées. Sachant que chacun d'entre nous a la responsabilité de plus d'un million de lignes de code.

Donc oui, nous avons beaucoup de verrues. Nous ne sommes pas sensés recevoir des montants mal formatés, mais nous les contrôlons quand même, parceque des fois ça arrive. Suivant les cas, nous plantons, rejetons, ou transformons en zéro. C'est simplement inévitable. Nous avons trop de choses à faire pour nous permettre de prévoir tous les cas. Ca ne rentrerait pas dans nos misérables cerveaux de simples mortels.

La programmation par contrat, ça veut dire que le module en amont, celui qui nous envoie ses données, a pensé absolument à tout. C'est possible(voire parfois indispensable) dans certains cas(je pense en particulier à l'embarqué). Pas dans le mien. Notre chaine de restitution reçoit des flux de 130 applis en amont, qui toutes ont leur propre rythme de maintenance et d'évolutions. Qui, pour la plupart, découvrent que nous existons quand ils nous font planter. Qui, pour la plupart, sont en sous-effectifs. Une solution théoriquement propre serait magnifique, mais nécéssiterait des moyens hors de proportion. Même pour une banque.

La programmation par contrat, ça veut dire aussi qu'on impose aux gens du métier d'autres sources que des applis à leur main qui ne font pas de contrôles. Pas d'Unica ou ils font mumuse pour optimiser leurs flux sans être emmerdés par les développeurs. Ce pour quoi le budget n'est généralement pas disponible. Unica leur donne un contrôle bien plus grand sur leurs actions de contrôle ou de marketing, mais c'est à moi, en aval, de gérer leurs, euh, déchets. L'ancien outil qu'ils avaient à disposition, pourtant taillé sur mesure, ne générait pas de déchets, mais ne leur permettait pas de faire ce dont ils avaient besoin.

Je n'ai pas la prétention de délivrer des best practices en médical ou en compilateurs. Ma connaissance de ses domaines est purement théorique. Mais les conclusions qu'on peut tirer de ces domaines ne sont pas forcément appliquables à d'autres domaines.

Citation:

---

Envoyé par arkhamon

Le constructeur d'une pile de pont ne va pas revérifier les analyse géologiques du terrain pour deux raisons [...]

---

Il ne refera pas les analyses mais il s'assurera que le rapport qu'il a entre les mains correspond bien à l'endroit de la pile, qu'il a été validé par le responsable du projet,...

Citation:

---

Envoyé par el_slapper

Souviron34 l'a justement remarqué. Lui bosse dans le médical, moi dans le bancaire. Et ça a des conséquences importantes sur la manière de penser.

---

Médical, météo, trains, aviation et simulateurs :)

Disons que ce que m'ont appris 27 ans dans ces métiers c'est que les "règles d'or" sont, comme toutes les normes en informatique, des absurdités si c'est pris au pied de la lettre... *

Ces normes ou règles doivent être des guides, pas des absolus...

Il y a trop de cas divers et variés pour que les analyses ou séparations ou vérifications ou domaines de compétences ou "contrats" ou ce qu'on veut soient complets et sûrs dans 100% des cas de la vraie vie...

C'est tout :D

C'est pour ça que je suis totalement contre tout absolutisme, que ce soit dans les règles, les méthodologies, les "patterns", les features de programmation, les tests, etc etc etc...

Ce qui est valable dans un certain cadre ne l'est pas dans un autre, à moins de faire une super-pyramide de trucs complexes.. Des cas "aberrants" peuvent apparaître, des moyens de "bypasser" le système peuvent être désirés, etc etc..

Tous pour de bonnes raisons...

(rappelez-vous le pilote qui a posé l'avion sur l'Hudson il y a.. 2 ans ??? Si il n'avait pas pu débrancher le pilote automatique, il se crashait avec tous ses passagers... Dans le médical, les urgences pré-emptent toute sécurité, et toute loi...en météo, comme je l'ai dit, des stations peuvent émettre temporairement (pendant 3 à 5 mois, ou 3 jours) des données "valides" au sens de valeurs et "invalides" en termes de sens (nivomètre gelé, bateau en bas d'une capitainerie et abrité du vent en hiver... et les exemples sont infinis..)

Or un soft ne devrait NI CRASHER NI SORTIR, JAMAIS....

Cette obligation détruit tout absolutisme....



* Note : comme par exemple les "règles d'or" sur : une fonction ne doit pas faire plus que tant de lignes, une fonction ne doit contenir que un if ou une boucle.... J'ai très rarement vu le cas où appliquer ceci strictement n'entrainait pas un tel surplus de complexité, que ce soit en arborescence de fonctionalité, de maintenance, ou de fichiers, que ça en valait la peine....

Au risque de me faire plein d'amis...

Citation:

---

Envoyé par souviron34

Ces normes ou règles doivent être des guides, pas des absolus...

---

Ca y est : quelles qu'elles aient pu être, si on considère qu'elles ne sont dès le départ de que "vagues règles, plutôt un concept à vaguement regarder", on est foutu. "Dura Lex, sed Lex". Sans lois, tout part en vrille.

Citation:

---

Envoyé par souviron34

C'est tout :D

---

Ben tiens...

Citation:

---

Envoyé par souviron34

C'est pour ça que je suis totalement contre tout absolutisme, que ce soit dans les règles, les méthodologies, les "patterns", les features de programmation, les tests, etc etc etc...

---

Je ne parle pas de jusqu'au boutisme (je suis pas sur de l'hauteaugraffe) je parle jsute de travailler avec des normes. Ensuite dans certains cas, la logique, les conditions et tout une palanquée de paramètres peuvent éventuellement faire évoluer les choses. Qui plus est, je ne parle pas de l'obligation de patterns ou autres, je dis simplement quà force d'oubleir des bases qui sont claires et logiques, on pond des usines à gaz incontrolables...

Citation:

---

Envoyé par souviron34

(rappelez-vous le pilote qui a posé l'avion sur l'Hudson il y a.. 2 ans ??? Si il n'avait pas pu débrancher le pilote automatique, il se crashait avec tous ses passagers...

---

En même temps, si le règlement des pilotes (vous avez remarqué le mot règlement ?) ne permettait pas à un pilote de débrancher le pilote auto, à quoi sert l'humain ? :aie:

Citation:

---

Envoyé par souviron34

Dans le médical, les urgences pré-emptent toute sécurité, et toute loi...

---

Merci. Grâce à toi, on connaît maintenant les vrais coupables des crises du sang contaminé, de l'amiante, du plomb... Va expliquer ta théorie aux familles des vicimes...

Citation:

---

Envoyé par souviron34

en météo, comme je l'ai dit, des stations peuvent émettre temporairement (pendant 3 à 5 mois, ou 3 jours) des données "valides" au sens de valeurs et "invalides" en termes de sens (nivomètre gelé, bateau en bas d'une capitainerie et abrité du vent en hiver... et les exemples sont infinis..

---

En même temps (jeu de mot), si personne ne s'assure que le niveaumêtre est pas gelé, on risque pas de s'en sortir... Un peu comme si personne ne s'inquiétait que les saisies sont faites pour que les traitements de nuit se déroulent bien...

Citation:

---

Envoyé par souviron34

Or un soft ne devrait NI CRASHER NI SORTIR, JAMAIS....

---

Ouais la décemment je ne peux pas te donner tord. Tu l'as fait exprès non ? :ccool: Et pour abonder dans ton sens, il doit toujours être capable de maîtriser son exécution (le try-exept que j'utilise si peu dans mes softs à moi... :aie:)

Citation:

---

Envoyé par souviron34

* Note : comme par exemple les "règles d'or" sur : une fonction ne doit pas faire plus que tant de lignes, une fonction ne doit contenir que un if ou une boucle.... J'ai très rarement vu le cas où appliquer ceci strictement n'entrainait pas un tel surplus de complexité, que ce soit en arborescence de fonctionalité, de maintenance, ou de fichiers, que ça en valait la peine....

---

JE ne suis pas d'accord non plus avec ces choses. Encore qu'une fonction qui ferait 200 ilgnes ne pourrait-elle être scindée en plusieurs ? Sous-jacent : cette fonction de 200 lignes ne fait-elle qu'une seule chose ?

Citation:

---

Envoyé par souviron34

(.../...)
Or un soft ne devrait NI CRASHER NI SORTIR, JAMAIS....

---

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 repartir. Mais c'est parceque dans notre cas, le résultat prime sur la réactivité. La compta DOIT être juste. Tant pis si elle prend du retard et que les utilisateurs s'excitent en attendant. Evidemment, un pilote qui essaye de se poser aura une approche différente.....

Citation:

---

Envoyé par arkhamon

Ca y est : quelles qu'elles aient pu être, si on considère qu'elles ne sont dès le départ de que "vagues règles, plutôt un concept à vaguement regarder", on est foutu. "Dura Lex, sed Lex". Sans lois, tout part en vrille.

---

Tout simplement parceque notre domaine de métier est bien trop vaste pour qu'une règle pensée pour tel cas corresponde à tous les métiers. Mon approche du métier est radicalement différente de celle de Souviron34, mais c'est parceque nos applications sont radicalement différentes aussi.

Citation:

---

Envoyé par arkhamon

Je ne parle pas de jusqu'au boutisme (je suis pas sur de l'hauteaugraffe) je parle jsute de travailler avec des normes. Ensuite dans certains cas, la logique, les conditions et tout une palanquée de paramètres peuvent éventuellement faire évoluer les choses. Qui plus est, je ne parle pas de l'obligation de patterns ou autres, je dis simplement quà force d'oubleir des bases qui sont claires et logiques, on pond des usines à gaz incontrolables...

---

Mais on trouve toujours des cas limites ou les normes deviennent contre-productives.

Citation:

---

Envoyé par arkhamon

En même temps (jeu de mot), si personne ne s'assure que le niveaumêtre est pas gelé, on risque pas de s'en sortir... Un peu comme si personne ne s'inquiétait que les saisies sont faites pour que les traitements de nuit se déroulent bien...

---

Ah, mais un traitement qui "passe quand même" peut parfaitement lever des alarmes. Sur un de mes rares traitements "qui ne doit pas planter", en cas de bizarrerie, l'auteur du fichier reçoit un mail du genre "votre fichier 0X2Z a été rejeté parceque la typologie n'est pas renseignée", et le traitement continue. L'utilisateur peut regénérer son fichier, il sera collecté par une autre quotidienne. Si il n'a plus d'erreurs.

J'ose imaginer que quand un pluviomètre envoie des données aberrantes(15 mètres de pluie par heure), une alerte est levée. Sa gestion est une affaire de management, pas de programmation(référence aux alertes levées sur les actions de Kerviel et qui n'ont pas été traitées : c'est un problème de management, pas de programmation).

Citation:

---

Envoyé par arkhamon

JE ne suis pas d'accord non plus avec ces choses. Encore qu'une fonction qui ferait 200 lignes ne pourrait-elle être scindée en plusieurs ? Sous-jacent : cette fonction de 200 lignes ne fait-elle qu'une seule chose ?

---

La plupart du temps, oui, on peut scinder. Mais, encore une fois, on peut trouver des cas limite ou la compréhension est simplifiée si on fait un paragraphe un peu plus long. Exemple vécu : vaut il mieux faire :

Code:

---

1 2 3 4 5 6 7

Sub TraitementTableau() For Ligne = 1 to MaxLignes For Colonne = 1 to MaxColonnes (24 lignes de traitement) Next Colonne Next Ligne End Sub

---

ou

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Sub TraitementTableau() For Ligne = 1 to MaxLignes Call TraitementLigne(Ligne) Next Ligne End Sub Sub TraitementLigne(Ligne as Integer) For Colonne = 1 to MaxColonnes Call TraitementCellule(Ligne, Colonne) Next Colonne End Sub Sub TraitementCellule(Ligne,Colonne) (24 lignes de traitement) End Sub

---

Perso, je préfère la première version, sachant que le traitement est spécifique, et non réutilisé ailleurs. Pour du réutilisable on peut modulariser, mais pour du spécifique, franchement, avoir la boucle, ça permet d'avoir l'ensemble de la cinématique sous les yeux. 28 lignes au lieu de 24, ça n'est pas la mort.

Citation:

---

Envoyé par el_slapper

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 repartir. Mais c'est parceque dans notre cas, le résultat prime sur la réactivité. La compta DOIT être juste. Tant pis si elle prend du retard et que les utilisateurs s'excitent en attendant. Evidemment, un pilote qui essaye de se poser aura une approche différente.....

---

Oui il a pas intérêt à rater son approche... :aie: bon sérieusement, oui tu as raison, dans certains cas il faut de la réactivité, dans d'autres il faut de l'exactitude. La compta c'est plutôt l'exactitude... Mais à mon avis ça n'enlève rien aux régles...

Citation:

---

Envoyé par el_slapper

Tout simplement parceque notre domaine de métier est bien trop vaste pour qu'une règle pensée pour tel cas corresponde à tous les métiers. Mon approche du métier est radicalement différente de celle de Souviron34, mais c'est parceque nos applications sont radicalement différentes aussi.

---

Là aussi tu as raison. Le problème est que tout le monde se cache derrière cette approche pour carrément supprimer toutes les règles. C'est là ou je pense qu'il faut revenir aux bases. Parce que Java offre un garbage collector, il est devenu impossible de libérer soi même une ressource. Or cela va contre cette "règle" qui dit qu'on doit gérer ses ressources. Le laisser faire par d'autres est dangereux (cf fuites mémoires...).

Citation:

---

Envoyé par el_slapper

Ah, mais un traitement qui "passe quand même" peut parfaitement lever des alarmes. Sur un de mes rares traitements "qui ne doit pas planter", en cas de bizarrerie, l'auteur du fichier reçoit un mail du genre "votre fichier 0X2Z a été rejeté parceque la typologie n'est pas renseignée", et le traitement continue. L'utilisateur peut regénérer son fichier, il sera collecté par une autre quotidienne. Si il n'a plus d'erreurs.

---

D'accord, sauf que le jour où les règles de typologie vont changer, il faudra AUSSI modifier ton code. Donc double travail : celui du module qui pond les fichiers d'entrée et ton module qui les vérifie. Double travail, double coût, double risque de mauvaise compréhension, double risque de bug (nous ne sommes qu'humains), doubles analyses d'impacts etc... Tu vois mon principe de raisonnement ?

Citation:

---

Envoyé par el_slapper

J'ose imaginer que quand un pluviomètre envoie des données aberrantes(15 mètres de pluie par heure), une alerte est levée. Sa gestion est une affaire de management, pas de programmation

---

C'est justement ce que j'allais dire. En même temps, un pluviomêtre ne devrait-il pas être réglé pour ne pas pouvoir envoyer cette pluviométrie ? Ou alors que cette valeur doive être vérifiée avant l'envoi ? Plus on détecte un dysfonctionnement tôt, moins ça coute cher de le corriger. C'est une des rares notions du management moderne avec laquelle je sois 100% d'acord.

Citation:

---

Code:

---

1 2 3 4 5 6 7

Sub TraitementTableau() For Ligne = 1 to MaxLignes For Colonne = 1 to MaxColonnes (24 lignes de traitement) Next Colonne Next Ligne End Sub

---

ou

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Sub TraitementTableau() For Ligne = 1 to MaxLignes Call TraitementLigne(Ligne) Next Ligne End Sub Sub TraitementLigne(Ligne as Integer) For Colonne = 1 to MaxColonnes Call TraitementCellule(Ligne, Colonne) Next Colonne End Sub Sub TraitementCellule(Ligne,Colonne) (24 lignes de traitement) End Sub

---

Perso, je préfère la première version, sachant que le traitement est spécifique, et non réutilisé ailleurs. Pour du réutilisable on peut modulariser, mais pour du spécifique, franchement, avoir la boucle, ça permet d'avoir l'ensemble de la cinématique sous les yeux. 28 lignes au lieu de 24, ça n'est pas la mort.

---

Je préfère aussi la première sachant que tu as donné la réponse dans la question : le code n'a pas besoin d'être réutilisé dans ses sous blocs. Donc on peut le garder cohérent. Et 28 lignes pour une fonction ça me semble tout à fait correct et approprié...