Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 7 sur 16 PremièrePremière ... 34567891011 ... DernièreDernière
Affichage des résultats 121 à 140 sur 310
  1. #121
    Membre du Club
    Profil pro Joël
    Inscrit en
    janvier 2011
    Messages
    55
    Détails du profil
    Informations personnelles :
    Nom : Joël
    Âge : 55

    Informations forums :
    Inscription : janvier 2011
    Messages : 55
    Points : 56
    Points
    56

    Par défaut

    Citation Envoyé par Fabllot Voir le message
    Quelles normes ? Celles de mettre des printf ? C'est une norme ça ? Déjà pour jouer sur les mots c'est peut-être un "standard" parce-que beaucoup font comme ça, mais je considère vraiment pas cela comme une norme !
    Je vais de donner un petit exemple de norme de développement. Soit une variable entière pouvant recevoir plusieurs valeurs possible. Mais tu ne traites que pour la valeur 1 et 2. Alors tu écris le mauvais code suivant :

    Si variable = 1 alors Traiter paragraphe 1
    Sinon traiter paragraphe 2
    FinSi.

    Mais si ta variable prend la valeur 3, tu traites le paragraphe 2, ce dont tu n'aurais pas du faire.

    Voici le bon code :

    Si variable = 1 alors Traiter paragraphe 1
    Finsi

    Si variable = 2 alors traiter paragraphe 2
    Finsi

    Si (variable <> 1) et (variable <>2) alors Traiter cette anomalie
    Finsi.

    Et dans ce cas tu n'as pas besoin d'un débogueur, car ton traitement indiquera que tu es en anomalie avec la variable = 3.

    Citation Envoyé par Fabllot Voir le message
    Et puis qui t'as dit que je travaillais sans normes de méthodologies ? Mes collègues te diront que je suis certainement un des plus "chiant" sur les normes de codages et les procédures.
    Mais je vois pas là le conflit entre utiliser un débogueur et respecter des normes ?
    J'ai jamais dit ca. D'ailleurs je ne te connais pas. Je dis simplement qu'une méthodologie de développement simplifie grandement la mise au point d'un programme. Et que dans la grande majorité des cas, un débogueur ne serre à rien.

    Citation Envoyé par Fabllot Voir le message
    Ce que je dis c'est pourquoi ne pas utiliser un débogueur quand les conditions optimales de son utilisation sont réunies (qui ne sont pas les tiennes - si j'ai bien compris), alors qu'il peut-être utile et te faire gagner du temps ? Ou pourquoi creuser un (gros) trou à la petite cuillère alors que tu as une pelle ?
    Oui, je n'ai pas en gros système toutes les conditions favorables pour déboguer comme en micro. Voir VISUAL C++ avec les deux modes (débug ert release) et les outils de mises au point.

    Et donc quand on n'a pas de débogueur, comment faire ?
    Et de surcroit, puisque je n'utilise pas de débogueur, j'en arrive à la conclusion que cela ne sert à rien. Pour la simple raison que j'ai une approche plus méthodologie.

  2. #122
    Membre Expert
    Inscrit en
    février 2005
    Messages
    1 243
    Détails du profil
    Informations forums :
    Inscription : février 2005
    Messages : 1 243
    Points : 1 702
    Points
    1 702

    Par défaut

    Citation Envoyé par super_bus Voir le message
    Alors si je comprends ce que tu dis , utiliser une méthodologie est contre productive ?
    Non tu n'as pas compris. Je dis simplement qu'aujourd'hui dans l'informatique il est facile d'écrire et dire ce qu'il faudrait faire, la réalité apporte aussi son lot de contrainte.

    Croire aveuglément qu'une méthode est la bonne c'est aussi dangereux que de ne pas en avoir. Tout mérite un peu de recul.

    Trop de lumiére, ça aveugle.

    Dans la théorie, les spécificiations sont claires, justes, sans ambiguités, tous les cas d'utilisation sont identifiés, tous les aléas techniques résolus,tous les scénarios identifiés à l'avance, tous les test faits, tous les outils fiables, toutes les personnes compétentes et fiables.

    C'est la limite de l'académisme. La spécification c'est la zone grise de l'informatique depuis que ça existe, les cas de tests ne sont jamais exhaustifs, les tests et autres recettes ou itérations générent des overheads, la technique pose toujours son lot de question, les outilsont leurs limites et les gens ne sont pas tous ni du même niveau ni de la même culture.

    Ce delta, souvent négligé, fait que la seule voie de la croyance aveugle dans la méthode académique c'est la déception et les débats de machine à café "si tu avais, si j'avais, si ils avaient..." et comme partout, on finit par faire ce qu'on peut, parfois au mieux, parfois au moins disant; parce que là aussi intervient la dimension argent, qui n'est pas négligeable.

    Donc les grandes théories sur comment il faut bien faire les choses, c'est pour moi l'apanage de l'inspection des travaux finis.

    Je ne vois pas ce que ça apporte quand quelqu'un qui dit "je ne m'en sers pas à cause des contraintes locales qui rendent la chose complexe et/ou inutile" de lui répondre "Haha!!! Moi je ne connais pas tes contraintes, mais je vais t'expliquer la vie et comment tu dois faire les choses bien". C'est de la philo de BDE d'école d'ingé.

  3. #123
    Membre du Club
    Profil pro Joël
    Inscrit en
    janvier 2011
    Messages
    55
    Détails du profil
    Informations personnelles :
    Nom : Joël
    Âge : 55

    Informations forums :
    Inscription : janvier 2011
    Messages : 55
    Points : 56
    Points
    56

    Par défaut

    Je l'avoue, j'ai du mal à te comprendre.

    Tu parles du décalage qui existe entre ce que l'on devrait faire et ce que l'on peut faire ? Car en général, les spécifications sont du domaine du faisable. S'il existe un problème dans la pratique, la difficulté revient à une spécification mal posée.

    Ce que tu appelles les grandes théories sont pour moi du concret. Je n'invente rien. Je travaille comme ça depuis des années. Et je peux te confirmer que cette façon de travailler est très lourde et contraignante. Une simple correction d'une anomalie dans mon environnement de travail peut me prendre, disons dix minutes. Mais en suivant le processus de la maintenance, mis en place dans les entreprises que l'on nomme aussi grand compte, il faut parfois compté plus jours entre le moment de la récupération du source et sa mise en production. Et là, je ne fais que subir cette règle imposée par l'entreprise. Ce n'est pas moi qui décide.

  4. #124
    Membre Expert
    Inscrit en
    février 2005
    Messages
    1 243
    Détails du profil
    Informations forums :
    Inscription : février 2005
    Messages : 1 243
    Points : 1 702
    Points
    1 702

    Par défaut

    Citation Envoyé par super_bus Voir le message
    Je l'avoue, j'ai du mal à te comprendre.

    .
    Non en fait dans ton explication tu es parfaitement d'accord avec moi, sauf que tu t'acharnes tellement à prouver l'exception stratégique et vitale qu'est ton cas que tu ne lis les posts qu'en te disant qu'on va contre toi.

  5. #125
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro yan verdavaine
    Ingénieur expert
    Inscrit en
    mars 2004
    Messages
    9 958
    Détails du profil
    Informations personnelles :
    Nom : Homme yan verdavaine
    Âge : 32
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2004
    Messages : 9 958
    Points : 12 417
    Points
    12 417

    Par défaut

    Citation Envoyé par super_bus Voir le message
    je ne développe pas des logiciels mais des applications.
    Je n'ai pas compris ta définition de logiciels et applications...
    Développeur Windows 8, Windows phone 8 et Nokia Asha, inscrivez vous sur DVLUP

  6. #126
    Membre du Club
    Profil pro Joël
    Inscrit en
    janvier 2011
    Messages
    55
    Détails du profil
    Informations personnelles :
    Nom : Joël
    Âge : 55

    Informations forums :
    Inscription : janvier 2011
    Messages : 55
    Points : 56
    Points
    56

    Par défaut

    Citation Envoyé par B.AF Voir le message
    Non en fait dans ton explication tu es parfaitement d'accord avec moi, sauf que tu t'acharnes tellement à prouver l'exception stratégique et vitale qu'est ton cas que tu ne lis les posts qu'en te disant qu'on va contre toi.
    Je crois que tu m'as bien cerner ! Mea culpa ! Désolé, je ne savais que cela était aussi évident.

    Citation Envoyé par yan Voir le message
    Je n'ai pas compris ta définition de logiciels et applications...
    Un logiciel est un produit commercial que tu ne peux pas modifier. Par contre, tu es maitre de ton application puisque c'est toi qui l'écrit, et tu peux en faire ce que tu veux. En gros tu as toutes les libertés sur une application et aucune sur un logiciel.

  7. #127
    Membre Expert Avatar de zaventem
    Profil pro Cédric
    Inscrit en
    février 2003
    Messages
    371
    Détails du profil
    Informations personnelles :
    Nom : Cédric
    Âge : 33
    Localisation : Belgique

    Informations forums :
    Inscription : février 2003
    Messages : 371
    Points : 1 350
    Points
    1 350

    Par défaut

    Citation Envoyé par super_bus Voir le message
    Mathématiquement prouvé ne veut rien dire. Un programme fonctionne ou ne fonctionne pas. Faite des tests grandeur nature et là vous serez capable de dire si il est bogué ou pas.
    Si tu mettais un instant ta suffisance de coté et que tu t'intéressais un peu à ce qui existe en dehors de ton monde, cela t'éviterais de dire n'importe quoi

    Il est tout à fait possible de prouver qu'un programme fait rigoureusement et dans tous les cas ce qui est défini au niveau du cahier des charges. Certes c'est très lourd et très couteux et c'est donc employé dans des cas rares mais cela existe. Allez, je te mets sur la piste : les méthodes formelles

  8. #128
    Membre du Club
    Profil pro Joël
    Inscrit en
    janvier 2011
    Messages
    55
    Détails du profil
    Informations personnelles :
    Nom : Joël
    Âge : 55

    Informations forums :
    Inscription : janvier 2011
    Messages : 55
    Points : 56
    Points
    56

    Par défaut

    Les méthodes formelles appartiennent à la logique formelle et ce traite dans des problèmes d'intelligence artificielle. Tu trouves ca dans les chapitres consacrés au calcul des prédicats. Par simplification, il s'agit de la résolution par réfutation de la décomposition de problème mathématique.

    Le génie logiciel est une application de la logique formelle. J'ai suivi, il y a déjà très longtemps en école d'ingénieur des cours de logique formelle avec des exercices en langage PROLOG.

    Mais ce dont tu me parles n'a rien avoir avec l'informatique de gestion. Il s'agit de mathématique.

    De plus, un programme bogué ne peut pas être détecté s'il ne s'était pas planté au préalable. Et c'est le rôle des tests dans les environnements de recettage.

    De plus, les applications du génie logiciel concerne l'écriture d'un programme sans bogue. Et dans le jargon des informaticiens, on appelle ca une méthodologie de développement.

    Donc avant de me traiter de suffisant, renseigne toi. Au lieu de me sortir une connerie sur un sujet, qui de toute évidence, tu ne dois pas connaitre sinon pour m'en mettre plein la vue et me faire taire. C'est raté ! ! ! !

  9. #129
    Membre Expert
    Inscrit en
    février 2005
    Messages
    1 243
    Détails du profil
    Informations forums :
    Inscription : février 2005
    Messages : 1 243
    Points : 1 702
    Points
    1 702

    Par défaut

    Citation Envoyé par TropMDR Voir le message
    Bonjour, j'ai deux listes de chaines de caractères. Je voudrais savoir si en répétant des chaines de la premières liste (autant de fois qu'on veut, et dans n'importe quel ordre), on peut obtenir la même chaine de caractère qu'en répétant les chaines de la deuxième liste. C'est du domaine du faisable ?

    C'est complêtement puéril et inutile cet échange.

    En venir à s'insulter pour des méthodes de travail différentes, tu peux parler de méthodes formelles, on peut aussi partir dans le numérique; n'en reste pas moins que ça ne volera jamais très haut vu le fond de la discussion.

    Bref, good luck, fin de sujet pour moi.

  10. #130
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro Nicolas Vallée
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 194
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Vallée
    Âge : 29
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 194
    Points : 16 749
    Points
    16 749

    Par défaut

    il est grand temps de calmer un peu ce sujet...
    autant confronter des avis divergents est autorisé, autant transformer une discussion (*) en pugilat est totalement stérile... et va finir par bouffer un max de temps aux modos pour rendre le sujet présentable (ce qui vexera certaines personnes car leurs arguments noyés au milieu d'attaques personnelles seront virés... et ils prendront la mouche en fermant leur compte )



    (*) je l'admets, elle était tellement "bien" posée initialement qu'elle est vouée à troller, donc à faire de nombreuses lectures/posts, donc à faire croire que la news est de qualité
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  11. #131
    Membre chevronné
    Inscrit en
    mars 2010
    Messages
    308
    Détails du profil
    Informations forums :
    Inscription : mars 2010
    Messages : 308
    Points : 793
    Points
    793

    Par défaut

    Citation Envoyé par super_bus Voir le message
    Les méthodes formelles appartiennent à la logique formelle et ce traite dans des problèmes d'intelligence artificielle.
    Ce sont deux mondes complètement à part, même s'il est envisageable d'appliquer des méthodes formelles à des problèmes d'intelligence artificielle. Par exemple si on considère que piloter automatiquement un métro, c'est un problème d'intelligence artificielle, alors oui, la méthode B (méthode formelle par raffinement) a bien été appliqué dans ce domaine (métro 14). Mais elles sont aussi appliqué pour s'assurer de l'absence de plantage du code des commandes dans les avions, ou sur des codes cryptographique, etc etc.

    C'est méthode permettent effectivement d'éviter très largement de recourir à un débogueur, puisqu'elles assurent statiquement (sans avoir à lancer le programme) qu'on s'est débarrassé de toute une classe de bugs (par exemple dépassement de bornes dans un tableau), voir même plus précisément dans certain cas, que le programme satisfait ses spécification à 100%. Donc elles permettent aussi de trouver des bugs dans les programmes *avant* de les exécuter.

    Mais, comme le dit wikipedia,
    Citation Envoyé par wikipedia
    Cependant, elles sont généralement coûteuses en ressources (humaines et matérielles) et actuellement réservées aux logiciels les plus critiques.
    Il est donc effectivement peu probable qu'on les retrouve d'ici peu dans l'informatique de gestion. Mais ce n'est pas une séparation intrinsèque.

    Citation Envoyé par super_bus Voir le message
    Le génie logiciel est une application de la logique formelle.
    Je dirais plutôt que les méthodes formelle sont une forme très poussée de génie logiciel.

  12. #132
    Membre Expert

    Homme Profil pro Chris Camel
    Architecte de système d'information
    Inscrit en
    novembre 2006
    Messages
    1 245
    Détails du profil
    Informations personnelles :
    Nom : Homme Chris Camel
    Âge : 39
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : novembre 2006
    Messages : 1 245
    Points : 1 650
    Points
    1 650

    Par défaut

    Citation Envoyé par super_bus Voir le message
    Les méthodes formelles appartiennent à la logique formelle et ce traite dans des problèmes d'intelligence artificielle.
    Tu trouves ca dans les chapitres consacrés au calcul des prédicats.
    Tu confonds beaucoup de choses, c'est dommage dans un forum de professionnels.

    Les méthodes formelles sont un cadre qui permettent d'exprimer des choses et de raisonner dessus. Dire qu'elles appartiennent à la logique formelle est un non sens. Il est plus correct de dire qu'elle s'appuient sur des logiques formelles pour cela, en tant que support.

    En outre, ces logiques ne se limitent pas aux prédicats. Les logiques peuvent être modales (épistémiques, déontiques ou temporelles par exemple) selon la nature du domaine dénoté.

    Rien à voir avec l'intelligence artificielle, qui peut recourir à des logiques pour l'édification d'un système formel et bénéficier ainsi de l'inférence pour la déduction (on parlera alors d'un système expert), mais ce n'est pas la seule voie. Les algorithmes évolutionnistes, réseaux de neurones, et bien d'autres choses encore sont autant d'autres volets de ce que couvre l'intelligence artificielle.

    Citation Envoyé par super_bus Voir le message
    Le génie logiciel est une application de la logique formelle. J'ai suivi, il y a déjà très longtemps en école d'ingénieur des cours de logique formelle avec des exercices en langage PROLOG.
    Rien à voir. Le génie logiciel est "une science de génie industriel qui étudie les méthodes de travail et les bonnes pratiques des ingénieurs qui développent des logiciels" (cf wikipédia). Les logiques formelles sont un outil possible mais loin d'être le seul ni le plus usité. UML par exemple en est un autre, et si on peut le qualifier de formel (syntaxe et sémantique bien définie), ce n'est pas une logique formelle.

    Citation Envoyé par super_bus Voir le message
    Mais ce dont tu me parles n'a rien avoir avec l'informatique de gestion. Il s'agit de mathématique.
    Pourtant il est tout à fait possible de spécifier une application de gestion à l'aide d'une logique formelle. Les méthodes formelles peuvent adresser tout domaine.

    Citation Envoyé par super_bus Voir le message
    De plus, un programme bogué ne peut pas être détecté s'il ne s'était pas planté au préalable. Et c'est le rôle des tests dans les environnements de recettage.
    Pourtant c'est ce que font les assistants de preuves, type Coq http://fr.wikipedia.org/wiki/Coq_(logiciel).

    En outre par les tests fonctionnels tu te heurtes vite au problème d'exhaustivité et de couverture. Comment garantir que tes tests couvrent tous les chemins du programme ?

  13. #133
    Membre Expert
    Inscrit en
    février 2005
    Messages
    1 243
    Détails du profil
    Informations forums :
    Inscription : février 2005
    Messages : 1 243
    Points : 1 702
    Points
    1 702

    Par défaut

    C'est un grand mélange de tout.

    On peut faire une application dont la logique fonctionnelle est implacable et incassable mais dont l'implémentation technique est fautive, vice et versa, où dont les composants sont défaillants dans le temps.

    Dans sa globalité, sur un système de grande taille et critique / haute disponibilité, les facteurs de risques sont multiples, et il ne peut exister une méthode unique et une pratique unique de la qualité.

    Dans tout cela, le debugger n'est qu'un élément de productivité dans une technologie et dans un composant logiciel isolé.

    C'est un grand ensemble dans lequel tous les corps de métier ont leur mot à dire. Typiquement un sujet peu résolu ou mal résolu : les tests de données dans les SGBD. Même ici ce fut une foire d'empoigne.

    Le développement c'est une logique fractalienne. Chaque élément de la chaine se comporte en fonction des éléments dont il dépend et de son propre aléa.

  14. #134
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro yan verdavaine
    Ingénieur expert
    Inscrit en
    mars 2004
    Messages
    9 958
    Détails du profil
    Informations personnelles :
    Nom : Homme yan verdavaine
    Âge : 32
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2004
    Messages : 9 958
    Points : 12 417
    Points
    12 417

    Par défaut

    Citation Envoyé par super_bus Voir le message
    De plus, un programme bogué ne peut pas être détecté s'il ne s'était pas planté au préalable.

    Pour toi bug == plantage?
    Développeur Windows 8, Windows phone 8 et Nokia Asha, inscrivez vous sur DVLUP

  15. #135
    Expert Confirmé Sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    3 132
    Détails du profil
    Informations personnelles :
    Localisation : France, Val d'Oise (Île de France)

    Informations forums :
    Inscription : décembre 2007
    Messages : 3 132
    Points : 9 105
    Points
    9 105

    Par défaut

    Citation Envoyé par B.AF Voir le message
    (.../...)
    C'est la limite de l'académisme. La spécification c'est la zone grise de l'informatique depuis que ça existe, les cas de tests ne sont jamais exhaustifs, les tests et autres recettes ou itérations générent des overheads, la technique pose toujours son lot de question, les outils ont leurs limites et les gens ne sont pas tous ni du même niveau ni de la même culture.(.../...)
    Je suis globalement d'accord avec toi, mais je ne suis pas sur de ce que tu appelles l'overhead. Si c'est une fuite de mémoire, alors en COBOL, c'est impossible. Ce qui pose pas mal de problème pour résoudre certains petits trucs, car on a pas d'allocation dynamique de mémoire, pas de collections, toute la mémoire est assignée dès la compilation. Interdit d'en sortir.

    ça rend certaines choses plus longues à coder. Ca rend aussi les machines beaucoup plus fiables, puisqu'un programmeur crade(nous en avons aussi, hélas) ne pourra jamais priver de RAM les programmes de ses petits camarades. Je ne suis pas d'accord avec superbus pour dire que les programmeurs sont plus propres en grand système. Mais ils ont beaucoup moins de moyens de pourrir la vie de leurs collègues. D'ou la propreté des grands systèmes. Et aussi la haine qu'ils inspirent aux programmeurs habitués à la liberté des langages "modernes". Parceque la liberté de pourrir le voisin est parfois tellement utile...

    Là, je reçois des fichiers non controlés, je dois faire des agrégats sur des clefs et des contrôles, et je dois dimensionner des tables internes pour gérer ça. Je dimensionne "au pif", en me basant sur des volumétries témoin. Et je plante le programme si j'ai sous-dimensionné, en laissant une erreur claire et lisible. C'est beaucoup de boulot par rapport à une bête collection, il faut gérer la taille, la taille max, les limites, ça ajoute plusieurs heures de boulot. Mais jamais, au grand jamais, ça ne bouffera la mémoire du voisin. Car même si j'ai oublié de gérer le cas ou je dépasse la taille max, le programme va planter. Sans dépasser d'un octet. Et en étant compliqué à débogger - puisqu'on ne sait pas ce qu'on cherche, et qu'on a oublié de coder un traitement de la limite. Et si j'ai bien fait mon boulot, la log me dira "table interne TAB-AFF en dépassement de capacité, maximum 99, besoin 312". auquel cas on augmente(par exemple à 500), et on relance.

    Ca, plus le très haut niveau de sécurité intrinsèque, rend les grands systèmes très attractifs pour les très grosses organisations, genre banque. Malgré leurs défauts évidents.

  16. #136
    Membre Expert
    Inscrit en
    février 2005
    Messages
    1 243
    Détails du profil
    Informations forums :
    Inscription : février 2005
    Messages : 1 243
    Points : 1 702
    Points
    1 702

    Par défaut

    L'overhead pour moi, c'est la charge (coût et temps) qu'on minore systèmatiquement parce que la théorie dit que tout doit aller pour le mieux dans le meilleur des mondes.

    En gros ceux qui pensent que tous les risques sont anticipables, les disciples de la distribution de Taleb.

    C'est à dire que les théoriciens passent leur temps à faire des gains faible de qualité sur des évidences avec des théories pompeuses et considére que tout risque qu'ils n'ont pas considéré est improbable. Sauf que les vrais risques, ce ne sont pas ceux que la méthode explique, ce sont ceux du contexte que seul l'expérience connait.
    Et ceux là, quand on les prend, on le paye beaucoup plus cher que les risques triviaux que l'on a voulu couvrir académiquement.

    Et c'est un cas commun à énormément de secteurs.

  17. #137
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 173
    Détails du profil
    Informations personnelles :
    Âge : 56

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 173
    Points : 12 816
    Points
    12 816

    Par défaut

    Eh bé !!

    Je pars 4 jours et sur un sujet comme ça je retrouve 4 pages de discussions enflammées !!


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

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



    Citation Envoyé par super_bus Voir le message
    Alors si je comprends ce que tu dis , utiliser une méthodologie est contre productive ?
    Moi je maintiens dans certains cas, oui... ça dpend de ce qu'on sous-tend par "méthodologie"




    Citation Envoyé par B.AF Voir le message
    Non tu n'as pas compris. Je dis simplement qu'aujourd'hui dans l'informatique il est facile d'écrire et dire ce qu'il faudrait faire, la réalité apporte aussi son lot de contrainte.

    Croire aveuglément qu'une méthode est la bonne c'est aussi dangereux que de ne pas en avoir. Tout mérite un peu de recul.

    Trop de lumiére, ça aveugle.
    re+1000 ...


    Citation Envoyé par super_bus Voir le message
    Je l'avoue, j'ai du mal à te comprendre.

    Tu parles du décalage qui existe entre ce que l'on devrait faire et ce que l'on peut faire ? Car en général, les spécifications sont du domaine du faisable. S'il existe un problème dans la pratique, la difficulté revient à une spécification mal posée.


    Ah bon ?

    • ça ne peut pas être parce que à la réalisation on se rend compte que l'algo ne sort pas ce qu'il aurait dû ?

    • ça ne peut pas être parce que entre le moment où on a fait la spec et le moment où on code, un nouveau truc est sorti qui élimine une partie ? (ou carrément remplace 50% de la fonctionalité) ??

    • ça ne peut pas être parce que quelqu'un, quelque part, a décidé de changer de paradigme, de langage ? (par exemple quelqu'un du marketing ou le nouveau Directeur Info..)

    • ça ne peut pas être parce qu'il y a un nouveau besoin, non existant au moment de la spec, mais qui, gràce à ce que fournit le logiciel, devient un besoin à remplir ?

    • ça ne peut pas être parce que la(les) règle(s) de base a (ont été) modifé(es), éventuellement par des organismes sur lesquels l'équipe (ou même la boîte) n'a aucun poids ???



    Entre illuson sur l'implémentation, nouveauté technologique, effets de mode et de position concurentielle, ou modification du besoin / des contraintes, tout un tas de possibilités existent...
    "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. #138
    Membre Expert

    Homme Profil pro François Durand
    Spécialiste Delivery Mainframe IBM
    Inscrit en
    octobre 2005
    Messages
    1 219
    Détails du profil
    Informations personnelles :
    Nom : Homme François Durand
    Âge : 55
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Spécialiste Delivery Mainframe IBM
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 219
    Points : 2 079
    Points
    2 079

    Par défaut

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

    Un exemple de débogueur en Grands systèmes IBM :
    COMPUWARE - Xpediter

  19. #139
    Membre chevronné
    Inscrit en
    mars 2010
    Messages
    308
    Détails du profil
    Informations forums :
    Inscription : mars 2010
    Messages : 308
    Points : 793
    Points
    793

    Par défaut

    Citation Envoyé par B.AF Voir le message
    C'est à dire que les théoriciens passent leur temps à faire des gains faible de qualité sur des évidences avec des théories pompeuses et considére que tout risque qu'ils n'ont pas considéré est improbable.
    C'est assez triste de voir un tel mépris pour le monde académique :-\ Tu suggères donc de rejeter tout ce qui vient de ce monde, sous prétexte que ce n'est forcément que pompeux ? Ce n'est pas un peu réducteur tu penses ? Et peut être que ce n'est pas parce qu'une méthode ne garantie pas 100% de sécurité qu'elle est forcément à jeter, non ? Et à quel point es-tu au fait de ces méthodes ? De coq à frama-C, en passant par la méthode B, lesquelles as-tu regardé ?

  20. #140
    Membre Expert Avatar de Guardian
    Inscrit en
    mars 2009
    Messages
    820
    Détails du profil
    Informations forums :
    Inscription : mars 2009
    Messages : 820
    Points : 1 520
    Points
    1 520

    Par défaut

    Citation Envoyé par Luc Orient Voir le message
    Citation Envoyé par super_bus Voir le message
    Je précise encore une fois qu'en gros système nous n'avons pas de débogueur. Alors nous avons notre expérience et le système D.
    Faux.

    Un exemple de débogueur en Grands systèmes IBM :
    COMPUWARE - Xpediter
    Faut voir...
    Ce n'est faux que si sa phrase signifie "il n'existe pas de ..." mais elle est incontestable, sauf par quelqu'un qui connaît son entreprise, si elle signifie "nous ne possédons pas de ...".
    Je t'accorde qu'il faut probablement comprendre le premier sens mais... qui sait ?

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •