Mais, mais... comment trouver du boulot si on ne peut pas récrire nos programmes tous les 6 mois parce que (choix multiples possibles) □しろいしかく optimisation du code (parce qu'on a codé comme des pieds mais ça faut pas le dire au client) □しろいしかく sécurisation du code (parce qu'on a codé comme des pieds mais ça faut pas le dire au client) □しろいしかく nouvelle fonctionnalité du code qui nécessite une nouvelle architecture (parce qu'on a codé comme des pieds mais ça faut pas le dire au client) □しろいしかく nouveau langage à la mode qui permet d'avoir la même mais en mieux (parce qu'on a codé comme des pieds mais ça faut pas le dire au client) □しろいしかく code non maintenable (parce qu'on a codé comme des pieds mais ça faut pas le dire au client) □しろいしかく code non documenté (parce qu'on a codé comme des pieds mais ça faut pas le dire au client) □しろいしかく le concurrent le fait (parce qu'on a codé comme des pieds mais ça faut pas le dire au client) □しろいしかく tu peux pas cap' c'est nous les experts (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
Le problème du Cobol c'est qu'il faut redoubler d'efforts pour se trouver des excuses. Heureusement avec un peu de bouteille nous y arrivons aussi. D'autant plus que les pratiquants ne sont pas souvent informaticiens de métier mais ce sont retrouvés là-dedans par nécessité (ce qui soit dit en passant signifie que c'est pas trop dans les mœurs de vouloir recoder juste pour la beauté du geste).
Ce qui est paradoxal étant donné la nature du langage et l'écosystème dans lequel il est utilisé on est un peu obligé de savoir un minimum coder et architecturer (c'est-à-dire pas juste compter sur un gestionnaire de librairie et une base de code bullet-proof qu'on se contenter de télécharger/appeler, mais écrire de vrais algos avec nos petites mains - heureusement 99% du temps c'est assez trivial).
[^] # Re: Pourquoi casser ce qui fonctionne
Posté par Nicolas (site web personnel) . En réponse au lien Faut-il se débarrasser des systèmes COBOL ? Entre dédain et transmission des savoirs. Évalué à 2.
Mais, mais... comment trouver du boulot si on ne peut pas récrire nos programmes tous les 6 mois parce que (choix multiples possibles)
□しろいしかく optimisation du code (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□しろいしかく sécurisation du code (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□しろいしかく nouvelle fonctionnalité du code qui nécessite une nouvelle architecture (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□しろいしかく nouveau langage à la mode qui permet d'avoir la même mais en mieux (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□しろいしかく code non maintenable (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□しろいしかく code non documenté (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□しろいしかく le concurrent le fait (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
□しろいしかく tu peux pas cap' c'est nous les experts (parce qu'on a codé comme des pieds mais ça faut pas le dire au client)
Le problème du Cobol c'est qu'il faut redoubler d'efforts pour se trouver des excuses. Heureusement avec un peu de bouteille nous y arrivons aussi. D'autant plus que les pratiquants ne sont pas souvent informaticiens de métier mais ce sont retrouvés là-dedans par nécessité (ce qui soit dit en passant signifie que c'est pas trop dans les mœurs de vouloir recoder juste pour la beauté du geste).
Ce qui est paradoxal étant donné la nature du langage et l'écosystème dans lequel il est utilisé on est un peu obligé de savoir un minimum coder et architecturer (c'est-à-dire pas juste compter sur un gestionnaire de librairie et une base de code bullet-proof qu'on se contenter de télécharger/appeler, mais écrire de vrais algos avec nos petites mains - heureusement 99% du temps c'est assez trivial).