On est surtout sur une base de code gigantesque, essentiellement en back office (où ça bouge certainement beaucoup moins qu'en front office), et personne n'ose ou n'a les moyens de refaire ça avec des technologies plus modernes. Alors tant que ça marche, pourquoi pas ? Pour autant, j'appellerais pas vraiment ça "avoir du succès".
Posté par PR .
Évalué à 0.
Dernière modification le 09 février 2022 à 22:38.
On dév encore en Cobol. Il se raconte même que certains font encore du Pacbase, mais ça j’y crois pas, je pense que c’est un mythe :-`
Et il reste que peu de personne a les compétences toute techno confondue. Au moins dans le mainframe c’est cadré (pas de crainte de voir des nombres flottants, I/O complètement bordées, aucun risque d’injection SQL, performance acceptables même si codé avec les pieds — et c’est très souvent codé avec les pieds).
C’est un drame d’ailleurs, le refus de reconnaître cette base de code et ce travail qui continue ; Chez mon client actuel, on tient absolument à passer en méthodo. agile &wtf. Pas du tout adapté à un cycle de dév. sur serveurs z/OS.
Tu peux clarifier pourquoi une méthode agile ne serait pas adapté à un OS X sur un hardware Y ? (z/Os ou autre d'ailleurs). J'ai du mal à comprendre pourquoi.
Après y a agile et agile, y a l'agile du manager/chef de projet qui trouve le terme cool comme cache-misère de la Rache et y a les vrais méthodologies agile, avec des rôles clairement définie, beaucoup de micro-management etc…
Pour avoir fait de l'agile (plutôt du vrai) avec des devs COBOL dans l'équipe, je vois pas non plus pourquoi ce serait pas adapté, ça le faisait plutôt bien (sous Unix plutôt que z/OS, je ne sais pas si ça influe).
Et au passage, c'est le jour et la nuit la qualité de code entre les vieux trucs qui ont vécu trente ans en prod, et du code récent écrit avec de bonnes normes basées sur des années d'expérience et une architecture correcte.
De mémoire il y avait du JCL dans les chaînes batch, mais les équipes agiles n'intervenaient pas dessus. Elles touchaient soit les étapes de traitement appelées au sein des chaînes, soit des programmes TP.
Rupture/synchro, ça ne me parle pas, en tout cas pas sous ce nom.
Les anciens programmes étaient bien sûr régulièrement maintenus, mais ça n'avait pas un impact significatif sur la qualité.
La différence était plutôt sur la qualité du nommage (trop libre dans le vieux code, beaucoup mieux cadré dans le nouveau), sur l'architecture (les vieux programmes faisaient tout d'un coup, règles métiers et accès aux données entremêlés), sur les pratiques de programmation (les vieux programmes réutilisaient parfois des zones mémoires pour des usages différents, des GO TO, des MOVE CORRESPONDING…).
Arf, oui «synchro» c’est du vocable pacbase, en cobol pur on n’utilise pas toujours le même nom mais j’ai oublié les autres termes (fusion?). Sous Unix, ce serait des algorithmes construit à coup de sort/uniq/join. En SQL, ce sont tout simplement des jointures ou des group by (mais pas juste du “Query”, on fait des traitement dessus…).
Ça permet de ramener les traitements à une complexité linéaire (même si en pratique on ne travaille plus comme ça).
Par contre une rupture est une rupture.
Pour les JCL, après recherche, permet moi d’émettre de gros doutes : à priori c’est spécifique mainframe. À première vue, aucun lien avec Cobol, mais on ne comprend pas bien la déclaration des I/O Cobol si on n’a pas fait un peu de JCL.
Pour la qualité de code, tes critères sont purement formels et bas niveau. C’est sûr que sur des modifications mineures, où vous ne faites plus vraiment de nouvelle conception, l’agile peut suffir…
L'essentiel du travail était dans la création de nouveaux modules, mais il fallait parfois impacter les anciens. Et le COBOL n'était qu'une partie du travail de l'équipe.
Quant à JCL, ayant jeté un petit coup d’œil du côté de celui d'IBM, il est fort possible que la solution utilisée ait conservé ce nom (voire un sous-ensemble du langage) pour ses propres scripts.
y a les vrais méthodologies agile, avec des rôles clairement définie, beaucoup de micro-management etc…
s/micro/self
Le micro management c'est quand ton manager te donne des directives extrêmement précises sans te laisser de marge de manœuvre puis vérifie régulièrement où tu en es.
Les méthodes agiles (ou au moins la méthode Scrum) préconise du Self-Management (autogestion en français ?) qui est plutôt l'inverse. L'équipe doit s'auto-organiser.
ça n'empêche qu'il y a de beaucoup de micro qui aime bien se cacher sous un manteau agile… En tout cas dans nombre d'endroits où je suis passé en France.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Titre trompeur
Posté par mahikeulbody . Évalué à 7.
On est surtout sur une base de code gigantesque, essentiellement en back office (où ça bouge certainement beaucoup moins qu'en front office), et personne n'ose ou n'a les moyens de refaire ça avec des technologies plus modernes. Alors tant que ça marche, pourquoi pas ? Pour autant, j'appellerais pas vraiment ça "avoir du succès".
[^] # Re: Titre trompeur
Posté par PR . Évalué à 0. Dernière modification le 09 février 2022 à 22:38.
On dév encore en Cobol. Il se raconte même que certains font encore du Pacbase, mais ça j’y crois pas, je pense que c’est un mythe :-`
Et il reste que peu de personne a les compétences toute techno confondue. Au moins dans le mainframe c’est cadré (pas de crainte de voir des nombres flottants, I/O complètement bordées, aucun risque d’injection SQL, performance acceptables même si codé avec les pieds — et c’est très souvent codé avec les pieds).
C’est un drame d’ailleurs, le refus de reconnaître cette base de code et ce travail qui continue ; Chez mon client actuel, on tient absolument à passer en méthodo. agile &wtf. Pas du tout adapté à un cycle de dév. sur serveurs z/OS.
Mort aux cons !
[^] # Re: Titre trompeur
Posté par Tangi Colin . Évalué à 4.
Tu peux clarifier pourquoi une méthode agile ne serait pas adapté à un OS X sur un hardware Y ? (z/Os ou autre d'ailleurs). J'ai du mal à comprendre pourquoi.
Après y a agile et agile, y a l'agile du manager/chef de projet qui trouve le terme cool comme cache-misère de la Rache et y a les vrais méthodologies agile, avec des rôles clairement définie, beaucoup de micro-management etc…
[^] # Re: Titre trompeur
Posté par PR . Évalué à -1.
Rien que parler de micro-management me donne des boutons, mais au vu de la mentalité de l’informaticien moyen…
Mort aux cons !
[^] # Re: Titre trompeur
Posté par Boa Treize (site web personnel) . Évalué à 4.
Pour avoir fait de l'agile (plutôt du vrai) avec des devs COBOL dans l'équipe, je vois pas non plus pourquoi ce serait pas adapté, ça le faisait plutôt bien (sous Unix plutôt que z/OS, je ne sais pas si ça influe).
Et au passage, c'est le jour et la nuit la qualité de code entre les vieux trucs qui ont vécu trente ans en prod, et du code récent écrit avec de bonnes normes basées sur des années d'expérience et une architecture correcte.
[^] # Re: Titre trompeur
Posté par PR . Évalué à 1.
Ben déjà pas JCL et rupture/synchro, ça te parle ? Quelle volumétrie (fichiers traités, bases SQL) ?
Avec quelle maintenance ?
Mort aux cons !
[^] # Re: Titre trompeur
Posté par Boa Treize (site web personnel) . Évalué à 6.
De mémoire il y avait du JCL dans les chaînes batch, mais les équipes agiles n'intervenaient pas dessus. Elles touchaient soit les étapes de traitement appelées au sein des chaînes, soit des programmes TP.
Rupture/synchro, ça ne me parle pas, en tout cas pas sous ce nom.
Les anciens programmes étaient bien sûr régulièrement maintenus, mais ça n'avait pas un impact significatif sur la qualité.
La différence était plutôt sur la qualité du nommage (trop libre dans le vieux code, beaucoup mieux cadré dans le nouveau), sur l'architecture (les vieux programmes faisaient tout d'un coup, règles métiers et accès aux données entremêlés), sur les pratiques de programmation (les vieux programmes réutilisaient parfois des zones mémoires pour des usages différents, des GO TO, des MOVE CORRESPONDING…).
[^] # Re: Titre trompeur
Posté par PR . Évalué à 1.
Arf, oui «synchro» c’est du vocable pacbase, en cobol pur on n’utilise pas toujours le même nom mais j’ai oublié les autres termes (fusion?). Sous Unix, ce serait des algorithmes construit à coup de sort/uniq/join. En SQL, ce sont tout simplement des jointures ou des group by (mais pas juste du “Query”, on fait des traitement dessus…).
Ça permet de ramener les traitements à une complexité linéaire (même si en pratique on ne travaille plus comme ça).
Par contre une rupture est une rupture.
Pour les JCL, après recherche, permet moi d’émettre de gros doutes : à priori c’est spécifique mainframe. À première vue, aucun lien avec Cobol, mais on ne comprend pas bien la déclaration des I/O Cobol si on n’a pas fait un peu de JCL.
Pour la qualité de code, tes critères sont purement formels et bas niveau. C’est sûr que sur des modifications mineures, où vous ne faites plus vraiment de nouvelle conception, l’agile peut suffir…
Mort aux cons !
[^] # Re: Titre trompeur
Posté par Boa Treize (site web personnel) . Évalué à 2.
L'essentiel du travail était dans la création de nouveaux modules, mais il fallait parfois impacter les anciens. Et le COBOL n'était qu'une partie du travail de l'équipe.
Quant à JCL, ayant jeté un petit coup d’œil du côté de celui d'IBM, il est fort possible que la solution utilisée ait conservé ce nom (voire un sous-ensemble du langage) pour ses propres scripts.
[^] # Re: Titre trompeur
Posté par NicolasP . Évalué à 4.
s/micro/self
Le micro management c'est quand ton manager te donne des directives extrêmement précises sans te laisser de marge de manœuvre puis vérifie régulièrement où tu en es.
Les méthodes agiles (ou au moins la méthode Scrum) préconise du Self-Management (autogestion en français ?) qui est plutôt l'inverse. L'équipe doit s'auto-organiser.
[^] # Re: Titre trompeur
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
ça n'empêche qu'il y a de beaucoup de micro qui aime bien se cacher sous un manteau agile… En tout cas dans nombre d'endroits où je suis passé en France.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Titre trompeur
Posté par mahikeulbody . Évalué à 2.
Ça ne suffit quand même pas pour dire qu'un langage a actuellement du succès.
[^] # Re: Titre trompeur
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
C'est une réponse à l'autre extrême qui dit que le langage est mort ou à l'agonie, alors que finalement il n'en est rien.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.