IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

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


Sujet :

Débats sur le développement - Le Best Of

  1. #261
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    Août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : Août 2005
    Messages : 2 894
    Points : 7 083
    Points
    7 083
    Par défaut
    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.
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  2. #262
    Membre averti
    Homme Profil pro
    Directeur de projet
    Inscrit en
    Octobre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur de projet

    Informations forums :
    Inscription : Octobre 2012
    Messages : 117
    Points : 343
    Points
    343
    Par défaut


    Citation Envoyé par el_slapper Voir le message
    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 , c'est bien souvent le petit détail qui vient ébranler l'édifice.

    Citation Envoyé par el_slapper Voir le message
    Euh, voyons, la compta d'une banque, c'est des centaines de JCL...
    Condoléances 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 Voir le message
    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

    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.

  3. #263
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Nemek Voir le message
    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 Voir le message
    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 .. 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...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  4. #264
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    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 Voir le message
    Tout ça pour finir par s'apercevoir, au bout de ..... 1 mois !!!! ... de recherches approfondies, partout - en en particulier dans le code .. 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...
    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.
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  5. #265
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    Août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : Août 2005
    Messages : 2 894
    Points : 7 083
    Points
    7 083
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    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 Voir le message
    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 .. 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...
    Je compatis 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 Voir le message
    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 Voir le message
    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 !
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  6. #266
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par Nemek Voir le message
    (.../...) 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 Voir le message
    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 Voir le message
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  7. #267
    Membre averti
    Homme Profil pro
    Directeur de projet
    Inscrit en
    Octobre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur de projet

    Informations forums :
    Inscription : Octobre 2012
    Messages : 117
    Points : 343
    Points
    343
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    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 Voir le message
    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.

  8. #268
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    Août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : Août 2005
    Messages : 2 894
    Points : 7 083
    Points
    7 083
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    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 Voir le message
    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


    Citation Envoyé par el_slapper Voir le message
    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 ^^
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  9. #269
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par Nemek Voir le message
    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 Voir le message
    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...
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  10. #270
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    Août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : Août 2005
    Messages : 2 894
    Points : 7 083
    Points
    7 083
    Par défaut
    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.
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  11. #271
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par Nemek Voir le message
    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 Voir le message
    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 Voir le message
    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
    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 Voir le message
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  12. #272
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par Nemek Voir le message
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  13. #273
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par arkhamon Voir le message
    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 Voir le message
    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...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  14. #274
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    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à...

    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" ?
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  15. #275
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  16. #276
    Membre expérimenté
    Homme Profil pro
    /
    Inscrit en
    Février 2003
    Messages
    433
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Belgique

    Informations professionnelles :
    Activité : /

    Informations forums :
    Inscription : Février 2003
    Messages : 433
    Points : 1 604
    Points
    1 604
    Par défaut
    Citation Envoyé par arkhamon Voir le message
    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,...

  17. #277
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    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

    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....
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  18. #278
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Au risque de me faire plein d'amis...
    Citation Envoyé par souviron34 Voir le message
    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 Voir le message
    C'est tout
    Ben tiens...

    Citation Envoyé par souviron34 Voir le message
    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 Voir le message
    (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 ?

    Citation Envoyé par souviron34 Voir le message
    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 Voir le message
    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 Voir le message
    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 ? 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... )

    Citation Envoyé par souviron34 Voir le message
    * 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 ?
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

  19. #279
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    (.../...)
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  20. #280
    Membre éprouvé

    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Janvier 2006
    Messages
    621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Janvier 2006
    Messages : 621
    Points : 1 264
    Points
    1 264
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    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... 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 Voir le message
    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 Voir le message
    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 Voir le message
    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.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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é...
    "L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
    Général George S. PATTON. Messine 1943.

Discussions similaires

  1. Réponses: 1
    Dernier message: 10/12/2015, 13h48
  2. [Questions]Le langage de programmation Binaire existe t-il ?
    Par Nasky dans le forum Langages de programmation
    Réponses: 30
    Dernier message: 16/11/2012, 10h09
  3. Réponses: 0
    Dernier message: 21/01/2011, 15h11
  4. Quel langage pour programme ne nécessitant pas d'install ?
    Par burnedsoul dans le forum Langages de programmation
    Réponses: 5
    Dernier message: 09/03/2006, 20h23
  5. Nombre de langage de programmation total
    Par Adrael dans le forum Langages de programmation
    Réponses: 16
    Dernier message: 22/07/2003, 01h06

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo