Discussion :

[super_bus]

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.

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.

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.

[B.AF]

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

[super_bus]

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.

[B.AF]

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.

[yan]

je ne développe pas des logiciels mais des applications.

Je n'ai pas compris ta définition de logiciels et applications...

[super_bus]

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.

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.

[zaventem]

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

[super_bus]

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é ! ! ! !

[B.AF]

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.

[gorgonite]

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é

[TropMDR]

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,

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.

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.

[Tommy31]

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.

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.

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.

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 ?

[B.AF]

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.

[yan]

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?

[el_slapper]

(.../...)
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.

[B.AF]

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.

[souviron34]

Eh bé !!

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

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

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"

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

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

[Luc Orient]

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

[TropMDR]

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é ?

[Guardian]

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 ?