Discussion :

[Marco46]

La seule spécificité du COBOL dans ce cas, c'est son âge canonique. D'ici une vingtaine d'années, tous vos langages de jeunots seront soumis aux mêmes contraintes, pour les mêmes raisons.

Pas vraiment, il y a aussi l'amateurisme des personnes qui ont écrit les premiers codes qui n'a peut-être que peu évolué.

Depuis quelques années on a eu les design patterns, le TDD, l'Agile, les pratiques devops, etc .... Qui nous amènent doucement vers une professionnalisation de notre métier dont l'industrie et en particulier ses décideurs sont très immatures pour ne pas dire incompétents.

Tout ca pour dire que si vous pensez que votre expérience est universelle et reproductible pour les nouvelles générations vous vous trompez lourdement.

[el_slapper]

Pas vraiment, il y a aussi l'amateurisme des personnes qui ont écrit les premiers codes qui n'a peut-être que peu évolué.

Amateurisme, oui. Tout restait à inventer. Maintenant, est-ce que tous les petits jeunes font du code impeccable? Ce 'est pas mon impression.

Quand à "peu évolué", je ne suis pas sur de quoi tu parle, mais le code en question, est passé, chaque année pendant plus de trente ans, entre eu moins un dizaines de mains différentes, pour des modifications à tout va.

Depuis quelques années on a eu les design patterns, le TDD, l'Agile, les pratiques devops, etc .... Qui nous amènent doucement vers une professionnalisation de notre métier dont l'industrie et en particulier ses décideurs sont très immatures pour ne pas dire incompétents.

Outre la dichotomie programmeur = bon, décideur = méchant qui me parait sujette à caution(euphémisme), l'ampleur des projets moderne est bien plus grande que les bêtes chaines comptables avec quelques saisies transactionelles des années 70. Les outils dont tu parles sont de très bonnes choses, mais pour moi le problème n'a pas changé. LEs outils permettent de faire plus, alors on fait plus. Et, comme dans le temps, on ne s'arrête qu'aux frontières du supportable. Cette frontière a reculé, on est d'accord. Mais elle existe toujours, et tout le monde joue avec.

Évidemment, les détails seront différents. Mais tu crois qu'une boite qui se fait racheter trois fois en trente ans aura encore de la doc? Du code béton suivant toutes les normes?

Tout ca pour dire que si vous pensez que votre expérience est universelle et reproductible pour les nouvelles générations vous vous trompez lourdement.

Pas telle quelle, évidemment. Mais encore une fois, mon propos à ce sujet, c'était de dire que plus un code est vieux, et plus il est isolé par l'histoire de la boite qui tourne autour. Au début, il y a des specs, des dessins de chaine ou de base, tout un tas de trucs qui vont avec. Petit à petit, les gens sont mutés, les prestataires partent, la boite est rachetée, des serveurs sont perdus, les nouveaux ne savent même pas ou sont les docs, et on se retrouve avec le code. Seulement le code. Et c'est donc lui, et lui seul qui fait foi.

Alors évidemment, certains langages presque modernes permettent de faire de la doc à partir du code. C'est bien. C'est d'autant mieux que quand tout le reste à disparu, c'est tout ce qui reste. Et oui, c'est un progrès par rapport aux temps héroiques dont nous parlons. Mais ce PL/SQL n'est pas si vieux, et il n'est pas conçu pour être relu, de toute évidence. Et c'est tout ce qu'on a.

[Matthieu Vergne]

Ben quand même si le code n'implémente pas les règles décrites par le métier ...

Les specs sont indispensables. Le code tout seul ne permet pas de vérifier que l'algo est correctement implémenté ni qui les tests sont pertinents.

Effectivement, ce que le système est censé faire est important, car s'il ne le fait pas le système doit être modifié. Mais ce discours n'est valable que pour celui qui maintient le code. Ici, on est dans une optique de revue de code (i.e comprendre le code). S'il est effectivement possible de suggérer des améliorations, l'objectif premier ici est l'étude du code dans un but de compréhension, et non son amélioration (c'est le ministère qui en a la charge). C'est pourquoi ce besoin du cahier des charges devient secondaire.

Dans un autre contexte, tu aurais eu raison, mais ce n'est pas le cas ici.

[Marco46]

Amateurisme, oui. Tout restait à inventer. Maintenant, est-ce que tous les petits jeunes font du code impeccable? Ce 'est pas mon impression.

Je parlais des pratiques, elles n'existaient pas il y a 20 ans.

Est-ce que les jeunes font du code impeccable ? Certainement pas, mais les développeurs expérimentés n'ont plus aucune excuse de ne pas en faire, il y a tous les outils qu'il faut, toute la littérature nécessaire pour apprendre.

Quand à "peu évolué", je ne suis pas sur de quoi tu parle, mais le code en question, est passé, chaque année pendant plus de trente ans, entre eu moins un dizaines de mains différentes, pour des modifications à tout va.

Je veux dire que quand un développeur reste des décennies dans le même environnement technique, il ne progresse pas. Donc un développeur qui faisait du code dégueux il y a 20 ans et qui n'a fait aucun effort pour évoluer fera toujours du code dégueux 20 ans plus tard, probablement même pire.

L'expérience n'est pas mécaniquement un critère de qualité, c'est une condition.

Outre la dichotomie programmeur = bon, décideur = méchant qui me parait sujette à caution(euphémisme),

Je veux dire que la plupart des décideurs sont dangereux pour leurs propres projets parce qu'ils ne comprennent pas les impacts de leurs décisions de management parce qu'ils n'ont pas la moindre notion basique de génie logiciel. Par exemple un manager qui croit pouvoir accélérer la cadence sur un projet en retard en staffant du monde dessus, ou baisser la qualité pour augmenter la vélocité. Ce sont les décisions d'un incompétent.

l'ampleur des projets moderne est bien plus grande que les bêtes chaines comptables avec quelques saisies transactionelles des années 70. Les outils dont tu parles sont de très bonnes choses, mais pour moi le problème n'a pas changé. LEs outils permettent de faire plus, alors on fait plus. Et, comme dans le temps, on ne s'arrête qu'aux frontières du supportable. Cette frontière a reculé, on est d'accord. Mais elle existe toujours, et tout le monde joue avec.

Évidemment, les détails seront différents. Mais tu crois qu'une boite qui se fait racheter trois fois en trente ans aura encore de la doc? Du code béton suivant toutes les normes?

Si à chaque étape les gens font leur travail il n'y a aucun raison de perdre quoi que ce soit.

Pas telle quelle, évidemment. Mais encore une fois, mon propos à ce sujet, c'était de dire que plus un code est vieux, et plus il est isolé par l'histoire de la boite qui tourne autour. Au début, il y a des specs, des dessins de chaine ou de base, tout un tas de trucs qui vont avec. Petit à petit, les gens sont mutés, les prestataires partent, la boite est rachetée, des serveurs sont perdus, les nouveaux ne savent même pas ou sont les docs, et on se retrouve avec le code. Seulement le code. Et c'est donc lui, et lui seul qui fait foi.

Je m'en fous des raisons.

Un code seul est un code mort.

Comment fais-tu pour savoir que tu n'as pas créé de régression en l'absence de tests automatisé ? Comment sais-tu que le programme fait toujours ce qu'il est censé faire en l'absence de specs ET de tests ?

Se servir du code seul comme base c'est comme faire un 100m haie les yeux bandés. C'est stupide et dangereux.

Sinon pour en revenir à nos moutons le ministère de l'éducation nationale n'est pas une entreprise qui a été rachetée 3 fois non ?

Alors évidemment, certains langages presque modernes permettent de faire de la doc à partir du code. C'est bien. C'est d'autant mieux que quand tout le reste à disparu, c'est tout ce qui reste. Et oui, c'est un progrès par rapport aux temps héroiques dont nous parlons. Mais ce PL/SQL n'est pas si vieux, et il n'est pas conçu pour être relu, de toute évidence. Et c'est tout ce qu'on a.

Et c'est de la merde. Et ça montre le degré d'incurie qui règne dans la réalisation du SI de l'état et ça fait chier.

[Marco46]

Effectivement, ce que le système est censé faire est important, car s'il ne le fait pas le système doit être modifié. Mais ce discours n'est valable que pour celui qui maintient le code. Ici, on est dans une optique de revue de code (i.e comprendre le code). S'il est effectivement possible de suggérer des améliorations, l'objectif premier ici est l'étude du code dans un but de compréhension, et non son amélioration (c'est le ministère qui en a la charge). C'est pourquoi ce besoin du cahier des charges devient secondaire.

Dans un autre contexte, tu aurais eu raison, mais ce n'est pas le cas ici.

Comment ça revue de code ?

Relire le code sans pouvoir l'exécuter ça n'a absolument aucun intérêt.

Pouvoir l'exécuter sans le confronter au besoin métier réel ça n'a aucun intérêt (si tu exécutes un soft qui ne fait ce qu'il est censé faire quel intérêt ?)

L'intérêt de l'opendata c'est de permettre au public et aux entrepreneurs de pouvoir bâtir des services autour.

[Matthieu Vergne]

Comment ça revue de code ?

Relire le code sans pouvoir l'exécuter ça n'a absolument aucun intérêt.

Pouvoir l'exécuter sans le confronter au besoin métier réel ça n'a aucun intérêt (si tu exécutes un soft qui ne fait ce qu'il est censé faire quel intérêt ?)

L'intérêt de l'opendata c'est de permettre au public et aux entrepreneurs de pouvoir bâtir des services autour.

Encore une fois, ton problème est que tu te focalises sur un type de travail (une perspective, un besoin, une façon de faire) spécifique alors que ce n'est pas le seul possible, et en l'occurrence pas celui qui nous intéresse ici.

Certes, pouvoir exécuter le code est un atout, mais en rien une nécessité. Ce n'est pas parce qu'on es incapable de le lancer qu'on es incapable de l'analyser. Dire cela c'est mettre au rabais l'expertise humaine. N'oublies pas que le code est écrit par un humain. De toute évidence cela ne pourrait pas se faire si le code en lui-même ne pouvais pas être compris autrement que par son exécution. Par expérience, je n'ai pas besoin d'exécuter un code Java pour me rendre compte qu'un code est mal écrit et pour y trouver des fautes. Je participe a quelques projets open source et rien que de lire les commits me permet en général de déceler des erreurs ou des défauts qu'on aurait difficilement vu a l'exécution (par manque de tests). Quand tu n'a ni tests ni environnement d'exécution, et bien tu fais sans, tout simplement. Dans le cadre de la recherche, analyser un code à la main est un requis, car son exécution ne raconte pas tout. Et c'est bien un contexte de recherche qu'on vise ici : les demandeurs veulent connaître la formule, et non pas exécuter le programme chez eux.

Bref, arrête de penser qu'il n'y a qu'une seule bonne façon de faire ou d'interpréter les choses. Tu t'enlèves plus d'éléments de compréhension que tu ne t'en rajoutes.

[Luckyluke34]

Vous me faites bien rigoler les jeunots ! J'ai dû maintenir de code COBOL écrit par des brontosaures sans aucune formation informatique, ni aucun intérêt autre que financier à la chose. Des dizaines de milliers de lignes, sans aucun commentaire, avec des noms de variables type A1, TT... des Goto, des étiquettes genre "Premier", "Deux" etc.
Ca a été la pire période de ma carrière, mais la plus formative aussi. Et ça donne l'occasion de voir ce dont les utilisateurs ont vraiment besoin, pour pouvoir réécrire quelque chose de correct ensuite.
Mais c'était une période héroïque, qui demandait avant tout du talent et la volonté de faire. Aujourd'hui, on vous voit arriver avec vos peaux d'ânes toute fraîches, fringants et prêts à fiche par terre tout ce qui existe.

Bref, continuons à faire faire de la bouse par des gens pas formés en compliquant inutilement la vie de ceux qui vont maintenir le code, parce que "c'est formateur" ?

[Grogro]

La seule spécificité du COBOL dans ce cas, c'est son âge canonique. D'ici une vingtaine d'années, tous vos langages de jeunots seront soumis aux mêmes contraintes, pour les mêmes raisons.

Tu penses que nos langages à la mode vivront aussi longtemps que le vénérable COBOL ? Dans 25 ans, on fera toujours du java, du c#, du php ?

Le COBOL ça parait immortel ce langage. Il nous enterrera tous.

[Luckyluke34]

...

Encore une fois, ton problème est que tu te focalises sur un type de travail (une perspective, un besoin, une façon de faire) spécifique alors que ce n'est pas le seul possible, et en l'occurrence pas celui qui nous intéresse ici.

Certes, pouvoir exécuter le code est un atout, mais en rien une nécessité. Ce n'est pas parce qu'on es incapable de le lancer qu'on es incapable de l'analyser. Dire cela c'est mettre au rabais l'expertise humaine. N'oublies pas que le code est écrit par un humain. De toute évidence cela ne pourrait pas se faire si le code en lui-même ne pouvais pas être compris autrement que par son exécution. Par expérience, je n'ai pas besoin d'exécuter un code Java pour me rendre compte qu'un code est mal écrit et pour y trouver des fautes. Je participe a quelques projets open source et rien que de lire les commits me permet en général de déceler des erreurs ou des défauts qu'on aurait difficilement vu a l'exécution (par manque de tests). Quand tu n'a ni tests ni environnement d'exécution, et bien tu fais sans, tout simplement. Dans le cadre de la recherche, analyser un code à la main est un requis, car son exécution ne raconte pas tout. Et c'est bien un contexte de recherche qu'on vise ici : les demandeurs veulent connaître la formule, et non pas exécuter le programme chez eux.

Pour réconcilier les deux points de vue, il existe aussi des techniques pour explorer de manière automatisée le comportement d'une application. Property based testing permet, par exemple, de formuler des théories sur celle-ci et de les vérifier en la bombardant de valeurs en entrée et en vérifiant les sorties.

J'aurais tendance à partir là-dessus en posant des théories par rapport au contexte comme les noms des variables, des tables, etc (qui sont quand même bien pourris) et à ce qu'on connait déjà sur l'algo.

[Grogro]

Pour réconcilier les deux points de vue, il existe aussi des techniques pour explorer de manière automatisée le comportement d'une application. Property based testing permet, par exemple, de formuler des théories sur celle-ci et de les vérifier en la bombardant de valeurs en entrée et en vérifiant les sorties.

J'aurais tendance à partir là-dessus en posant des théories par rapport au contexte comme les noms des variables, des tables, etc (qui sont quand même bien pourris) et à ce qu'on connait déjà sur l'algo.

Ca m'intéresse beaucoup. Peux-tu nous en dire plus ?

[Luckyluke34]

Ca m'intéresse beaucoup. Peux-tu nous en dire plus ?

Le standard c'est QuickCheck en Haskell mais ça a été porté vers plein d'autres langages fonctionnels comme FsCheck en F#. En cherchant bien, on doit pouvoir trouver des bibliothèques *Check pour des langages OO style Java.

En gros, tu poses tes théorèmes - les propriétés de ton algo que tu souhaites tester. Ca pourrait être (je dis n'importe quoi) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Sur une formation post-bac donnée, un élève ne peut pas avoir un rang plus bas que le nombre total d'élèves qui candidatent.

Sur une formation post-bac donnée, deux élèves ne peuvent pas avoir le même rang.

Un élève a forcément une réponse positive à au moins deux formations post-bac.

Concrètement, dans le code, ça donne des fonctions qui prennent en paramètre toutes les données d'entrée nécessaires à ton algo. Dans le corps de la fonction, il y a une assertion (la propriété) qui renvoie un booléen, un peu comme dans un test unitaire traditionnel. L'assertion contient un appel de l'algo.

QuickCheck va :

• Lancer le test un nombre arbitrairement élevé de fois en balançant des données aléatoires en input

• Lorsqu'il trouve des données pour lesquelles le théorème ne tient pas (ton assertion est fausse), te les afficher

• Faire un shrink sur ces cas d'échec, c'est à dire chercher à trouver la plus petite donnée d'entrée qui pète quand même le théorème. La notion de plus petite est définie par type de donnée : par exemple, une liste à 1 élément est plus petite qu'une liste à deux éléments, etc. Tu peux définir tes propres shrinkers pour test types à toi.

De base, des générateurs aléatoires pour pas mal de trucs (scalaires, listes) sont fournis mais tu peux définir les tiens.

[Matthieu Vergne]

Pour réconcilier les deux points de vue, il existe aussi des techniques pour explorer de manière automatisée le comportement d'une application. Property based testing permet, par exemple, de formuler des théories sur celle-ci et de les vérifier en la bombardant de valeurs en entrée et en vérifiant les sorties.

J'aurais tendance à partir là-dessus en posant des théories par rapport au contexte comme les noms des variables, des tables, etc (qui sont quand même bien pourris) et à ce qu'on connait déjà sur l'algo.

Oui mais là encore, ça s'appuie sur l'exécution. Si tu peux pas exécuter ton code, comme c'est le cas ici, tu ne peux faire aucun test automatique. Donc tes property faudra les chercher à la main en analysant la syntaxe du code. Éventuellement tu peux faire de l'analyse statique, ça au moins ça demande juste d'avoir le code, pas de l'exécuter.

[Luckyluke34]

Si tu peux pas exécuter ton code, comme c'est le cas ici

Pourquoi on ne pourrait pas ? Il y a même quelqu'un qui a fait un simulateur en Python.

Donc tes property faudra les chercher à la main en analysant la syntaxe du code.

Oui, c'est ce que je voulais dire par "poser des théories par rapport au contexte". Il faut un minimum de lecture du code pour partir avec des property qui ne sont pas trop déconnantes.

Mais si tu te bases entièrement sur la lecture du code pour déterminer des règles fonctionnelles sans te laisser la possibilité de l'exécuter pour vérifier tes hypothèses, c'est quand même assez casse-gueule.

[Matthieu Vergne]

Pourquoi on ne pourrait pas ? Il y a même quelqu'un qui a fait un simulateur en Python.

Dans l'absolu, tu peux toujours exécuter si tu rajoute tout ce qui manque par toi-même. Mais cela demande un investissement et ne correspond pas forcément à ce qui se fait réellement. Le code n'a pas été fourni pour être exécuté, c'est un fait, et c'est sur cette base que je prend la perspective d'un code "non exécutable". Faut pas oublier que mon propos est que ce n'est pas parce qu'on ne peut pas l'exécuter qu'on ne peut rien en faire.

Oui, c'est ce que je voulais dire par "poser des théories par rapport au contexte". Il faut un minimum de lecture du code pour partir avec des property qui ne sont pas trop déconnantes.

Mais si tu te bases entièrement sur la lecture du code pour déterminer des règles fonctionnelles sans te laisser la possibilité de l'exécuter pour vérifier tes hypothèses, c'est quand même assez casse-gueule.

Je ne dis pas le contraire, mais les analyses statiques et dynamiques sont complémentaires, y'en a pas une meilleure que l'autre. Les deux sont importants. L'exécution n'apporte pas tout.

[TJ1985]

Le sujet était assez simple : Nous voulons comprendre comment est faite la répartition des postulants à certaines formations en fonction de leurs souhaits, des places disponibles et des résultats qu'ils ont obtenu aux examens qu'ils ont passé.
La formulation a été faite par des gens qui n'y connaissent rien, et qui ont donc demandé le code source de l'algorithme chargé du boulot. Chacun de nous je pense sera d'accord que ça ne veut rien dire et qu'il faut avoir du temps à perdre pour partir du code pour remonter aux règles, surtout si on ne dispose pas du modèle.
Nous pouvons donc considérer que :
- La question est posée par des gens incompétents.
- Ils se sont fait rouler dans la farine.
- Le sujet doit être assez chaud chez les gens en charge de "l'algorithme".
- Si il n'y avait pas de loup, tout ça serait sans problème sur la place publique.
Après cela, il serait bon de se demander ce qu'on veut vraiment, soit comprendre ces bouts de code indigestes, soit comprendre ce qu'on a voulu implémenter. Je penche pour la deuxième proposition, car à partir de là nous pouvons toujours nous construire une solution propre, avec son jeu de test, et la proposer à froid.

En conclusion : Il semble que les gens en charge de l'informatique dans certaines instances officielles doit être une sacrée chasse gardée - et potentiellement une sacrée pétaudière - pour qu'il soit impossible d'obtenir une réponse sensée à une question sommes-toutes très simple.
Vous n'êtes pas d'accord ?

[Luckyluke34]

Après cela, il serait bon de se demander ce qu'on veut vraiment, soit comprendre ces bouts de code indigestes, soit comprendre ce qu'on a voulu implémenter. Je penche pour la deuxième proposition, car à partir de là nous pouvons toujours nous construire une solution propre, avec son jeu de test, et la proposer à froid.

Du coup, on fait comment ? On fait confiance à l'administration pour produire une description en français de "ce qu'on a voulu implémenter" qui 1/ soit intelligible et 2/ corresponde vraiment à ce que fait l'algo ? C'est bien parce qu'on a des doutes sur sa capacité de fournir l'un et l'autre que le code source a été demandé. Retour à la case départ.

De plus, peut-être que les demandeurs seraient intéressés par un recensement de bugs ou de propriétés peu évidentes de l'algo qui vont ajouter de l'eau à leur moulin. Ce genre de trucs se détecte rarement juste "en comprenant ce qu'on a voulu implémenter". Il faut faire tourner la fonction.

[danyclassique]

Je pense a mon humble avis, qu'il y a une grande différence entre déchiffrer un code sans Specs ou autre ,quand il s'agit d'un code cobol ou code inline et quand il s'agit d'un code orienté object comme par exemple, c# ou c++ , je parle pas de codes style ,un project qui contient 27 classes mais bien des solutions qui contiennent au moins 77 projects ,et bien sur, avec une exploitation de la poo a grande échelle ainsi que de l'interopatibilite et pas des classes dérivées a deux niveaux et interface de décoration mais "d'utilité obligatoire".

[grunt2000]

Entre Anacrime dont les suggestions provoquent l'arrêt de Murielle Bolle et le suicide du juge Lambert dénonçant spécifiquement ce logiciel,
et APB qui laisse sur le carreau encore 67 000 bacheliers tout en en ayant affecté un grand nombre n'importe où ou en n'importe quoi,
je crois que nous sommes devant des monuments d'informatique imbécile dont nous devons prendre la mesure.

Parce qu'ils nous montrent à quel point notre art peut être dévoyé et produire le monde le plus abominable quand il est aux mains d'incompétents, de négligents, et de trop cupides.
Un monde devenu logiciellement injuste et brutal.
On ne peut qu'imaginer combien des jeunes de toutes filières sont maintenant désemparés et ne savent pas comment faire face à quelque-chose d'inhumain, comme ces ordinateurs et IA fous de romans d'anticipation, et qui en plus d'être visiblement raté n'explique à personne (et même pas à eux, ses victimes) son fonctionnement, ses choix.

[Bubu017]

Mouais enfin c'est facile d'accuser le logiciel. C'est toujours la faute de l'informatique et jamais de l'interface chaise-clavier.

[Matthieu Vergne]

C'est pareil quand on critique l'IA au lieu de critiquer ses concepteurs/utilisateurs.

Enfin bon, il suffit d'un coup de déprime ou de fatigue pour insulter (voire pire) son PC quand il fait pas ce qu'on veut. Ça je pense qu'on y est tous passé et y a rien de mal à ça (le crime de châtiment logiciel n'existe pas... encore). Faut juste pas oublier d'éviter ce genre de réaction quand on raisonne et argumente : il n'y a pas de responsable sans intention, et il n'y a pas de raison que ça change.