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. #281
    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
    je dis simplement quà force d'oubleir des bases qui sont claires et logiques, on pond des usines à gaz incontrolables...
    Je ne dis pas autre chose

    Je dis juste que justement, dans certains cas ces "règles" se heurtent à la logique du bon sens...


    Citation Envoyé par arkhamon Voir le message
    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...
    Va expliquer que quand un gouvernment promulgue une loi s'appliquant à tous, et que les médecins trouvent ça aberrant et protestent, le temps que ça repasse en commissions des lois, Sénat, et Assemblée, ton petit chérubin sera par exemple troué 2 fois pour une ponction lombaire et non pas une seule... Parce que simplement "le législateur" avait oublié le cas des enfants...

    (cas réel : plus d'un an entre la sortie de la loi et sa révision. Donc pendant plus d'un an les médecins allaient contre la loi...car pour eux, il était dangerux de faire plus q'une ponction lombaire sur un enfant, alors que 2 comme c'était recommandé sur un adulte ça posait pas de pbes)


    Citation Envoyé par arkhamon Voir le message
    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...
    Sauf que ce nivomètre est dans le Grand Nord canadien, et que le technicien ne pourra le dépanner que.... au début de l'été... Et on s'aperçoit qu'il ne marche pas en... Novembre.. Et il envoie toutes les heures une "mesure"...


    Citation Envoyé par arkhamon Voir le message
    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 ?
    J'ai fait 2 fois une fonction de presque 2000 lignes...

    Et honnêtement, au vu de ce qu'on lui demandait, la scinder aurait demandé soit plus de 40 paramètres à passer pour plus de 30 fonctions, soit pleins de variables globales.... Plus des pertes de temps d'éxécution à chaque appel...

    J'ai pas aimé les faire, mais j'ai pas trouvé de manière simple de ne pas les faire...
    "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

  2. #282
    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
    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...).
    J'ai déjà exposé mon point e vue là-dessus ailleurs,(et me suis d'ailleurs fait copieusement quasi insulté parce que j'osais dire qu'il fallait savoir ce qu'on faisait..), et je suis tout à fait conte les GC.


    Citation Envoyé par arkhamon Voir le message
    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.
    Sauf que quand tu fais quelque chose pour être dans le blizzard par moins 80, tu te limites au minimum.. Donc il n'y a pas de logiciel, juste une mini-carte électronique...

    Et que, comme déjà dit juste au dessus, ça peut prendre plus de 6 mois avant de pouvoir aller le dépanner..
    "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

  3. #283
    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 ne dis pas autre chose
    Je dis juste que justement, dans certains cas ces "règles" se heurtent à la logique du bon sens...
    Autant pour moi...

    Citation Envoyé par souviron34 Voir le message
    Va expliquer que quand un gouvernment promulgue une loi s'appliquant à tous, et que les médecins trouvent ça aberrant et protestent, le temps que ça repasse en commissions des lois, Sénat, et Assemblée, ton petit chérubin sera par exemple troué 2 fois pour une ponction lombaire et non pas une seule... Parce que simplement "le législateur" avait oublié le cas des enfants...

    (cas réel : plus d'un an entre la sortie de la loi et sa révision. Donc pendant plus d'un an les médecins allaient contre la loi...car pour eux, il était dangerux de faire plus q'une ponction lombaire sur un enfant, alors que 2 comme c'était recommandé sur un adulte ça posait pas de pbes)
    Moi je parlais juste d'informatique. J'avais pas bien saisi ton propos et j'ai moi même intrioduit la pratique médicale dasn le débat. Toutes mes excuses. La santé prime. Moi je parlais uniquement d'informatique...

    Citation Envoyé par souviron34 Voir le message
    Sauf que ce nivomètre est dans le Grand Nord canadien, et que le technicien ne pourra le dépanner que.... au début de l'été... Et on s'aperçoit qu'il ne marche pas en... Novembre.. Et il envoie toutes les heures une "mesure"...
    Ouais effectivemetn vu comme ça... Mais c'est de ta faute aussi tu me sors LE cas particulier qui met à bas (du moins localement) ma belle théorie...

    Citation Envoyé par souviron34 Voir le message
    J'ai fait 2 fois une fonction de presque 2000 lignes...

    Et honnêtement, au vu de ce qu'on lui demandait, la scinder aurait demandé soit plus de 40 paramètres à passer pour plus de 30 fonctions, soit pleins de variables globales.... Plus des pertes de temps d'éxécution à chaque appel...

    J'ai pas aimé les faire, mais j'ai pas trouvé de manière simple de ne pas les faire...
    Et allez hop encore le cas particulier qui tue...
    Bon j'ai moi aussi fait une fois une fonction qui prenait une palaquée de paramètres poru valoriser une opération financière. Et derrière je sias plus combien de lignes de code (et des appels dedans bien zür....).
    Et c'est vrai que celle la, quand elle bugge, bonjour...
    "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.

  4. #284
    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
    Moi je parlais uniquement d'informatique...

    Ouais effectivemetn vu comme ça... Mais c'est de ta faute aussi tu me sors LE cas particulier qui met à bas (du moins localement) ma belle théorie...

    Et allez hop encore le cas particulier qui tue...


    Je dit juste que justement, l'absolu des "règles" n'est qu'un guide, pas un "must do" absolu...

    Justement parce que il y a des cas particuliers...

    Et que la modélisation et l'arcboutement jusqu'au boutiste sur des règles sont absurdes, parce que nous ne travaillons pas "dans la théorie", mais dans la pratique, et que la pratique ne se résume pas à l'application de simples règles rigides..

    D'ailleurs, même dans ton exemple de lois, si il y a un juge, c'est bien que ce n'est pas "automatique".. Tu peux avoir violé la loi et avoir "des circonstances atténuantes", avoir commis un délit et non un crime, ou bien au contraire "avoir des circonstances aggravantes"..

    Un tribunal juge par rapport à l'esprit de la loi, rarement par rapport à la lettre.. Sinon une simple machine ou le commissarait pourait décider tout seul avec un barême...

    C'est strictement la même chose en informatique.. Que l'on garde toutes les bonnes règles en tête est une excellente chose.. Qu'on les applique partout systématiquement sans discernement est une très mauvaise chose..

    "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

  5. #285
    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 dit juste que justement, l'absolu des "règles" n'est qu'un guide, pas un "must do" absolu...

    Justement parce que il y a des cas particuliers...

    Et que la modélisation et l'arcboutement jusqu'au boutiste sur des règles sont absurdes, parce que nous ne travaillons pas "dans la théorie", mais dans la pratique, et que la pratique ne se résume pas à l'application de simples règles rigides..

    D'ailleurs, même dans ton exemple de lois, si il y a un juge, c'est bien que ce n'est pas "automatique".. Tu peux avoir violé la loi et avoir "des circonstances atténuantes", avoir commis un délit et non un crime, ou bien au contraire "avoir des circonstances aggravantes"..

    Un tribunal juge par rapport à l'esprit de la loi, rarement par rapport à la lettre.. Sinon une simple machine ou le commissarait pourait décider tout seul avec un barême...

    C'est strictement la même chose en informatique.. Que l'on garde toutes les bonnes règles en tête est une excellente chose.. Qu'on les applique partout systématiquement sans discernement est une très mauvaise chose..

    UN pour toi.
    Mais quand même... Si y a pas de lois, y a pas l'excitation de les violer légèrement un coup de temps en 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.

  6. #286
    Rédacteur
    Avatar de CyaNnOrangehead
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2008
    Messages
    777
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mai 2008
    Messages : 777
    Points : 1 731
    Points
    1 731
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Tu bosses sur des trucs 100% techniques, manifestement. Dans ce cadre, tu as surement raison. Quand on fait essentiellement du fonctionnel(dans le sens "métier", pas dans le sens "langage fonctionnel"), on aimerait bien avoir 100% de couverture automatique, mais c'est pas toujours possible.

    En d'autres termes, tu as raison, mais ça ne s'applique hélas pas partout.
    En fait je parlais effectivement du developpement de librairies.
    Je découpe mes projets comme suit :
    Partie potentielement réutilisable et / ou ça fait 10 fois qu'on l'écrit -> hop dans des librairies -> hop bardés de testes unitaires (je préfère ceux d'intégration et de complience, plus consistents à mon goût... n'en déplaise).

    Partie HMI, métier simple et tout ça, en générale, les unitaires sont très compliqués et n'apportent pas forcément grand chose.

    Du coup je découple au maximum pour pouvoir faire le maximum de testes, et tu as raison, une partie n'est pas testé automatiquement.



    Mince, je suis litéralement floudé sous les réponses....
    J'ai vraiment déclenché une guere des tranchés..... cool ....
    Retrouvez tous mes tutoriels : http://caron-yann.developpez.com/

    Et mon projet en cours : Algoid - programming language

    N'oubliez pas de consulter les FAQ Java (http://java.developpez.com/faq/) et les cours et tutoriels Java (http://java.developpez.com/cours/)

  7. #287
    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 arkhamon Voir le message
    (.../...)
    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...).
    Pour le GC, j'en sais rien. Je n'ai pas fait assez de java pour avoir un avis pertinent. Je sais juste que celui de VBA pour excel contient un trou(quand une collection d'objets contient elle-même une collection d'objets, je crois),, et j'ai pris l'habitude de faire des set MonObjet = Nothing à la fin de tous mes paragraphes, histoire de ne pas me faire surprendre. Même si dans 99% du temps, le GC ferait mieux.

    Citation Envoyé par arkhamon Voir le message
    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 ?
    Tout à fait. Pourtant, je reçois régulièrement des typologies erronées (les seules valeurs autorisées sont 001 et 003, et j'ai poussé le vice jusqu'à accepter quand même les " 1" ou les "1 "). Si la typologie est erronée, je ne sais pas dans quel sortie je dois orienter le fichier. Donc je DOIS contrôler.

    C'est effectivement un doublon de contrôle(simple dans ce cas précis, j'en ai des nettement plus exotiques). Pour autant, j'ai le choix entre contrôler, planter ou dysfonctionner(i.e. inférer aléatoirement la bonne sortie). Contrôler est, et de loin, ce qui fonctionne le mieux.

    La source de l'erreur n'est pas, dans mon cas, un blizzard à -80°C. C'est un utilisateur surbooké, qui utilise un outil commercial très efficace, mais qui ne permet pas le contrôle applicatif des données. Donc, j'ai de la merde. Dans d'autres cas, ça sera juste l'extrême complexité des règles fonctionelles qui fera que je reçois des choses fausses ou incohérentes, ce qui n'est pas forcément testable par l'appli amont(surtout si j'en ai 2 dont je rapproche les données - chaque fichier peut être bon individuellement, mais pourri par rapport à l'autre).

    Faute de mieux, je contrôle. Parceque c'est nécéssaire, et que la confiance m'a trop envoyé dans le décor.

    Citation Envoyé par arkhamon Voir le message
    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é...
    Sauf qu'il dépasse la règle des 25 lignes. C'est d'ailleurs moi qui avait pondu cette horreur(je débutais, hein...). Mais ça peut être une conséquence de la règle des 25 lignes.

    Et, comme l'a dit Souviron34, dans des cas particuliers, on peut être amené à commettre des abominations - parcequ'on a pas forcément le choix. Je me souviens d'un collègue qui avait - à son grand regret - commis un monstre de 36000 lignes de COBOL. Simplement, il fallait faire un entonnoir, appeller 73 référentiels différents(donc 73 modules d'accès, séparés du programme), chaque appel dépendait du résultat du précédent, faire des contrôles(parceque là encore, le fichier en entrée était réputé non fiable, à juste titre), et gérer les erreurs de tout ça.

    J'avais(et quelques autres aussi) été amené à réfléchir à un découpage de la bête(nom donné par son auteur); nous sommes tous arrivés à la même conclusion : la tuyauterie de découpage serait vite ingérable(comme dans la fonction monstrueuse de Souviron34). Il y avait sans doute moyen de gagner quelques milliers de ligne sur les traitements d'erreur, mais le corps du programme était insécable, fonctionellement.

    Evidemment, quand je peux éviter, j'évite. Dans une récente situation similaire, mais avec moins d'adhérences, j'ai déporté les appels référentiels et leur gestion d'erreurs dans des modules à part(qui ne sont donc que des encapsulations du module d'accès standard, spécialisée pour MON appel). Et je suis resté à des tailles raisonnables pour chaque composant. Mais ça, c'est quand c'est possible.

    @CyaNnOrangehead : pigé, et +1 !
    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.

  8. #288
    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
    Tout à fait. Pourtant, je reçois régulièrement des typologies erronées (les seules valeurs autorisées sont 001 et 003, et j'ai poussé le vice jusqu'à accepter quand même les " 1" ou les "1 "). Si la typologie est erronée, je ne sais pas dans quel sortie je dois orienter le fichier. Donc je DOIS contrôler.

    C'est effectivement un doublon de contrôle(simple dans ce cas précis, j'en ai des nettement plus exotiques). Pour autant, j'ai le choix entre contrôler, planter ou dysfonctionner(i.e. inférer aléatoirement la bonne sortie). Contrôler est, et de loin, ce qui fonctionne le mieux.
    Tu as pris la bonne décision, dans ce contexte, c'est tout à ton honneur.

    Citation Envoyé par el_slapper Voir le message
    La source de l'erreur n'est pas, dans mon cas, un blizzard à -80°C. C'est un utilisateur surbooké, qui utilise un outil commercial très efficace, mais qui ne permet pas le contrôle applicatif des données. Donc, j'ai de la merde. ...... Faute de mieux, je contrôle. Parceque c'est nécéssaire, et que la confiance m'a trop envoyé dans le décor.
    J'en déduis donc que tu surcharges inutilement ton soft pour pallier à l'incompétence de personnes en amont. C'est tout le problème des développeurs : une partie (compétents) passe son temps à bidouiller pour pallier l'incompétence d'une autre partie qui fait n'importe quoi. Admets que si chacun faisait son travail correctemetn et effectuait ses contrôles correctement, la vie des autres serait grandement simplifiée.

    C'est en ça que je propose un strict retour aux règles : que tout le monde puisse bosser sereinement sans avoir sans arrêt besoin de réinventer la roue.

    Citation Envoyé par el_slapper Voir le message
    Sauf qu'il dépasse la règle des 25 lignes. C'est d'ailleurs moi qui avait pondu cette horreur(je débutais, hein...). Mais ça peut être une conséquence de la règle des 25 lignes.
    En même temps, 25, 26 , 27, 28... Non je déconne... J'ai été un peu rugueux avec mes règles. Je ne sais pas s'il faut limiter une fonction à 25 ou 30 lignes (en fait il ne faut pas), je pense juste qu'il faut savoir raison garder, et qu'en se forçant à respecter des règles, on se laisse justement la possibilité parfois et quand c'est justifié, de les adapter un peu. Mais encore faut-il savoir y revenir juste après et ne pas faire preuve de laxisme...

    Citation Envoyé par el_slapper Voir le message
    Et, comme l'a dit Souviron34, dans des cas particuliers, on peut être amené à commettre des abominations - parcequ'on a pas forcément le choix. Je me souviens d'un collègue qui avait - à son grand regret - commis un monstre de 36000 lignes de COBOL. Simplement, il fallait faire un entonnoir, appeller 73 référentiels différents(donc 73 modules d'accès, séparés du programme), chaque appel dépendait du résultat du précédent, faire des contrôles(parceque là encore, le fichier en entrée était réputé non fiable, à juste titre), et gérer les erreurs de tout ça.
    Effectivement la on n'est plus dans une fonction mais dans une appli
    Ceci illustre bien deux concepts : le premier est que revérifier les données d'entrée compléxifie inutilement et met en péril. Le second est qu'à mon avis dans ce projet, les phases amont (analyse fonctionnelle entre autres) n'ont pas été menées correctement. un bloc de 36000 lignes en COBOL est effectivement une aberration !

    Citation Envoyé par el_slapper Voir le message
    J'avais(et quelques autres aussi) été amené à réfléchir à un découpage de la bête(nom donné par son auteur); nous sommes tous arrivés à la même conclusion : la tuyauterie de découpage serait vite ingérable(comme dans la fonction monstrueuse de Souviron34). Il y avait sans doute moyen de gagner quelques milliers de ligne sur les traitements d'erreur, mais le corps du programme était insécable, fonctionellement.
    A mon avis nous sommes dans un autre cas : une tentative (en général vouée à l'échec) de refactorer une usine à gaz existante. Un architecte est formel : quand les bases sont pourries, on démolit et on rebatit proprememnt, au final ça revient toujours moins cher.

    J'aime bien cet exemple de l'architecte et de la tour : on étudie tout avant, et on se tient au plan, sinon la tour se casse la gueule. J'ai encore JAMAIS vu Vinci ou Bouygues rajouter 3 étages en heut d'une tour existante ou un niveau de sous sol de parking en dessous.
    A force en informatique d'oublier les règles de base, on en arrive à des tours de Pise (sauf que la vraie elle est encore debout elle) voir des Tchernobyl en puissance, dasn lesquels on ne contrôle plus rien...
    "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.

  9. #289
    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 arkhamon Voir le message
    Tu as pris la bonne décision, dans ce contexte, c'est tout à ton honneur.

    J'en déduis donc que tu surcharges inutilement ton soft pour pallier à l'incompétence de personnes en amont. C'est tout le problème des développeurs : une partie (compétents) passe son temps à bidouiller pour pallier l'incompétence d'une autre partie qui fait n'importe quoi. Admets que si chacun faisait son travail correctemetn et effectuait ses contrôles correctement, la vie des autres serait grandement simplifiée.
    Mais nous vivons dans un monde réel. Shit happens. Et il faut la nettoyer.

    Citation Envoyé par arkhamon Voir le message
    C'est en ça que je propose un strict retour aux règles : que tout le monde puisse bosser sereinement sans avoir sans arrêt besoin de réinventer la roue.
    c'est probablement possible dans un monde peuplé uniquement de développeurs. et encore : de développeurs ayant tous la philosophie qui va bien.

    Citation Envoyé par arkhamon Voir le message
    En même temps, 25, 26 , 27, 28... Non je déconne... J'ai été un peu rugueux avec mes règles. Je ne sais pas s'il faut limiter une fonction à 25 ou 30 lignes (en fait il ne faut pas), je pense juste qu'il faut savoir raison garder, et qu'en se forçant à respecter des règles, on se laisse justement la possibilité parfois et quand c'est justifié, de les adapter un peu. Mais encore faut-il savoir y revenir juste après et ne pas faire preuve de laxisme...
    Jusqu'ou? Soit on définit une règle stricte, soit on ne le fait pas. Si on ne le fait pas, il y aura toujours des petits malins. C'est pour ça qu'à 52 en ville, on est tranquille, à 53, on prend une prune sévère. Parceque sinon, les petits malins tirent toujours plus sur la corde.

    On est pas dans un monde parfait.

    Citation Envoyé par arkhamon Voir le message
    Effectivement la on n'est plus dans une fonction mais dans une appli
    Ceci illustre bien deux concepts : le premier est que revérifier les données d'entrée compléxifie inutilement et met en péril. Le second est qu'à mon avis dans ce projet, les phases amont (analyse fonctionnelle entre autres) n'ont pas été menées correctement. Un bloc de 36000 lignes en COBOL est effectivement une aberration !
    Il y avait un tas de raisons de le faire ainsi. d'abord, nous recevions des données d'un partenaire extérieur. Impossible de faire l'impasse sur la vérification technique des données. On a même reçu des montants en Yen ou en Won avec des décimales(ce qui n'existe pas). En tant qu'équipe prestataire pour la banque A, nous n'avions pas le pouvoir d'imposer au partenaire B les contrôles que nous souhaitions avoir. Donc, programmation défensive.

    Je ne suis pas informaticien à la base. Je suis ingénieur généraliste, avec en plus une spécialisation plasturgie. Un des axes fondamentaux de la conception de produtis industriels, c'est de concevoir non seulement en fonction des besoins, mais aussi en fonction des méthodes de fabrication. Ainsi, la forme de ton clavier est fortement influençée par la fonction(porter des touches), le design, mais aussi la méthode de fabrication(l'injection thermoplastique en l'occurence). C'est pour ça que les touches sont plus larges à la base qu'au sommet. L'inverse serait faisable, mais le moule couterait bien plus cher(une histoire d'angle de dépouille qui facilite la fabrication du moule).

    Force est de constater que les gens qui ont besoin de systèmes informatiques n'ont pas ce genre de philosophie, ni ce genre de formation. Alors tu peux mener ta petite croisade, mais tu ne convaincras que les gens qui sont déjà sensibilisés. Les gens du marketing bancaire, ils ont le pognon, et ils décident. C'est la vraie vie. Celà implique des architectures suboptimales.

    Citation Envoyé par arkhamon Voir le message
    A mon avis nous sommes dans un autre cas : une tentative (en général vouée à l'échec) de refactorer une usine à gaz existante. Un architecte est formel : quand les bases sont pourries, on démolit et on rebatit proprememnt, au final ça revient toujours moins cher.
    Joel Spolsky n'est pas d'accord.. Moi non plus. J'ai déjà reduit en cendres d'anciennes architectures pourries pour les remplacer par du solide, mais j'ai toujours pris le soin de cannibaliser un maximum de code fonctionnel qui fonctionnait très bien(et à le refactorer le cas échéant). Parceque le code, aussi vieux et moche qu'il soit, il marche. Je refuse de jeter à la poubelle ce qui marche. Le cout en termes de dysfonctionnements est bien trop élevé pour le client.

    Citation Envoyé par arkhamon Voir le message
    J'aime bien cet exemple de l'architecte et de la tour : on étudie tout avant, et on se tient au plan, sinon la tour se casse la gueule. J'ai encore JAMAIS vu Vinci ou Bouygues rajouter 3 étages en heut d'une tour existante ou un niveau de sous sol de parking en dessous.
    A force en informatique d'oublier les règles de base, on en arrive à des tours de Pise (sauf que la vraie elle est encore debout elle) voir des Tchernobyl en puissance, dasn lesquels on ne contrôle plus rien...
    Sauf que l'informatique est beaucoup plus fluide que le bâtiment. L'allégorie est fausse. On peut faire bien plus qu'un bête pont(même de 3 km de long, un pont est bête, il ne comprend qu'un nombre limité de cables, piliers, et voussoirs), tout simplement parcequ'on est pas limité par la physique, la mécanique, la résistance des matériaux ou les conditions de constructions(les compilateurs n'ont pas de problèmes en cas de tempête, par exemple).

    Si tu t'interdis de faire évoluer une conception propre, mais dépassée par la concurrence, tu crèves. Sans entrer dans son délire pro-LISP, on ne peut que constater que Paul Graham a tué la concurrence en rajoutant des fonctionnalités non prévues en 24 ou 48 heures, juste après que la concurrence aie annoncé ladite fonctionnalité. :
    Citation Envoyé par Paul Graham
    ...our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too.
    Si il s'était astreint à suivre son plan, il aurait été bouffé par la concurrence. Au contraire, il a bouffé la concurrence(avant de se vendre 50 M$ à Yahoo et de financer dropbox et airbnb). Parceque, justement, il n'a eu aucun état d'âme, ni aucune difficulté technique, à rajouter des étages à son building.



    Nous ne travaillons pas pour le plaisir de faire des beaux programmes - même si c'est une motivation puissante. Nous travaillons pour multiplier la productivité de nos clients : les vendeurs en lignes de Paul Graham, les médecins de Souviron34, mes marketeurs bancaires, ou les développeurs utilisant le compilateur de CyaNnOrangehead. Dans 3 cas sur 4, ce sont des non-informaticiens. Qui ont autre chose à foutre dans la vie que de respecter nos petites règles. C'est à nous de nous mettre à leur service, pas de les plier à nos désirs les plus fous. Parceque, au final, ce sont eux qui créent la richesse qui paye notre salaire.
    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.

  10. #290
    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
    Mais nous vivons dans un monde réel. Shit happens. Et il faut la nettoyer.
    Ouais. Mais on peut aussi apprendre aux gens à pas tout dégueulasser.

    Citation Envoyé par el_slapper Voir le message
    Force est de constater que les gens qui ont besoin de systèmes informatiques n'ont pas ce genre de philosophie, ni ce genre de formation. Alors tu peux mener ta petite croisade, mais tu ne convaincras que les gens qui sont déjà sensibilisés. Les gens du marketing bancaire, ils ont le pognon, et ils décident. C'est la vraie vie. Celà implique des architectures suboptimales.
    Pas d'accord. C'est pas parce que certains ont le pognon (d'ailleurs, ils l'ont souvent grâce à l'informatique, un peu de gratitude ça ferait pas de mal) que ça leur donne droit de faire ou faire faire n'importe quoi. Pour ensuite taper sur ces cons d'informaticiens qui ont ENCORE pondu un truc plein de bugs. Si on laissait faire les pros on n'aurait moins de soucis.

    Citation Envoyé par el_slapper Voir le message
    J'ai déjà reduit en cendres d'anciennes architectures pourries pour les remplacer par du solide, mais j'ai toujours pris le soin de cannibaliser un maximum de code fonctionnel qui fonctionnait très bien(et à le refactorer le cas échéant). Parceque le code, aussi vieux et moche qu'il soit, il marche. Je refuse de jeter à la poubelle ce qui marche. Le cout en termes de dysfonctionnements est bien trop élevé pour le client.
    Tout à fait d'accord, même dans du code pourri, il y a toujours des trucs à récupérer qui marchaient. D'ou l'importance justement de faire dans le modulaire : c'est plus facile d'identifier ce qui peut être récupéré.

    Citation Envoyé par el_slapper Voir le message
    Sauf que l'informatique est beaucoup plus fluide que le bâtiment. L'allégorie est fausse. On peut faire bien plus qu'un bête pont(même de 3 km de long, un pont est bête, il ne comprend qu'un nombre limité de cables, piliers, et voussoirs), tout simplement parcequ'on est pas limité par la physique, la mécanique, la résistance des matériaux ou les conditions de constructions(les compilateurs n'ont pas de problèmes en cas de tempête, par exemple).
    Un pont est loni d'être bête, et il subit toute une série de contraintes dont certaines sont dynamiques. Quant au compilateur, ce n'est qu'un morceau de "l'édifice". Tiens d'ailleurs en passant, le compilo demande à ce que la syntaxe et la structure soit parfaite, sinon il stoppe. Il n'accepte aucune trangession à ses régles (qui sont porutant strictes et parfois complexes), et pourtant personne ne critique. C'est peut être pas pour rien...

    Citation Envoyé par el_slapper Voir le message
    Si tu t'interdis de faire évoluer une conception propre, mais dépassée par la concurrence, tu crèves. Sans entrer dans son délire pro-LISP, on ne peut que constater que Paul Graham a tué la concurrence en rajoutant des fonctionnalités non prévues en 24 ou 48 heures, juste après que la concurrence aie annoncé ladite fonctionnalité. :
    Faut juste pas confondre capacité de développer rapidement une fonctionnalité et le faire comme un porc.

    Citation Envoyé par el_slapper Voir le message
    Dans 3 cas sur 4, ce sont des non-informaticiens. Qui ont autre chose à foutre dans la vie que de respecter nos petites règles. C'est à nous de nous mettre à leur service, pas de les plier à nos désirs les plus fous. Parceque, au final, ce sont eux qui créent la richesse qui paye notre salaire.
    Ben jsutement comme je le disais dans un autre sujet, faudrait peut être arréter de prendre des non-informaticiens pour faire de l'informatique. Sous le prétexte fallacieux que chacun peut avoir un micro dans son salon, et que le pekin moyen a fait trois macros excel, un hello world en VBA et son pseudo site PHP que personne ne consulte, tout le monde se bombarde informaticien et pourrit le secteur. J'ai jamais vu un hopital embaucher un plombier pour faire de la chirurgie intestinale, ni un garage embaucher pour de la mécanique un passionné de Mécano (le jeu), ni Vinci embaucher un passionné de Légos pour bâtir des tours. Alros faudrait peut être arréter de prendre des "sup de co option finance internationale" pour faire de l'informatique sous prétexte qu'en projet de 3ème année il a pondu un vague pseudo site PHP de réservation de place dans sa cantine, le tout en mode "projet transverse"...

    C'est ce type de charlots qui pourrissent le métier, métier qui ne t'en déplaise, DOIT être fait par des professionnels, professionnels ayant eu une VRAIE formation et suivant les règles de l'art. Y aura peut être moins de plantages...
    "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.

  11. #291
    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 le dit el_slapper "Shit happens"...
    C'est pas pour autant qu'on doit accepter (puis sacraliser) le fait que n'importe qui saloppe tout !
    Citation Envoyé par souviron34 Voir le message
    Et je suis toujours pour avoir un algo sûr à 100% (qui donc vérifie ses données) que un algo qui se base sur la pré-supposition que les données sont valables..
    Je n'ai pas parle de pré-supposition, j'ai juste dit qu'en faisant comme ça, on duplique du code, on introduit des facteurs de risques, on réduit les performances, on monopolise du temps machine pour des tâches inutiles, on rend inextricables les analyses d'impact, et j'en passe et des meilleurs... Au final, on entérinne le fait que tout le monde fait n'importe quoi.
    Quel que soit le métier, le professionnel s'attend à utiliser des outils corrects, et à bosser sur des bases saines. Tous les métiers... Sauf l'informatique ou on accepte que n'importe qui foute son nez là ou y a pas d'eau pour el laver ! C'est quand même effarant ça ! Accepter que tout un pan de notre économie (et non le moindre puisque maintenant tout se fait avec l'informatique) soit confié à des branques qui n'ont aucune formation digne de ce nom...

    Citation Envoyé par souviron34 Voir le message
    Si tu fais un algo d

    Le second est qu'à mon avis dans ce projet, les phases amont (analyse fonctionnelle entre autres) n'ont pas été menées correctement. un bloc de 36000 lignes en COBOL est effectivement une aberration !

    A mon avis nous sommes dans un autre cas : une tentative (en général vouée à l'échec) de refactorer une usine à gaz existante. Un architecte est formel : quand les bases sont pourries, on démolit et on rebatit proprememnt, au final ça revient toujours moins cher.

    J'aime bien cet exemple de l'architecte et de la tour : on étudie tout avant, et on se tient au plan, sinon la tour se casse la gueule. J'ai encore JAMAIS vu Vinci ou Bouygues rajouter 3 étages en heut d'une tour existante ou un niveau de sous sol de parking en dessous.
    A force en informatique d'oublier les règles de base, on en arrive à des tours de Pise (sauf que la vraie elle est encore debout elle) voir des Tchernobyl en puissance, dasn lesquels on ne contrôle plus rien...
    T'as du rater un slash-quote...
    "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.

  12. #292
    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
    T'as du rater un slash-quote...
    Non j'ai zappé une touche et ça a envoyé le mess avant que j'ai fini je delete..
    "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

  13. #293
    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
    J'en déduis donc que tu surcharges inutilement ton soft pour pallier à l'incompétence de personnes en amont. C'est tout le problème des développeurs : une partie (compétents) passe son temps à bidouiller pour pallier l'incompétence d'une autre partie qui fait n'importe quoi. Admets que si chacun faisait son travail correctemetn et effectuait ses contrôles correctement, la vie des autres serait grandement simplifiée.
    ...
    Effectivement la on n'est plus dans une fonction mais dans une appli
    Ceci illustre bien deux concepts : le premier est que revérifier les données d'entrée compléxifie inutilement et met en péril.
    Comme le dit el_slapper "Shit happens"...

    Et je suis toujours pour avoir un algo sûr à 100% (qui donc vérifie ses données) que un algo qui se base sur la pré-supposition que les données sont valables..

    Si tu fais un algo dans lequel il y a une division, tu ne testes pas avant la division si ce qui va être au dénominateur est nul ???

    Moi si...

    Et on ne parle pas d'incompétence.. On parle de la réalité, que ce soit numérique, des bases, des données, des "glitch" électroniques (une panne du réseau en plein au milieu d'une écriture, ou d'une lecture, etc etc etc)..

    Mieux vaut un test 99.99% du temps inutile qu'un crash....



    Citation Envoyé par arkhamon Voir le message
    Le second est qu'à mon avis dans ce projet, les phases amont (analyse fonctionnelle entre autres) n'ont pas été menées correctement. un bloc de 36000 lignes en COBOL est effectivement une aberration !
    Ben voyons..... Il y a des moments où simplement le but est de solutionner un problème, et où ce problème est dû à une nouveauté, qui n'était pas présente lors de la phase d'analyse/conception..

    Nous sommes d'autre part dans un monde réel, très loin d'un idéal théorique, dans lequel et les finances et les utilisateurs sont la base et le fond...

    Entre les nouveautés du métier pour lequel le logiciel est destiné, son envergure initiale, les budgets et délais autorisés, et l'envergure des utilisateurs (en terme de nombre et de "captivité") , c'est le plus souvent une demande qui apparaît au bout de X nombres d'années d'utilisation...



    Citation Envoyé par arkhamon Voir le message
    A mon avis nous sommes dans un autre cas : une tentative (en général vouée à l'échec) de refactorer une usine à gaz existante. Un architecte est formel : quand les bases sont pourries, on démolit et on rebatit proprememnt, au final ça revient toujours moins cher.

    J'aime bien cet exemple de l'architecte et de la tour : on étudie tout avant, et on se tient au plan, sinon la tour se casse la gueule. J'ai encore JAMAIS vu Vinci ou Bouygues rajouter 3 étages en heut d'une tour existante ou un niveau de sous sol de parking en dessous.
    A force en informatique d'oublier les règles de base, on en arrive à des tours de Pise (sauf que la vraie elle est encore debout elle) voir des Tchernobyl en puissance, dasn lesquels on ne contrôle plus rien...
    Il est LA PLUPART DU TEMPS extrêmement mauvais de vouloir ré-écrire quelque chose qui marche...

    Outre le coût et temps démesuré, le fait de passer à côté d'un cas subtil figurant dans le code, et l'expérience utilisateur mise dans l'écriture/débugage/fine tuning de la version existante, juste la nécessaire étape de bugs te mettra à dos tous les utilisateurs et le SAV (c'est eux qui vont en subir les conséquences) de manière durable voire définitive... Sans compter justement les inputs des utilisateurs qui ont été inclus dans la précédente version, et qu'il va re-falloir solliciter..

    Et nous ne sommes pas les seuls à le dire..

    Lis par exemple Rewrites considered harmful ?...


    Excuse-moi, mais je pense que tu vis ou a vécu dans un monde très protégé, sur de petites applis, ou grosses mais avec un environnement très particulier..

    Il n'y a AUCUN soft sur lequel j'ai travaillé depuis plus de 25 ans qui aurait pu être ré-écrit, sauf cas très particulier pour lequel la conception était entièrement erronée.. (puisqu'il ne marchait pas)..

    Quelque chose qui est complexe et qui marche, on ne le "refait pas"...

    A moins d'accepter d'avoir un budget et un délai démesuré, et des utilisaeurs hyper-sympas prêts à tout pour toi....
    "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. #294
    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
    Si tu fais un algo dans lequel il y a une division, tu ne testes pas avant la division si ce qui va être au dénominateur est nul ???
    Si la provenance n,'est pas sure, je teste. Mais dans l'absolu, je ne devrais pas avoir à le faire. Mais je suis d'accord, entre l'absolu et la réalité...
    Citation Envoyé par souviron34 Voir le message
    Et on ne parle pas d'incompétence.. On parle de la réalité, que ce soit numérique, des bases, des données, des "glitch" électroniques (une panne du réseau en plein au milieu d'une écriture, ou d'une lecture, etc etc etc)..
    Justement la vérification de l'écriture, c'est pas ton soft qui le fait, c'est al couche réseu dédiée de l'OS. Dans ce cas là pourquoi ton soft ne fait-il pas une vérification des paquets IP ? Tu te bases donc sur la sécurité d'IP pour travailler. Ton appli se base sur le principe que l'OS est solide. Ce qu'on exoige d'nun OS, pourquoi ne pas se l'éxiger de soi ou des applis amont ?

    Citation Envoyé par souviron34 Voir le message
    Mieux vaut un test 99.99% du temps inutile qu'un crash....
    C'est pas faux.

    Citation Envoyé par souviron34 Voir le message
    Il est LA PLUPART DU TEMPS extrêmement mauvais de vouloir ré-écrire quelque chose qui marche...
    "En informatique, quand ça marche on touche pas"... Ca c'est une de mes phrases fétiches ! Mais parfois quand ça marche plus ou qu'il faut faire évoluer la réécriture s'avère souvent plus solide que le rustinage. Pour faire le paralelle, sur une chambre à air, on met une, max 2 rustines mais après on change. et de toutes façons on reste pas 2 ans avec une rustine...

    Citation Envoyé par souviron34 Voir le message
    Excuse-moi, mais je pense que tu vis ou a vécu dans un monde très protégé, sur de petites applis, ou grosses mais avec un environnement très particulier..
    Salles des marchés, avec besoins de réactivité énorme, tolérance 0 sur les plantages, soit disant pas de thune pour redévelopper... Environnement protégé...
    Et pourtant, ma première tâche a été d'adapter une chaine pour intégrer de nouveaux instruments. J'ai dit que c'était aps jouable et qu'il valait mieux redévelopper from scratch. 2 semaines de négo mais j'ai eu le feu vert. J'ai juste réutilisé quelques morceaux de code mais tout le reste est neuf. 180 000 lignes de code, et ça a tenu 3 ans sans aucune maintenance si support ni plantage.

    Citation Envoyé par souviron34 Voir le message
    Quelque chose qui est complexe et qui marche, on ne le "refait pas"...
    cf ma phrase fétiche...

    Citation Envoyé par souviron34 Voir le message
    A moins d'accepter d'avoir un budget et un délai démesuré, et des utilisaeurs hyper-sympas prêts à tout pour toi....
    Je suis pas croyant, mais Dieu t'entende mon fils...
    "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. #295
    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
    C'est pas pour autant qu'on doit accepter (puis sacraliser) le fait que n'importe qui saloppe tout !
    Non, mais c'est pas pour autant qu'on doit se f.utre de la non-conformité d'une entrée...

    Si les prises électriques n'acceptaient que les derniers fils de la denrière norme AFNIR, on n'irait pas loin, et il faudrait tous les ans changer tous les équipements électrique d'une maison...


    Citation Envoyé par arkhamon Voir le message
    Je n'ai pas parle de pré-supposition, j'ai juste dit qu'en faisant comme ça, on duplique du code, on introduit des facteurs de risques, on réduit les performances, on monopolise du temps machine pour des tâches inutiles, on rend inextricables les analyses d'impact, et j'en passe et des meilleurs... Au final, on entérinne le fait que tout le monde fait n'importe quoi.
    Non.. On entérine simplement le fait que "tout n'est pas parfait dans le meilleur des mondes possible"..

    Et que 250000 lignes de docs ne seront pas forcément remises à jour lors d'une évolution d'une partie d'un soft...

    Et que justement, au vu de ce que tu disais, dans une "blibliothèque", on peut être appelé par n'importe qui, et que donc la robustesse est un facteur essentiel..


    Citation Envoyé par arkhamon Voir le message
    Quel que soit le métier, le professionnel s'attend à utiliser des outils corrects, et à bosser sur des bases saines. Tous les métiers... Sauf l'informatique ou on accepte que n'importe qui foute son nez là ou y a pas d'eau pour el laver ! C'est quand même effarant ça ! Accepter que tout un pan de notre économie (et non le moindre puisque maintenant tout se fait avec l'informatique) soit confié à des branques qui n'ont aucune formation digne de ce nom...
    Non, en informatique comme dans les autres métiers, on se débrouille avec ce qu'on a..

    Un mécano qui dépanne ta voiture, il regarde, et, avec ses connaissances, essaye de te sorrir de ce mauvais pas avec la "moins pire" des solutions.

    Même chose pour le maçon à qui tu demandes de te rajouter une fenêtre dans une pièce... Il ne te dis pas "il faut casser toute la maison et tout reconstruire".

    Même chose pour Vinci ou Bouygues quand le gouvernement ou une grosse boîte leur demande d'aménager un ancien hôtel particulier du XVIII en bureaux, ou en salle de réception..

    Même chose pour un chef cusiinier, qui a 2 commis malades et a d'un seul coup sa salle à manger pleine comme un oeuf...
    "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

  16. #296
    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
    Salles des marchés, avec besoins de réactivité énorme, tolérance 0 sur les plantages, soit disant pas de thune pour redévelopper... Environnement protégé...
    Si quand même... D'après mon expérience des banques, le budget n'est pas un problème, et le "temps" non plus, puisqu'il y a une équipe à temps plein.. (et les utilisateurs sont "captifs").


    Dans mes domaines, que ce soit le médical, la météo, ou les aiguilleurs du ciel, d'une part les utilisateurs ne sont pas captifs (ils se débrouillent très bien sans info, et ne sont pas obligés de l'utiliser), tu n'es qu'un forunisseur parmi d'autres potentiels, leurs services achats peuvent donc se tourner vers d'autres boites que la tienne, d'autre part il n'y a pas d'équipes à temps plein - tu fais un projet pour le vendre. Quand il est vendu, tu as un SAV, mais c'est tout.. Et enfin le budget est restreint : si quelqu'un a payé 5 millions pour un soft, il va pas le re-payer tous les 2 ans.. Tu le fais pour 10, 15 ou 20 ans... Si ils t demandent une modif, il ne vont ni t'accorder des années, ni des millions.. Il faut que stiictement tout marche comme précédemment, la modif en plus.. Sans aucun droit à une erreur... éventuellement un bug dans la nouvelle fonctionalité.

    Et en tant qu'industriel, tu ne re-dépenses pas les X millions que tu as dépens pour mettre au point ton soft pour le plaisir. de le ré-écrire proprement..
    "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

  17. #297
    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
    Si quand même... D'après mon expérience des banques, le budget n'est pas un problème, et le "temps" non plus, puisqu'il y a une équipe à temps plein.. (et les utilisateurs sont "captifs").
    Sans aucune méchanceté de ma part, ça diot faire un bon moment que t'as pas mis les pieds dans des banques en général, et dans les SdM en particulier. Le mot d'ordre est "faire plus avec moins"... Et le mot à la mode est "arbitrage"...
    "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.

  18. #298
    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
    Sans aucune méchanceté de ma part, ça diot faire un bon moment que t'as pas mis les pieds dans des banques en général, et dans les SdM en particulier. Le mot d'ordre est "faire plus avec moins"... Et le mot à la mode est "arbitrage"...
    ça fait un bon moment, oui, et c'était pas du côté des SdM... Mais en attendant, quel est le budget annuel accordé à l'informatique ? Et il y a une équipe à temps plein non ??

    (à mon épqoue, sur 15 personnes en SI, 2 étaient salariées de la banque, les autres étaient des gars de SSII (comme moi) à temps plein)


    Pour te donner une idée, dans le médical j'avais droit à 6 personnes, 1 million, et un an (le soft existant avait bénéficié de 60 personnes pendant 15 ans, et 2 millions de lignes). Dans la météo j'avais droit à 1 personne, 350 000 euros à raison de 50 000 par an, et 7 ans, mais 1 an pour la première version opérationnelle nationale (le soft existant avait bénéficié de 100 personnes pendant 10 ans, et 2 millions de lignes), et pour les aiguilleurs 6 personnes, 1 an, et 500 000 euros ((le soft existant avait bénéficié de 10 personnes pendant 30 ans, et 5 millions de lignes)....
    "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

  19. #299
    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
    juste pour terminer sur cet aparté - nous sommes loin du sujet initial -, je voulais citer explicitement la conclusion du lien donné précédemment :

    So in summary, I would say that the "cost" of a total rewrite depends on three factors:

    • Amount of "accumulated wisdom" (bug fixes, tweaks and useful patches) in the old version that will be discarded
    • How incompatible the new version is with the old version (API, data formats, protocols etc)
    • How many people used the old version and will be affected by the changes


    A suggestion: If you have a very successful application, don't look at all that old, messy code as being "stale". Look at it as a living organism that can perhaps be healed, and can evolve. You can refactor, you can rewrite portions of the internals to work better, many things can be accomplished without abandoning all the experience and error correction that went into that codebase. When you rewrite you are abandoning history and condemning yourself to relive it.
    "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

  20. #300
    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
    ça fait un bon moment, oui, et c'était pas du côté des SdM... Mais en attendant, quel est le budget annuel accordé à l'informatique ? Et il y a une équipe à temps plein non ??

    (à mon épqoue, sur 15 personnes en SI, 2 étaient salariées de la banque, les autres étaient des gars de SSII (comme moi) à temps plein)


    Pour te donner une idée, dans le médical j'avais droit à 6 personnes, 1 million, et un an (le soft existant avait bénéficié de 60 personnes pendant 15 ans, et 2 millions de lignes). Dans la météo j'avais droit à 1 personne, 350 000 euros à raison de 50 000 par an, et 7 ans, mais 1 an pour la première version opérationnelle nationale (le soft existant avait bénéficié de 100 personnes pendant 10 ans, et 2 millions de lignes), et pour les aiguilleurs 6 personnes, 1 an, et 500 000 euros ((le soft existant avait bénéficié de 10 personnes pendant 30 ans, et 5 millions de lignes)....
    Tout ça confirme bien ce que nous vivons actuellement un peu partout : faire plus avec moins. Et après les gens s'étonnent que ça n emarche aps parfaitement.

    Marratn je viens de voir que mon profil est de... 666... le Chiffre de la Bête... Bon je sais hors sujet y a bien quelqu'un qui va le ramener à 665...
    "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