Réécriture de l'assembleur IBM + COBOL en C ++

13

Je travaille comme agent / gestionnaire de location pour une entreprise de location de voitures qui fonctionne sur un système de location qui a été écrit en 1972. J'ai décidé qu'il était peut-être temps de faire une mise à jour. Pour un peu de contexte, voici un bref exemple de la folie que nous devons affronter quotidiennement avec ce programme:

Un agent de location doit se rappeler que l'impression sur un écran utilise "MXC" dans le champ ACT (tout est basé sur des codes courts), ce qui signifie perplexe pour "affichage MaXimum sur un contrat", tandis que sur un autre, il nécessite PR (pour PRint) dans le champ ACTION, mais plusieurs écrans utilisent un Y dans le champ PT (pour PrinT), encore un autre écran utilise Y dans le champ PRT (pour PRinT), un autre écran oblige l'utilisateur à appuyer sur Entrée (mais pas sur l'entrée à côté de la lettres, car il s'agit d'un nouveau caractère de ligne, ce doit être l'entrée sur le pavé numérique) puis F8, un écran différent mais lié nécessite simplement F8, certains écrans ont un champ étiqueté PRT, qui devrait être pour PRinT, mais le champ en fait ne fait rien et l'impression se fait automatiquement après avoir parcouru plusieurs invites, et encore plus d'écrans ont un champ intitulé IMPRIMER O / N,qui par défaut est insensé à Y pour les opérations dans lesquelles un autre emplacement fournit déjà des documents et à N pour les opérations dans lesquelles un autre concessionnaire aura besoin de documents.

J'ai décidé que je pouvais faire un meilleur travail que cela, alors j'ai décidé de contacter la personne dans l'entreprise qui prendrait la décision de mettre à jour cela. Je parviens finalement au VP de l'informatique, qui est en charge de ce programme. Je reçois un peu d'informations de lui et j'apprends que mon entreprise de location de voitures a son programme de location écrit dans l'assembleur d'IBM IBM avec un peu de COBOL mélangé. Il dit qu'il n'y a pas de postes ouverts en ce moment, mais que je devrais envoyez-lui mon curriculum vitae de toute façon (au cas où quelque chose s'ouvre).

Cela m'amène à mes questions.

Le premier est technique. Avec l'idée d'améliorer la maintenabilité à l'avenir, ma pensée est de la réécrire dans un langage de niveau supérieur au langage d'assemblage. Mon domaine d'expérience est en C ++, c'est donc le choix évident pour moi. La société a un besoin urgent d'un moyen plus facile de mettre à jour le programme, car j'ai récemment lu un article dans lequel l'homme à qui j'ai parlé aurait déclaré que l'équipe avait travaillé dur, et ils sont fiers d'annoncer que le programme prend désormais en charge 5 - codes de localisation à chiffres (au lieu de 4) et numéros de voiture à 8 chiffres (au lieu de 7). Ma philosophie sur les mises à jour, même dans des situations aussi dramatiques, est conforme à celle de Joel: http://www.joelonsoftware.com/articles/fog0000000069.html en bref, les réécritures devraient être incrémentielles, plutôt que de jeter tout ce qu'il y avait avant et recommencer à zéro.

Existe-t-il un moyen simple d'intégrer IBM Assembly à C ++, et si oui, comment dois-je procéder? Je connais vaguement le mot-clé asm, mais je ne sais pas s'il est préférable de l'utiliser ou de faire autre chose. Un tel plan est-il mal avisé? Je fais la plupart de mon travail sur Linux en utilisant g ++ et GNU make, donc les réponses spécifiques à cela sont les bienvenues, mais certainement pas requises (car je n'ai aucune idée de quel type de système de construction ils n'ont pas, mais je soupçonne presque aucun).

La deuxième question est plus politique. Comment dois-je faire pour persuader cette entreprise qu'elle doit faire le changement? Les économies théoriques sont énormes (sur la base de mes estimations, la société gaspille un million de dollars supplémentaires par an, juste sur l'augmentation des coûts de formation pour apprendre à interagir avec le programme), mais les changements que je propose mettraient probablement tous les les programmeurs actuels sans emploi, s'ils sont adoptés, il y a donc une grande résistance structurelle au changement.

edit: je devrais expliquer pourquoi ma modification de ce que l'entreprise a déjà semble être la meilleure solution pour moi. Je suis toujours ouvert à d'autres suggestions, car il s'agit cependant d'un monstre de programme. Je n'ai jamais eu de travail de programmation auparavant, alors corrigez-moi toute analyse incorrecte que je pourrais donner.

Tout d'abord, il y a la solution standard.

D'après mes entretiens avec quelques gestionnaires de niveau intermédiaire à propos de ce genre de chose, l'une des principales préoccupations liées au passage à un nouveau système est le grand nombre d'employés fidèles qui travaillent dans l'entreprise depuis des décennies et qui sont à l'aise avec le système à l'heure actuelle. . Si j'ai la possibilité de modifier ce que nous avons, je pourrais maintenir l'interface actuelle dans une sorte de «mode de compatibilité». Les utilisateurs doivent déjà se connecter pour utiliser le système actuel, donc je pourrais ajouter la possibilité d'activer un paramètre lorsque les utilisateurs se connectent pour la première fois (après avoir effectué cette modification), où ils ont la possibilité d'utiliser soit le interface «classique» ou «nouvelle» interface. Il n'y a aucun moyen que je trouve une solution standard qui permet cela,

Mon entreprise possède également les logiciels que nous utilisons; nous ne l'autorisons pas. Cela signifie que la direction à laquelle je parle actuellement sont les mêmes personnes qui pourraient en fait m'autoriser à effectuer un changement. Avec une solution tierce, je devrais obtenir l'approbation de mon entreprise en plus d'obtenir tous les droits nécessaires de la société qui a développé le produit que nous utilisons, ce qui ajoute un obstacle supplémentaire. Cela nécessiterait également de convaincre la société de renoncer à «son» produit et de prendre un autre produit, ce qui semble être un obstacle plus important que d'essayer de mettre à jour ce que nous avons, mais je peux très bien me tromper sur cette question.

Enfin, en regardant vers l'avenir, je ne veux pas seulement améliorer l'interface utilisateur et corriger quelques bugs. Après avoir mis à jour ces problèmes «urgents», j'espérais mettre à jour le fonctionnement fondamental de l'entreprise en ce qui concerne la technologie. Après avoir passé un à deux ans sur ce genre de problèmes, mon plan était de revenir à la direction et de proposer des changements plus spectaculaires. Il existe de nombreuses façons dont l'entreprise fonctionne qui pourraient être fondamentalement améliorées par une technologie qu'elle n'utilise tout simplement pas en ce moment. Par exemple, chaque région fonctionne à peu près de la même manière. L'aéroport principal local est la plaque tournante centrale pour la distribution des voitures. Ils sont principalement envoyés au besoin. Cependant, l'aéroport est utilisé comme base d'attache pour toutes les opérations. Ils enverront deux personnes dans une voiture chez moi pour récupérer une voiture dont nous n'avons pas besoin, puis retournez à l'aéroport avec la voiture dans laquelle ils sont arrivés, plus ce qu'ils ramènent (nous sommes à 32 miles de l'aéroport). Ensuite, ils viendront à l'emplacement à 5 miles de nous dans deux voitures pour déposer l'un d'eux, puis retourneront dans leur autre voiture à l'aéroport. Ils le font même si la voiture que nous avons renvoyée est le même type de voiture dont ils ont besoin près de chez nous. Cela fait maintenant environ deux ans que je travaille dans l'entreprise, et il me semble qu'ils s'en écartent dans les situations d'urgence les plus extrêmes de la pénurie de voitures (donc environ trois fois). Je remplacerais les 4 personnes travaillant dans chaque région par un système de planification automatisé qui détermine quelles voitures vont où et j'essaie de trouver le chemin qui nécessite le moins de temps + miles + conducteurs pour livrer toutes les voitures là où elles doivent être, en tant que exemple des correctifs de niveau supérieur que j'espère ajouter un jour.

Cependant, avant de me sentir à l'aise de proposer tout cela, je pense qu'il serait utile de se familiariser avec l'entreprise et la base de code en effectuant des tâches plus petites, comme la mise à jour de l'interface. Des solutions comme l'externalisation ou autre supprimeraient cette possibilité.

David Stone
la source
3
Regardez l'émulateur Hercules - il y a beaucoup de magie dans le système d'exploitation principal d'un mainframe IBM qui doit être émulé.
Yann Ramin
Je regarderais honnêtement "refaire depuis le début" (mauvaise blague C64). Sérieusement, vérifiez les spécifications et voyez ce que cela pourrait prendre pour écrire une nouvelle interface graphique vous-même. Tant que l'interface de la base de données est la même, et cela prendra beaucoup de temps et de recherches pour déterminer, alors vous êtes en or - et en ligne pour gagner $ # && charge d'argent :)
8
Si le système actuel fonctionne réellement , vous devez avoir une très bonne raison pour que cela soit payant pour le client. De plus, vous sous-estimerez très probablement la quantité de travail nécessaire pour reproduire le système actuel - pensez simplement que vous devez d'abord comprendre le système actuel - ce qui rend votre réécriture encore plus coûteuse que votre estimation d'origine. Ce n'est pas pour vous décourager, mais simplement pour vous assurer que vous savez réellement quelle tâche herculéenne vous pourriez vous inscrire AVANT de ne pas pouvoir vous retirer. Aussi, rendez votre travail incrémental - en d'autres termes, restez sur le mainframe pour l'instant.
C'est ma crainte qu'il serait très difficile d'émuler le système qui m'a conduit à chercher un moyen pour moi de faire de petits changements modulaires, plutôt que d'essayer de recommencer à zéro.
David Stone
@David Stone J'ai déjà participé à un projet dans lequel nous avons fait le choix de la nouvelle ou de l'ancienne interface. Il est entré RAPIDEMENT dans l'enfer du développement - le code était étroitement couplé à l'interface et le if (m_newInterface)code spaghetti a rapidement commencé à apparaître partout dans la base de code. Le découplage et le refactoring ont pris suffisamment de temps pour que, lorsque cela a été fait, la plupart des utilisateurs aient déjà migré vers la nouvelle interface (pensez plusieurs années).
Vitor Py

Réponses:

4

Je me cantonne au front technique ...

Je vous suggère de commencer par déterminer l'environnement dans lequel l'application s'exécute. "Mainframe" peut signifier plusieurs choses différentes, étant donné l'âge de l'application, il peut s'agir de CICS ou IMS . Il est également possible que les auteurs originaux aient écrit leur propre tâche commencée.

Selon l'endroit où l'application s'exécute, elle utilisera probablement des API pour cet environnement, CICS utilise maintenant une interface nettement différente de ses débuts, je ne peux pas parler pour IMS. Si l'application est sa propre tâche démarrée, elle peut très bien avoir sa propre API interne - j'ai passé environ sept ans à soutenir une telle bête, écrite à la même époque.

Autre chose à considérer, étant donné l'âge de l'application, c'est que l'assembleur avec lequel vous souhaitez intégrer C ++ est antérieur à l'existence de Language Environment (LE). En tant que tel, à moins que l'assembleur n'ait été mis à jour pour être conforme à LE, vous aurez quelques difficultés car C et C ++ sont conformes à LE et exigeront que leurs appelants et leurs callees soient également conformes.

Un autre point à considérer, si cette application s'exécute sur un ordinateur central moribond, vous envisagez peut-être d'intégrer une application qui s'exécute sur du matériel et des logiciels non pris en charge. Ce ne serait pas différent d'essayer de l'intégrer avec une application écrite en 1989 qui fonctionne sous DOS 4.01 sur son matériel d'origine.

cschneid
la source
L'application pourrait même utiliser TPF , ce qui rendrait une conversion extrêmement difficile.
Gilbert Le Blanc
13

Vous sautez l'arme. D'après votre description, il semble que vous n'ayez pas entièrement compris l'environnement technique actuel (quel système d'exploitation exactement, où et comment sont stockées les données, existe-t-il des interfaces avec d'autres systèmes, etc.). Mais encore plus important: un plan sérieux devrait envisager des alternatives à une réécriture interne partielle ou complète du logiciel, à savoir un logiciel standard, une externalisation de la réécriture, un logiciel en tant que service, etc.

Quelle que soit la façon dont l'entreprise va finalement, elle a d'abord besoin d'une analyse solide de ce que fait le logiciel aujourd'hui et des exigences de la nouvelle solution.

Alors pourquoi ne proposez-vous pas de faire cette analyse?

Codo
la source
7
+1 C'est la seule réponse qui propose une analyse complète de l'application existante et des besoins de l'entreprise avant de proposer une solution technique. Cela me rappelle la vieille blague: vous commencez à coder - je vais découvrir ce qu'ils veulent.
C'est un bon point, et j'ai certainement besoin de plus d'informations avant de m'engager à faire ce travail. Une partie du problème est que j'ai demandé autour de moi, et ce n'est que lorsque j'ai contacté un vice-président de l'entreprise que j'ai trouvé quelqu'un qui connaissait vraiment les détails. J'ai appelé plusieurs bureaux, y compris le support technique, et aucun d'entre eux n'a pu me donner de détails tels que le langage de programmation dans lequel le programme a été écrit. Cependant, j'ai quelques raisons de lancer une solution standard, dans laquelle je modifierai ma question d'origine.
David Stone
7

Je suis surpris que vous ayez eu une réponse aussi polie!

Regardons cela de leur point de vue.

Ils ont réussi à gérer un système vieux de trente ans avec probablement des centaines de milliers de lignes de code, des interfaces avec peut-être vingt autres systèmes qui incarnent un processus métier qui a évolué sur quarante ans.

Ils sont probablement / espérons-le des experts dans leur domaine et, en tant que tels, considéreraient le C ++ comme un pas en avant du "langage de haut niveau de l'assembleur" d'IBM pour lui donner son titre complet. Le langage assembleur d'IBM est extrêmement puissant et le langage "MACRO" est la meilleure implémentation d'un langage de prétraitement / modèle.

Il aura été proposé de remplacer leur système tous les cinq ans environ depuis sa mise en œuvre. Certains auraient été rejetés après une étude de faisabilité, certains auraient atteint la phase de conception avant de perdre leur budget, certains auraient même pu entrer dans le code et peut-être en phase de test avant de rencontrer des problèmes de performances et de se mettre en conserve.

C ++ n'aiderait tout simplement pas. Il n'y a pas de bibliothèque graphique dans l'environnement où l'application s'exécute. (Il existe une bibliothèque graphique 3270, mais il est peu probable qu'elle soit prise en charge en C ++ car personne ne l'utilise et il existe une bibliothèque cliente "X" complète, mais vous devez être dans un environnement différent pour l'utiliser.)

Ils ont une interface utilisateur loin d'être parfaite mais bien connue et rapide. Un opérateur expérimenté remplira un formulaire environ trois fois plus rapidement en utilisant un écran vert plutôt qu'une interface graphique équivalente. De plus, ils peuvent prêter attention au client lorsqu'ils touchent le type.

Les opérateurs d'écran auront besoin de formation quelle que soit l'interface qu'ils utilisent, recycler tous les employés pour utiliser une nouvelle interface graphique inconnue serait un poste budgétaire énorme par rapport à la simple formation des nouveaux employés sur l'ancien système mondain.

James Anderson
la source
4

J'ai eu un problème similaire il y a quelques années chez BellSouth. J'ai simplement écrit du code COBOL pour analyser les programmes de langage assembleur octet par octet, séparer les opcodes et opérandes, convertir les instructions de branchement en tos et convertir les instructions de comparaison en IF. Ce programme a converti les instructions DC en code COBOL Data Division équivalent et converti les mouvements, zaps, etc., selon le cas.

Une fois cela fait, j'ai écrit un deuxième programme pour convertir les IF et les GOTO en IF-THEN, avec des mouvements et autres dans les lignes entre ces clusters (ce n'était pas vraiment si difficile à faire - le secret est d'insérer les IF et ELSE pendant que vous relisez le cobol "pidgin" de la première phase de l'arrière vers l'avant).

IF-THEN-ELSER a recherché des situations où il a trouvé une référence GOTO à proximité d'une étiquette, qui pourrait être supprimée en toute sécurité (décrémentant son nombre de références de 1). Vous exécutez ce programme IF-THEN-ELSER de manière itérative (c'est-à-dire que vous l'exécutez encore et encore, en vous arrêtant uniquement lorsque votre dernier passage ne peut pas trouver un moyen d'apporter d'autres modifications). La plupart du travail critique est effectué par ce si-alors-elser, dont le produit COBOL doit être soigneusement examiné et vérifié par un programmeur expérimenté et compétent en langage assembleur (à savoir, moi). D'après mon expérience, mon "if-then-elser" a pu éliminer plus de 90% des GO TO résultant des instructions de branchement d'origine.

Je suppose qu'il est possible d'aller de l'avant à partir de ce point avec une conversion simple en C (ou C ++) - langages avec lesquels je suis également familier. Cependant, chez BellSouth, notre langue cible de choix était COBOL / II. Il y a toujours un peu de complexité qui découle des situations où une étiquette restante a plusieurs références GO TO (plusieurs fois, ces situations sont gérées par COBOL PERFORMs, mais peuvent parfois être simplement représentées par des constructions OR et AND).

Je pense qu'il est agréable de produire du code en COBOL / II élégamment structuré en blocs, avec EVALUATEs (constructions de cas) et 88 noms de condition de niveau. L'ajout de ces touches finales a conduit à une autre paire de programmes, qui s'est avérée pratique pour les programmes COBOL ne provenant pas de programmes convertis à partir de l'assembleur.

Je ne sais pas si cela aide.

Comme d'autres l'ont indiqué ci-dessus, vous devez mener ce processus avec soin. Il est utile d'avoir 10 à 12 ans d'expérience en codage d'assembleur pour éclairer vos processus de prise de décision. Nous qui avons cette expérience sont difficiles à trouver.

Pour terminer: nous n'avions écrit dans l'assembleur à l'époque que parce que les compilateurs pour les langages de haut niveau produisaient un code objet lourd et inefficace. Les compilateurs COBOL «optimisants» d'aujourd'hui n'ont pas les mêmes mauvaises habitudes. ----------

Mark Mondt
la source
2

Les conseils de Joel sont généralement judicieux, mais dans ce cas, une réécriture complète est attendue. Idéalement, une réécriture avec une hampe de bataille, car ce que vous traitez ici est un monstre.

Je ne sais pas exactement quoi ajouter, car vous avez déjà fait un très bon argument pour cette réécriture vous-même. Ma seule recommandation serait de sauter complètement C ++ et d'aller directement à une interface Web pour le système de location, car cela sera probablement encore plus facile pour former les travailleurs et vous fera économiser beaucoup de travail sur l'interface utilisateur (ainsi que faire il est beaucoup plus facile d'obtenir du sang neuf dans le projet, ou même d'externaliser le tout).

Quant aux programmeurs COBOL existants, ils peuvent peut-être aider à documenter le système existant et au processus de migration.


la source
2
+1: ce n'est pas un travail pour C ++
6502
2
@ 6502: Pourquoi pas? L'expertise de l'OP est en C ++. Savoir comment gérer un ancien système est déjà assez mauvais. Apprendre une autre langue ne va pas aider. Un programmeur compétent utilisant des outils auxquels le programmeur est compétent sera en mesure de le faire fonctionner beaucoup mieux que l'ancien système, quelle que soit la langue.
In silico
1
@In silico: À mon avis, pour un projet assez important de cette taille, vous gagneriez du temps en apprenant un langage plus approprié comme par exemple Python que d'utiliser C ++. En supposant que Python n'était pas là, pour un projet assez grand de ce genre, IMO paierait l'écriture de votre propre Python en C ++ et le coderait en utilisant cela au lieu de faire le tout en C ++. C ++ est un langage très agréable et son point fort est que par conception ne veut pas laisser d'espace en dessous de C ++ et au-dessus de l'assembleur. Totalement inutile ici. Recommanderiez-vous de tout écrire en utilisant des FPGA si tel était le domaine d'expertise de l'affiche?
6502
3
@ 6502: Je ne suis pas d'accord. Avec une technique appropriée et moderne, des bibliothèques bien conçues et une compétence dans la langue, toutes ces questions ne sont pas pertinentes. (C'est vrai pour n'importe quel langage, bien sûr.) Et les gens ont développé des systèmes et des logiciels à grande échelle en C ++ qui fonctionnent très bien et ne semblent pas avoir de problème avec l'utilisation de C ++. Ce n'est pas parce que vous n'utiliseriez pas C ++ pour ce travail que d'autres ne pourraient pas l'utiliser et bien l'utiliser. C'est au PO de décider. Je suis sûr que vous êtes assez productif dans d'autres langues, et continuez à le faire.
In silico
1
In silico: Clairement, tout peut en théorie être implémenté avec n'importe quoi (y compris brainf k). Cela ne signifie pas que tous les outils sont équivalents. Je pense que pour une application commerciale, avoir du code simple à écrire et à lire (même par des personnes non techniques) est beaucoup plus important que la vitesse de calcul. De plus, quelque chose comme un comportement indéfini est un prix beaucoup trop élevé pour payer la proximité inutile avec le métal. Si pour vous le C ++ est un bon choix pour la logique métier une application de saisie de données alors je me demande si pour vous il y a ** quelque chose pour lequel le C ++ est un mauvais choix ...
6502
2

Quant à l'aspect technique, beaucoup dépendra de la qualité - la modularité - du code assembleur. Certains programmeurs ont compris l'importance de créer des modules avec une fonction spécifique et limitée et une interface paramétrée claire et simple, en utilisant les conventions de liaison de sous-programme IBM standard. Cependant, la grande majorité a eu tendance à créer des monstruosités monolithiques.

Avec le premier, la réutilisation est possible, et il ne devrait pas être si difficile de trouver la «colle» entre C ++ et l'assembleur, en supposant que vos modules d'assembleur utilisent des séquences d'appel standard (ou au moins cohérentes). Selon toute vraisemblance, cependant, le code assembleur sera un gâchis. Bien qu'il ait été possible d'écrire un assembleur structuré, très peu de personnes l'ont fait, et il sera presque impossible de discerner un "design" à partir duquel commencer la réécriture.

D'un autre côté, l'assembleur 360/370 est assez haut niveau par rapport aux microprocesseurs d'aujourd'hui, et beaucoup plus simple, et C est parfois considéré comme "assembleur de haut niveau". J'ai travaillé pour une société de SGBD dont le produit était entièrement 370 assembleur, et notre architecte principal pensait qu'il pourrait être possible de traduire automatiquement le code assembleur en C (pour une future portabilité). Je suis sceptique, mais le fait est que la distance n'est pas aussi grande qu'on pourrait le penser.

Je ne sais pas si tout cela est utile. Comme je l'ai dit, je pense que cela dépend fortement de la qualité et de la taille du code d'origine.

Type
la source
1

Je ne peux pas dire si c'est une blague ou non - votre entreprise exécute sérieusement du code écrit il y a 39 ans? S'il fonctionne sur un système / 360, vous devrez compiler g ++ à partir des sources ...

Honnêtement, je ne penserais même pas à utiliser l'ancien code; vous devez adopter une nouvelle approche, vous asseoir et réfléchir à ce qui doit entrer dans la conception, et le faire à partir de zéro. Oui, cela impliquera un peu de planification, mais je ne pense pas que même Joel dirait que c'est un cas pour des changements progressifs.

En ce qui concerne la persuasion de la société que vous devez changer, vous devez indiquer des raisons spécifiques qui amélioreront l'efficacité, entraîneront une baisse des coûts et / ou montreront que ce que vous utilisez maintenant nuit actuellement au résultat net.

Un autre commentaire - j'imagine que d'autres sociétés de location de voitures ont rejoint le reste d'entre nous au 21e siècle; Je ferais un peu de reconnaissance pour voir comment ils le font (sur le Web, j'imagine), et éventuellement le modéliser d'après l'un de ces systèmes (c'est-à-dire, ne pas réinventer la roue).

Bonne chance!

Chris Gregg
la source
5
Il n'est pas rare que les systèmes mainframe utilisent des bases de code commencées dans les années 60 ou 70. IBM conserve ses mainframes zSeries et le système d'exploitation rétrocompatible avec le 360 ​​juste à cause de cela. Il n'y a pas grand-chose dans le modèle économique d'une entreprise de location de voitures (ou d'une banque ou d'une compagnie d'assurance) qui a changé depuis. Vous pouvez ajouter une interface Web, bien sûr, mais qu'est-ce qui a changé dans la façon dont vous stockez les voitures dans la base de données?
Bo Persson
zOS possède un compilateur C ++ natif complet avec des pré-processeurs pour CICS et DB2. Il n'y a donc pas besoin de g ++.
James Anderson
5
Deuxièmement, il est assez courant que les grandes sociétés utilisent un code mainframe vieux de 30 ans. Son généralement fiable, performant et fait le travail. Il a également tendance à être très mal documenté.
James Anderson
3
@Chris, pourquoi ne devrait-on pas exécuter un code vieux de 39 ans? Est-ce que ça devient périmé à 30 ans? 20? Le code de production testé en combat peut être ancien mais faire toujours parfaitement le travail. Toute réécriture doit atteindre le même niveau que l'ancien programme avant de bénéficier à celui qui paie vos frais.
1
@Chris, très peu est plus rapide qu'une application "écran vert" bien écrite, et je le sais par expérience personnelle en étant le gars Java dans une boutique Cobol. Je crois sincèrement que vous sous-estimez tous sincèrement la quantité de travail nécessaire pour avoir une application similaire. De plus, le code ne rouille pas. Le fait d'être vieux n'est pas une raison suffisante pour y remédier.
0

En théorie, il ne devrait pas être difficile de convaincre la haute direction de remplacer l'ancien système si vous pouvez leur montrer que cela leur fera économiser des mégabucks. Et ce sera le cas. Il deviendra de plus en plus difficile de trouver des programmeurs pour maintenir ce système, et ces programmeurs deviendront de plus en plus chers. Ce n'est pas une question de «si», c'est une question de «quand». Il faut vraiment le mettre à jour.

Cependant, la question est de savoir si vous pouvez les convaincre non seulement qu'il a besoin d'une mise à jour (et ils le savent probablement de toute façon), mais que ce devrait être un projet interne. Surtout si l'équipe n'est que vous. Très souvent, un tel remplacement majeur est externalisé. Il peut même y avoir des logiciels disponibles sur le marché pour examen. Ces options doivent être étudiées et vos gestionnaires insisteront pour que cela se produise s'ils sont raisonnables.

Quant à la tâche, si vous deviez le faire, je pense en fait qu'une réécriture au bulldozer peut être appropriée dans ce cas. L'argument de Joel ne s'applique pas dans tous les cas. Mais je ne pouvais pas vraiment savoir sans le voir.

Igby Largeman
la source
0
  1. Un changement progressif est hors de question.

  2. Il est probable qu'une solution standard soit disponible. Il existe de nombreuses entreprises de location de voitures.

  3. Si, en dernier recours, vous avez besoin de le réécrire, passez d'abord un peu de temps à réfléchir au fonctionnement du nouveau système.
    Après avoir identifié les fonctionnalités et les interfaces, vous pouvez alors choisir les outils de développement qui correspondent le mieux aux besoins (et à vos compétences).

Une stratégie pour minimiser le stress pour les utilisateurs finaux consiste à commencer à émuler l'ancienne interface laide que les utilisateurs connaissent, avec quelques subtilités comme des listes déroulantes pour les mnémoniques laides, puis à ajouter progressivement des fonctionnalités d'interface utilisateur et à les sevrer dans une interface utilisateur moderne.

Vous ne voudrez probablement pas conserver le même format de fichier de données, il n'y aura donc pas de retour possible une fois qu'ils auront changé.

Michael J
la source
1
Si vous ne le faites pas progressivement, le projet échouera très probablement.