Riscrittura dell'assemblatore IBM + COBOL in C ++


13

Lavoro come agente di noleggio / manager per una società di noleggio auto che è in esecuzione su un sistema di noleggio che è stato scritto nel 1972. Ho deciso che forse era il momento di un aggiornamento. Per un po 'di background, ecco un breve esempio della follia che dobbiamo affrontare quotidianamente da questo programma:

Un agente di noleggio deve ricordare che la stampa su uno schermo utilizza "MXC" nel campo ACT (tutto si basa su codici brevi), che significa perplesso "MaXimum display on a Contract", mentre su un altro richiede PR (per PRint) in il campo AZIONE, ma diverse schermate utilizzano una Y nel campo PT (per PrinT), un'altra schermata utilizza Y nel campo PRT (per PRinT), ma un'altra schermata richiede che l'utente prema Invio (ma non il tasto Invio accanto al lettere, poiché si tratta di un nuovo carattere di linea, deve essere il tasto Invio sul tastierino numerico) e quindi F8, una schermata diversa ma correlata richiede semplicemente F8, alcune schermate hanno un campo etichettato PRT, che dovrebbe essere per PRinT, ma il campo in realtà non fa nulla e la stampa viene eseguita automaticamente dopo aver esaminato diversi prompt e ancora più schermate hanno un campo con l'etichetta STAMPA S / N,che per impostazione predefinita è follemente Y per le operazioni in cui un altro luogo sta già consegnando documenti e su N per le operazioni in cui un altro rivenditore avrà bisogno di documenti.

Decisi che avrei potuto fare un lavoro migliore di così, quindi mi misi in contatto con la persona della compagnia che avrebbe preso la decisione di aggiornarlo. Alla fine mi rivolgo al vicepresidente dell'IT, che è responsabile di questo programma. Prendo un po 'di informazioni da lui e apprendo che la mia compagnia di autonoleggio ha il suo programma di noleggio scritto nell'assemblatore mainframe IBM con un po' di COBOL mescolato. Dice che non ci sono posizioni aperte in questo momento, ma che dovrei e-mail lui il mio curriculum comunque (nel caso in cui qualcosa si apre).

Questo mi porta alle mie domande.

Il primo è tecnico. Con l'idea di migliorare la manutenibilità in futuro, il mio pensiero è quello di riscriverlo in un linguaggio di livello superiore rispetto al linguaggio assembly. La mia area di esperienza è in C ++, quindi questa è la scelta ovvia per me. La società ha un disperato bisogno di un modo più semplice per aggiornare il programma, poiché di recente ho letto un articolo in cui l'uomo con cui ho parlato è citato dicendo che il team ha lavorato duramente e sono orgogliosi di annunciare che il programma ora supporta 5 -codificare i codici di posizione (anziché 4) e i numeri di auto a 8 cifre (anziché 7). La mia filosofia sugli aggiornamenti, anche in situazioni così terribili, è in linea con quella di Joel: http://www.joelonsoftware.com/articles/fog0000000069.html in breve, le riscritture dovrebbero essere incrementali, piuttosto che buttare via tutto ciò che c'era prima e ricominciare da capo.

Esiste un modo semplice per integrare IBM assembly con C ++ e, in tal caso, come devo fare? Sono vagamente consapevole della parola chiave asm, ma non so se sia meglio usarlo o fare qualcos'altro. Un piano del genere è sconsiderato? Faccio la maggior parte del mio lavoro su Linux usando g ++ e GNU make, quindi le risposte specifiche sono benvenute, ma sicuramente non richieste (dal momento che non ho idea di che tipo di sistema di build non abbiano, ma sospetto quasi nulla).

La seconda domanda è più politica. Come dovrei persuadere questa azienda a dover cambiare? I risparmi teorici sui costi sono enormi (in base alle mie stime, la società sta sprecando circa un milione di dollari in più all'anno, solo per aumentare i costi di formazione per imparare a interagire con il programma), ma i miei cambiamenti proposti probabilmente metterebbero tutti i gli attuali programmatori non hanno lavoro, dovrebbero essere messi in atto, quindi c'è una grande resistenza strutturale al cambiamento.

modifica: dovrei spiegare perché la modifica di ciò che l'azienda ha già mi sembra la soluzione migliore. Sono ancora aperto ad altri suggerimenti, perché questo è un mostro di un programma, tuttavia. Non ho mai avuto un lavoro di programmazione prima, quindi per favore correggimi su qualsiasi analisi errata che potrei dare.

Prima di tutto, c'è la soluzione standard.

Dai miei colloqui con alcuni manager di medio livello su questo genere di cose, una delle preoccupazioni principali nel passaggio a un nuovo sistema è il gran numero di dipendenti fedeli che sono stati con l'azienda per decenni e ormai sono a proprio agio con il sistema . Se avessi la possibilità di modificare ciò che abbiamo, avrei potuto mantenere l'interfaccia attuale in una sorta di "modalità di compatibilità". Gli utenti devono già accedere per utilizzare il sistema corrente, quindi potrei aggiungere la possibilità di attivare un'impostazione quando gli utenti accedono per la 'prima' volta (dopo aver apportato questa modifica), dove hanno la possibilità di utilizzare il interfaccia "classica" o "nuova" interfaccia. Non c'è modo di trovare una soluzione standard che lo consenta,

La mia azienda possiede anche il software che utilizziamo; non lo autorizziamo. Ciò significa che i dirigenti con cui sto parlando sono le stesse persone che potrebbero effettivamente autorizzarmi a fare un cambiamento. Con una soluzione di terze parti, dovrei ottenere l'approvazione della mia azienda oltre a garantire tutti i diritti necessari alla società che ha sviluppato il prodotto che utilizziamo, il che aggiunge un ulteriore ostacolo. Ciò richiederebbe anche convincere la società a rinunciare al "loro" prodotto e prendere qualche altro prodotto, che sembra un ostacolo maggiore rispetto al tentativo di aggiornare ciò che abbiamo, ma potrei benissimo sbagliarmi su questo problema.

Infine, guardando al futuro, non voglio solo migliorare l'interfaccia utente e correggere alcuni bug. Dopo aver aggiornato quei problemi "urgenti", speravo di aggiornare il modo fondamentale in cui la società gestisce la tecnologia. Dopo aver trascorso 1-2 anni su questo tipo di problemi, il mio piano era di tornare alla direzione e proporre cambiamenti più drammatici. Ci sono molti modi in cui la società gestisce che potrebbero essere sostanzialmente migliorati dalla tecnologia che semplicemente non stanno usando in questo momento. Ad esempio, ogni regione funziona praticamente allo stesso modo. Il principale aeroporto locale è l'hub centrale per la distribuzione di automobili. Vengono inviati principalmente in base alle necessità. Tuttavia, l'aeroporto è utilizzato come base di partenza per tutte le operazioni. Manderanno due persone in una macchina nella mia posizione per ritirare da noi un'auto di cui non abbiamo bisogno, quindi tornare all'aeroporto con l'auto in cui sono entrati, oltre a ciò che stanno riprendendo (siamo a 32 miglia dall'aeroporto). Poi arriveranno nel luogo a 5 miglia di distanza da noi in due auto per lasciarne una, poi torneranno nell'altra macchina all'aeroporto. Lo fanno anche se l'auto che abbiamo rispedito è lo stesso tipo di auto di cui hanno bisogno vicino a noi. Sono in compagnia da circa due anni ormai, e mi sembra che si discostino da questo solo nelle emergenze più estreme di carenza di automobili (quindi circa tre volte in assoluto). Sostituirei le 4 persone che lavorano in ogni regione con un sistema di programmazione automatizzato che determina quali auto vanno dove e cerca e trova il percorso che richiede il minor tempo + miglia + autisti per consegnare tutte le auto dove devono essere, come un esempio delle correzioni di livello superiore che spero di aggiungere un giorno.

Tuttavia, prima di sentirmi a mio agio a proporre tutto ciò, ritengo che sarebbe utile avere una visione d'insieme della società e della base di codice eseguendo le attività più piccole, come l'aggiornamento dell'interfaccia. Soluzioni come l'outsourcing o altrimenti eliminerebbero questa possibilità.


3
Guarda nell'emulatore Hercules: c'è molta magia nel sistema operativo principale di un mainframe IBM che deve essere emulato.
Yann Ramin,

Guarderei onestamente "rifare dall'inizio" (brutta battuta C64). Seriamente, controlla le specifiche e vedi cosa potrebbe servire per scrivere una nuova GUI. Finché l'interfaccia del database è la stessa, e questo richiederà molto tempo e ricerca per determinare, allora sei d'oro - e in linea per fare un carico di denaro $ # && :)

8
Se il sistema attuale funziona davvero , devi avere un'ottima ragione per pagare il cliente. Inoltre, molto probabilmente sottovaluterai gravemente la quantità di lavoro necessaria per riprodurre il sistema attuale - basti pensare che devi prima capire il sistema attuale in modo completo - rendendo la tua riscrittura ancora più costosa della stima originale. Questo non per scoraggiarti, ma solo per assicurarti che tu sappia davvero quale compito erculeo potresti iscriverti PRIMA di non poter uscire. Inoltre, rendi il tuo lavoro incrementale - in altre parole, resta sul mainframe per ora.

Temo che emulare il sistema sarebbe molto difficile e questo mi ha portato alla ricerca di un modo per fare piccole modifiche modulari, piuttosto che provare a ricominciare da zero.
David Stone,

@David Stone Una volta ho partecipato a un progetto, abbiamo fatto la cosa "seleziona la nuova o la vecchia interfaccia". Passò rapidamente all'inferno dello sviluppo: il codice era strettamente associato all'interfaccia e rapidamente il if (m_newInterface)codice spaghetti iniziò ad apparire in tutta la base di codice. Il disaccoppiamento e il refactoring sono durati abbastanza a lungo che, una volta terminato, la maggior parte degli utenti è già passata alla nuova interfaccia (si pensi a più anni).
Vitor Py,

Risposte:


4

Mi limito al fronte tecnico ...

Ti suggerisco di iniziare determinando l'ambiente in cui viene eseguita l'applicazione. "Mainframe" potrebbe significare un paio di cose diverse, data l'età dell'applicazione potrebbe essere CICS o IMS . È anche possibile che gli autori originali abbiano scritto il loro compito iniziato.

A seconda di dove viene eseguita l'applicazione, probabilmente utilizzerà API per quell'ambiente, CICS ora utilizza un'interfaccia marcatamente diversa dai suoi primi tempi, non posso parlare per IMS. Se l'applicazione è un'attività avviata, potrebbe anche avere una sua API interna: trascorro circa sette anni a sostenere una tale bestia, scritta nella stessa epoca.

Qualcos'altro da considerare, data l'età dell'applicazione, è che l'Assembler con cui si desidera integrare il C ++ precede l'esistenza di Language Environment (LE). Pertanto, a meno che l'Assemblatore non sia stato aggiornato per essere conforme a LE, avrai qualche difficoltà dato che C e C ++ sono conformi a LE e richiedono che anche i loro chiamanti e callees siano conformi.

Un altro punto da considerare, se questa applicazione è in esecuzione su un mainframe moribondo, è possibile che si stia cercando di integrarsi con un'applicazione che funziona su hardware e software non supportati. Ciò non sarebbe diverso dal tentativo di integrarsi con un'applicazione scritta nel 1989 che gira su DOS 4.01 sul suo hardware originale.


L'applicazione potrebbe persino utilizzare TPF , il che renderebbe estremamente difficile una conversione.
Gilbert Le Blanc,

13

Stai saltando la pistola. Dalla tua descrizione sembra che tu non abbia compreso appieno l'ambiente tecnico attuale (quale sistema operativo esattamente, dove e come vengono archiviati i dati, esistono interfacce con altri sistemi ecc.). Ma ancora più importante: un piano serio dovrebbe prendere in considerazione alternative a una riscrittura interna parziale o completa del software, vale a dire software standardizzato, esternalizzazione della riscrittura, software come servizio ecc.

Qualunque sia il modo in cui l'azienda va finalmente, ha prima bisogno di una solida analisi di ciò che il software fa oggi e quali sono i requisiti per la nuova soluzione.

Allora perché non ti offri di fare questa analisi?


7
+1 Questa è l'unica risposta che propone un'analisi completa dell'applicazione esistente e requisiti aziendali prima di proporre una soluzione tecnica. Mi ricorda la vecchia battuta: inizi a scrivere codice - andrò a scoprire cosa vogliono.

Questo è un buon punto e ho sicuramente bisogno di maggiori informazioni prima di impegnarmi a fare questo lavoro. Parte del problema è che ho chiesto in giro, e non è stato fino a quando non sono arrivato a un vice presidente della compagnia che ho trovato qualcuno che conosceva davvero tutti i dettagli. Ho chiamato diversi uffici, incluso il supporto tecnico, e nessuno di loro potrebbe darmi dettagli come il linguaggio di programmazione in cui è stato scritto il programma. Tuttavia, ho alcuni motivi per lanciare una soluzione standard, che modificherò in la mia domanda originale.
David Stone,

7

Sono sorpreso che tu abbia avuto una risposta così educata!

Vediamo questo dal loro punto di vista.

Gestiscono con successo un sistema trentennale con probabilmente centinaia di migliaia di righe di codice, interfacce con forse altri venti sistemi che incarna un processo aziendale che si è evoluto nel corso di quaranta anni.

Probabilmente sono / si spera esperti nel loro campo e in quanto tali considererebbero il C ++ un passo in avanti rispetto al "linguaggio di assemblaggio di alto livello" di IBM per dargli il titolo completo. Il linguaggio assemblatore IBM è estremamente potente e il linguaggio "MACRO" è la migliore implementazione di un linguaggio pre-elaborazione / modello di sempre.

Ci sarà stata una proposta per sostituire il loro sistema ogni cinque anni circa da quando è stato implementato per la prima volta. Alcuni sarebbero stati respinti dopo uno studio di fattibilità, alcuni sarebbero arrivati ​​fino alla fase di progettazione prima di aver perso il budget, alcuni potrebbero anche essere entrati nel codice e magari testare la fase prima che colpissero problemi di prestazioni e venissero inscatolati.

Il C ++ semplicemente non sarebbe d'aiuto. Non esiste una libreria grafica nell'ambiente in cui l'applicazione viene eseguita. (Esiste una libreria grafica 3270 ma è improbabile che sia supportata in C ++ poiché nessuno la utilizza, e c'è una libreria client "X" completa ma è necessario trovarsi in un ambiente diverso per usarla.)

Hanno un'interfaccia utente tutt'altro che perfetta ma che è ben nota e veloce. Un operatore esperto compilerà un modulo circa tre volte più veloce utilizzando uno schermo verde anziché una GUI equivalente. Inoltre possono prestare attenzione al cliente mentre toccano il tipo.

Gli operatori dello schermo avranno bisogno di formazione su qualsiasi interfaccia utilizzino, riqualificare tutti i loro dipendenti per utilizzare una nuova e sconosciuta GUI sarebbe un enorme elemento di bilancio rispetto al solo addestramento dei nuovi dipendenti sul vecchio sistema mondano.


4

Ho avuto un problema simile alcuni anni fa a BellSouth. Ho semplicemente scritto il codice COBOL per scansionare i programmi in linguaggio assembler byte per byte, separare i codici operativi e gli operandi, convertire le istruzioni di diramazione per andare a termine e convertire le istruzioni di confronto in IF. Questo programma ha convertito le istruzioni DC nell'equivalente codice Divisione dati COBOL e ha convertito mosse, zaps, ecc., A seconda dei casi.

Una volta fatto ciò, ho scritto un secondo programma per convertire IF e GOTO in IF-THEN, con mosse e simili nelle linee tra questi cluster (non era poi così difficile da fare: il segreto è inserire IF e ELSE mentre rileggi il cobol "pidgin" di 1a fase da dietro a davanti).

IF-THEN-ELSER ha cercato situazioni in cui ha trovato un riferimento GOTO nelle immediate vicinanze di un'etichetta, che poteva essere tranquillamente eliminato (diminuendo il numero di riferimenti di 1). Esegui questo programma IF-THEN-ELSER in modo iterativo (ovvero lo esegui ancora e ancora, fermandoti solo quando l'ultimo passaggio non riesce a trovare un modo per apportare ulteriori modifiche). La maggior parte del lavoro critico viene svolto da questo if-then-elser, il cui prodotto COBOL deve essere attentamente esaminato e verificato da un programmatore esperto e competente in linguaggio assembler (ovvero io). Nella mia esperienza, il mio "if-then-elser" è stato in grado di eliminare oltre il 90 percento dei GO TO risultanti dalle istruzioni di filiale originali.

Suppongo che da questo punto sia possibile andare avanti con una semplice conversione in C (o C ++) - lingue con cui sono anche a conoscenza. Tuttavia, in BellSouth, la nostra lingua target scelta era COBOL / II. C'è sempre un po 'di complessità che deriva da situazioni in cui un'etichetta rimanente ha più riferimenti GO TO (molte volte, queste situazioni sono gestite da COBOL PERFORMs, ma a volte possono essere semplicemente rappresentate da costrutti OR ed AND).

Penso che sia bello produrre codice in COBOL / II elegantemente strutturato a blocchi, con VALUTAZIONI (costrutti Case) e 88 nomi di condizioni di livello. L'aggiunta di questi ultimi ritocchi ha portato a un'altra coppia di programmi, che si è rivelata utile su programmi COBOL che non provengono da programmi convertiti da assembler.

Non so se questo aiuta.

Come altri hanno già commentato, devi condurre questo processo con cura. Aiuta ad avere 10-12 anni di esperienza nella codifica dell'assemblatore per informare sui processi decisionali. Noi che abbiamo quell'esperienza è difficile da trovare.

Come nota finale: all'epoca scrivevamo solo in assembler perché i compilatori per i linguaggi di alto livello producevano un codice oggetto ingombrante e inefficiente. I compilatori COBOL "ottimizzati" di oggi non hanno le stesse cattive abitudini. ----------


2

Il consiglio di Joel è generalmente valido, ma in questo caso è attesa una riscrittura completa. Idealmente, una riscrittura con una ascia da battaglia, poiché quello che stai trattando qui è un mostro.

Non sono sicuro di cosa aggiungere esattamente, dal momento che hai già fatto una buona argomentazione per questa riscrittura. La mia unica raccomandazione sarebbe quella di saltare completamente C ++ e andare direttamente a un'interfaccia web per il sistema di noleggio, poiché probabilmente sarà ancora più facile addestrare i lavoratori e ti farà risparmiare molto lavoro sull'interfaccia utente (oltre a rendere è molto più facile ottenere nuovo sangue nel progetto, o anche semplicemente esternalizzare il tutto).

Per quanto riguarda i programmatori COBOL esistenti, forse possono aiutare con la documentazione del sistema esistente e con il processo di migrazione.


2
+1: questo non è un lavoro per C ++
6502

2
@ 6502: Perché no? L'esperienza del PO è in C ++. Capire come gestire un vecchio sistema è abbastanza male. Imparare un'altra lingua non aiuta. Un programmatore competente che utilizza strumenti di cui il programmatore è competente sarà in grado di farlo funzionare molto meglio del vecchio sistema, indipendentemente dalla lingua.
In silico,

1
@In silico: Secondo me per un progetto abbastanza grande di queste dimensioni risparmieresti tempo imparando un linguaggio più appropriato come ad esempio Python che usando C ++. Supponendo che Python non ci fosse, per un progetto abbastanza grande di questo tipo, IMO pagherebbe scrivendo il tuo Python in C ++ e codificandolo usando quello invece di fare tutto in C ++. Il C ++ è un linguaggio molto carino e il suo punto di forza è che in base alla progettazione non vuole lasciare alcuno spazio sotto C ++ e sopra assemblatore. Totalmente inutile qui. Consiglieresti di scrivere tutto usando FPGA se quella fosse l'area di competenza del poster?
6502

3
@ 6502: non sono d'accordo. Con una tecnica adeguata e moderna, librerie ben progettate e competenza nella lingua, tutte queste questioni sono irrilevanti. (Questo è vero per qualsiasi linguaggio, ovviamente.) E le persone hanno sviluppato sistemi e software su larga scala in C ++ che funzionano bene e non sembrano avere problemi con l'uso di C ++. Solo perché si non usa C ++ per questo lavoro non significa che gli altri non sarebbero in grado di usarlo e usarlo bene. Spetta all'OP decidere. Sono sicuro che sei abbastanza produttivo in altre lingue, e continua a farlo.
In silico,

1
In silico: chiaramente in teoria qualsiasi cosa può essere implementata con qualsiasi cosa (incluso brainf k). Ciò non significa che tutti gli strumenti siano equivalenti. Penso che per un'applicazione business con codice semplice da scrivere e da leggere (anche da persone non tecniche) sia molto più importante della semplice velocità di elaborazione. Anche qualcosa come un comportamento indefinito è un prezzo troppo alto per pagare per la vicinanza non necessaria al metallo. Se per te C ++ è una buona scelta per la logica di business un'applicazione di immissione di dati, allora mi chiedo se per te c'è qualcosa per cui C ++ è una cattiva scelta ...
6502

2

Per quanto riguarda l'aspetto tecnico, molto dipenderà dalla qualità - la modularità - del codice dell'assemblatore. Alcuni programmatori hanno compreso l'importanza di creare moduli con funzioni specifiche limitate e un'interfaccia parametrica chiara e semplice, utilizzando convenzioni di collegamento di subroutine IBM standard. La grande maggioranza, tuttavia, tendeva a creare mostruosità monolitiche.

Con il primo, il riutilizzo è possibile e non dovrebbe essere così difficile elaborare la "colla" tra C ++ e assemblatore, supponendo che i moduli assembler utilizzino sequenze di chiamata standard (o almeno coerenti). Con ogni probabilità, tuttavia, il codice assembler sarà un casino. Sebbene sia stato possibile scrivere assemblatore strutturato, pochissime persone lo hanno fatto e sarà quasi impossibile discernere qualsiasi "progetto" da cui iniziare a riscrivere.

D'altra parte, l'assemblatore 360/370 è piuttosto di alto livello rispetto ai microprocessori di oggi, e molto più semplice, e C è talvolta considerato "assemblatore di alto livello". Ho lavorato per una società DBMS il cui prodotto era interamente 370 assemblatore e il nostro architetto principale riteneva che fosse possibile tradurre automaticamente il codice dell'assemblatore in C (per portabilità futura). Sono scettico, ma il punto è che la distanza non è grande come potresti pensare.

Non so se nulla di tutto ciò sia utile. Come ho detto, penso che dipenda fortemente dalla qualità e dalle dimensioni del codice originale.


1

Non riesco a capire se si tratta di uno scherzo o no: la tua azienda sta eseguendo seriamente un codice scritto originariamente 39 anni fa? Se è in esecuzione su un System / 360, dovrai compilare g ++ dal sorgente ...

Onestamente, non avrei nemmeno pensato di usare nessuno dei vecchi codici; devi adottare un nuovo approccio, sederti e pensare a ciò che deve andare nel design e farlo da zero. Sì, implicherà un bel po 'di pianificazione, ma non credo che nemmeno Joel direbbe che questo è un caso di cambiamenti incrementali.

Per quanto riguarda la persuasione dell'azienda che è necessario cambiare, è necessario indicare ragioni specifiche che miglioreranno l'efficienza, porteranno a costi inferiori e / o dimostrano che ciò che si sta utilizzando ora sta danneggiando i profitti in questo momento.

Un altro commento: immagino che altre compagnie di autonoleggio si siano unite a noi nel 21 ° secolo; Vorrei fare un po 'di ricognizione per vedere come lo stanno facendo (basato sul web, immagino), e possibilmente modellarlo su uno di quei sistemi (cioè non reinventare la ruota).

In bocca al lupo!


5
Non è insolito che i sistemi mainframe utilizzino le basi di codice iniziate negli anni '60 o '70. IBM mantiene i loro mainframe zSeries e il sistema operativo all'indietro compatibili con il 360 solo per questo. Non c'è molto nel modello di business di una società di autonoleggio (o una banca o una compagnia di assicurazioni) che è cambiato da allora. È possibile aggiungere un'interfaccia Web, certo, ma cosa è cambiato nel modo in cui si memorizzano le auto nel database?
Bo Persson,

zOS ha un compilatore C ++ nativo completo di pre-processori per CICS e DB2. Quindi non è necessario per g ++.
James Anderson,

5
In secondo luogo, è abbastanza comune per le grandi aziende eseguire codice mainframe di 30 anni. È generalmente affidabile, performante e fa il lavoro. Inoltre tende ad essere molto mal documentato.
James Anderson,

3
@Chris, perché il codice di 39 anni non dovrebbe essere eseguito? Cresce a 30 anni? 20? Il codice di produzione testato in battaglia può essere vecchio ma funziona perfettamente. Qualsiasi riscrittura deve arrivare allo stesso livello del vecchio programma prima che abbia alcun beneficio per quello che paga le tue tasse.

1
@ Chris, molto poco è più veloce di un'applicazione ben scritta "schermo verde", e lo so per esperienza personale di essere il ragazzo Java in un negozio Cobol. Sinceramente credo che tutti voi sinceramente sottovalutiamo la quantità di lavoro necessaria per avere un'applicazione simile. Inoltre, il codice non arrugginisce. Solo essere vecchi non è un motivo sufficiente per risolverlo.

0

In teoria non dovrebbe essere difficile convincere i dirigenti a sostituire il vecchio sistema se si può mostrare loro che li salverà megabucks. E lo farà. Sarà sempre più difficile trovare programmatori per mantenere questo sistema, e quei programmatori diventeranno sempre più costosi. Non è una questione di "se", è una questione di "quando". Deve davvero essere aggiornato.

Tuttavia, la domanda è se puoi convincerli non solo che ha bisogno di essere aggiornato (e probabilmente lo sanno comunque), ma che dovrebbe essere un progetto interno. Soprattutto se la squadra sei solo tu. Abbastanza spesso un sostituto così importante è esternalizzato. Potrebbero anche essere disponibili alcuni software pronti all'uso da prendere in considerazione. Queste opzioni devono essere esaminate e i tuoi manager insisteranno che ciò accada se sono ragionevoli.

Per quanto riguarda il compito, se dovessi farlo, in realtà credo che una riscrittura di bulldoze possa essere appropriata in questo caso. L'argomento di Joel non si applica in tutti i casi. Tuttavia non potrei davvero saperlo senza vederlo.


0
  1. Una modifica incrementale è fuori discussione.

  2. È probabile che sia disponibile una soluzione standard. Ci sono molte compagnie di autonoleggio.

  3. Se, come ultima risorsa, è necessario riscriverlo, passare prima un po 'di tempo a pensare a come funzionerà il nuovo sistema.
    Dopo aver identificato la funzionalità e le interfacce, puoi scegliere gli strumenti di sviluppo che si adattano meglio alle esigenze (e alle tue competenze).

Una strategia per ridurre al minimo lo stress per gli utenti finali è quella di iniziare a emulare la vecchia e brutta interfaccia che gli utenti conoscono, con alcune bellezze come elenchi a discesa per brutti mnemonici, quindi aggiungere gradualmente la funzionalità dell'interfaccia utente e ridurli a un'interfaccia utente moderna.

Probabilmente non vorrai mantenere lo stesso formato di file di dati, quindi non sarà più possibile tornare indietro una volta passati.


1
Se non lo fai in modo incrementale, molto probabilmente il progetto fallirà.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.