Nel complesso: come manterremo i sistemi legacy? [chiuso]

Un problema chiave relativo al mantenimento di sistemi legacy è la mancanza di persone che a) sono in grado di accelerare tali sistemi eb) disposti a continuare a mantenerli.

Recentemente ho fatto una domanda in modo simile riguardo ai giovani programmatori che erano interessati ai mainframe. Il consenso si è spinto verso il no.

Il mantenimento dei sistemi legacy è considerato un suicidio di carriera. In molte aziende in cui vigono regole di inerzia, vi sono pochi investimenti nella formazione del personale per rimanere al di sopra di tali sistemi, portando a singoli punti di errore dal lato del personale. Molte persone che conosco che lavorano su sistemi simili cercano rotte perché non vedono alcun futuro a lungo termine nei sistemi e vedono solo un danno alla carriera.

In alcuni settori, le normative sulla manutenzione dei dati possono essere un fattore chiave per garantire che i sistemi legacy siano ragionevolmente sorvegliati. Questo è particolarmente il problema nel settore finanziario, penso. Tali regolamenti - per quanto ne so - sono generalmente limitati nel tempo.

Tuttavia, penso che in pratica, ciò che accadrà è:

There will come a point on the graph where the cost of cutting over to a more modern system which allows you to route around the disadvantages of a legacy system will fall to below the cost of maintaining the legacy system because it is cheaper.

Al momento, IBM sta vendendo molti mainframe e stanno lavorando molto duramente per garantire che le loro grandi macchine non escludano parti di giovani professionisti. Ma non penso che sia abbastanza in questa fase. Hanno alcuni USP in termini di emissioni di anidride carbonica e potenza di elaborazione effettiva.

Tuttavia, per ogni persona che acquisterà un mainframe IBM perché è possibile eseguire Linux su di esso, costa meno energia elettrica ed è molto efficiente, ne avrai molti altri che sceglieranno una server farm perché sono più familiari con quel mondo e così tanti altri programmatori.

In fin dei conti, molto dipende dal settore in questione. Lavoro in un particolare settore che è stato molto dipendente dai mainframe per anni e anni e sono ancora ampiamente in uso. Ma le soluzioni ospitate stanno diventando più popolari e consentono il consolidamento delle competenze in aziende più grandi, eliminando alcune delle problematiche affrontate dalle singole aziende in termini di punti di errore e, inoltre, alcuni fornitori guardano con molta attenzione a soluzioni basate su non mainframe per i problemi inerenti a quell'industria

Quindi, in sintesi, quello che sto dicendo è che, in generale, ci sarà un passaggio verso la migrazione dai sistemi legacy non appena un punto di manutenzione economica contro la migrazione cadrà a favore della migrazione. Sarà, tuttavia, in gran parte invisibile a molte persone perché non è nuovo e funky e non ha un volto molto pubblico nel modo in cui fa un next-big-thing. Tale migrazione potrebbe essere rivolta ai fornitori di servizi o alle nuove tecnologie (in particolare laddove i fornitori di servizi sono quelli direttamente interessati).

La mia esperienza, in particolare nelle reti, è che è necessario rimuovere la dipendenza dai sistemi legacy.

La maggior parte delle aziende sono già ignoranti del debito tecnico e non si rendono nemmeno conto che le cose vanno male fino a quando non letteralmente crolla intorno a loro e li manda in bancarotta (se mai arriverà a quel punto). In realtà ho visto visto e non è stato bello; ciò che ha reso peggio è stato il fatto che ho ripetutamente cercato di sensibilizzare gli imprenditori sul crescente debito tecnico e che avrebbe dovuto essere risolto, e ogni volta è stato rifiutato a causa della riluttanza a dedicare il tempo e le risorse necessari per risolvere esso. Il risultato finale è stato dopo oltre 10 anni che il sistema è fallito in modo catastrofico (dopo che me ne ero andato) e non potevano riprendersi, e sono falliti, perché erano troppo stupidi per rendersi conto in quei dieci anni che spendere un po 'di soldi per risolvere il problema sarebbe stato meglio che ignorarlo del tutto. Potrei lamentarmi per ore della stupida assurdità di quella compagnia, e ciò che mi ha addolorato di più è che avrebbe potuto essere evitato del tutto se i proprietari non fossero solo per fare un soldo veloce tagliando tutto il resto del tutto.

È faticosamente difficile cercare di dire a un'azienda se i loro sistemi sono scritti male e hanno bisogno di un pesante refactoring (se non di una riscrittura totale che è normalmente il caso perché è così male). La maggior parte delle volte ti abbatteranno anche se li avvertirai che è difficile apportare modifiche o aggiungere nuove funzionalità (nel modo giusto, voglio dire, non solo stratificare più cazzate sulla pila), o addirittura considerare tu un danno per il business perché vedi problemi con il sistema nel suo stato attuale.

Sono onestamente giunto alla conclusione che si tratta di una battaglia persa, e non vale la pena di combattere. Le persone abbastanza intelligenti da sapere del debito tecnico non hanno bisogno di sentirsi dire due volte al riguardo e sono consapevoli dei pericoli fin dall'inizio, e tutti gli altri non ascolteranno alcun tipo di motivo o avviso finché non sarà comunque troppo tardi. L'opzione migliore (e ovviamente la più irrealistica) sarebbe quella di consentire la selezione naturale e lasciare che le persone ignoranti si estinguano, lasciando solo quelle intelligenti. Non conosco un modo più semplice di gestirlo, perché tutto ciò che ho provato personalmente in passato è stato ignorato completamente, ha ridotto il mio valore agli occhi della compagnia (per "lamentarsi") o persino ha portato alla mia interruzione perché ero "troppo concentrato" nel correggere "ciò che non è rotto", quando in realtà era rotto e nessun altro aveva il giusto stato d'animo per vederlo rotto.

The miles of tubes, wires and iron beneath New York and other U.S. cities are getting older and could become dangerously unstable.

Per l'aneddoto, lo stesso argomento è stato fatto a Parigi nel 16-17 ° secolo. Al di sotto di essa sono stati scavati così tanti buchi e gallerie (oltre ai buchi naturali dovuti alla geologia dell'area) che un edificio occasionale si sarebbe sgretolato.

Quando interi blocchi di città crollarono nel terreno, furono date direttive per riempire le cavità e i tunnel non necessari con ghiaia e ossa (avevano anche problemi di cimitero sovraffollati). La città è sopravvissuta fino a quando non è stato inventato il cemento.

Il mio punto qui è che molte organizzazioni tendono ad attendere l'ultimo minuto per eseguire la manutenzione del software, ma i programmatori (come gli ingegneri civili) svolgono molto, velocemente e bene.

Siamo sopravvissuti al bug di Y2k. Il bug Y2036 costringerà molte organizzazioni ad aggiornare il proprio hardware e software. Il mondo potrebbe finire nel 2012. Ma gli informatici non sono sociologi o critici letterari .

Oh, e come dice il proverbio nel frattempo: scrivi il codice come se il prossimo manutentore fosse uno psicopatico feroce che sa dove vivi.

Ho dimenticato, cosa consideriamo il codice legacy in questi giorni? Il codice dell'anno scorso, il codice dell'ultimo decennio o il codice del secolo scorso?

Il denaro guida la conversazione sulla manutenzione dei sistemi legacy. Il debito tecnico prende la forma di un aumento dei costi per cambiare il sistema.

Ho lavorato con sistemi progettati male e progettati in modo intelligente. Ciò che è interessante è che i costi per mantenerli non variano di molto. I maggiori problemi sono le architetture non corrette per l'uso corrente, che di solito si manifestano in problemi di ridimensionamento o quando si desidera un cambiamento importante. Non converti facilmente un'area principale di codice da singolo thread a multi-thread.

I problemi più significativi che ho riscontrato sono i linguaggi di sviluppo utilizzati. I sistemi più vecchi sono scritti in lingue meno popolari oggi, quindi è necessario addestrare di più o assumere risorse più costose (costose) e rare. In entrambi i casi, a causa del pool più piccolo, si fatica anche a trovare individui esperti che tendono a portare tanti problemi quante soluzioni.

Per quanto riguarda la riscrittura promessa, la maggior parte dei sistemi che hanno avuto enormi investimenti non giustificano una riscrittura. È incredibile quanto tempo il software possa essere mantenuto funzionante e migliorato. I cambiamenti hardware (alcuni sistemi supportati dalla mia azienda utilizzano hardware specializzato) tendono ad essere il nostro più grande problema. La capacità di migliorare è spesso limitata solo dai meccanismi per integrare il codice legacy con nuove funzionalità.

Questo è già un grosso problema. E non mostra segni di cambiamento.

Negli anni '60 e '70 le grandi istituzioni di ogni tipo sono passate dal fare contabilità su carta al fare contabilità sui sistemi informatici. Stranamente hanno scelto COBOL. La maggior parte sta ancora utilizzando versioni aggiornate di questi sistemi COBOL. Vedi link per alcune statistiche su questo

Ogni tanto riceviamo dei richiami casuali a questo, come quando Arnold Schwarzenegger scoprì un paio di anni fa che non poteva semplicemente tagliare la paga di 200.000 lavoratori statali senza 6 mesi di sviluppo prima (vedi link per la verifica).

Considerati i rischi del passaggio, è molto difficile giustificare il cambiamento di questi sistemi. Mai. Questa è stata la realtà per la mia vita. Ma non vedo alcuna ragione per cui questo fatto cambi nella vita dei miei figli. O anche la durata dei loro figli.

Ho amici che hanno mantenuto il codice che è più vecchio di loro. Ho un amico che è tornato in una compagnia 30 anni dopo aver lavorato lì la prima volta, per scoprire che i suoi programmi erano ancora in esecuzione, invariati, in un lingua che non ricordava nemmeno!

Lasciami terminare con una storia vera di ciò che entrambi possono accadere.

Negli anni '70 è stata fondata una azienda per fornire un mercato online per commercianti. Il PDP-11 era un buon rapporto prezzo / prestazioni per loro, quindi l'hanno scelto. Stavano spingendo i limiti delle prestazioni di una macchina, quindi hanno scritto il loro sistema in un assemblaggio PDP-11 altamente ottimizzato. Pochi anni dopo, il PDP-11 smise di essere venduto. Comunque gli affari andavano bene, le macchine duravano e le sostituzioni di seconda mano erano facili da trovare. Hanno mantenuto la loro piattaforma. Alcuni anni dopo che le sostituzioni divennero più difficili da trovare. È stato fatto un grande progetto per sostituire la piattaforma di trading. E 'fallito. Ci hanno provato di nuovo. E fallito di nuovo. Una delle principali cause del fallimento era che nessuno sapeva come funzionava il sistema di trading, e nessuno poteva più leggere l'assemblaggio del PDP-11. Poi ha colpito la salvezza. Qualcuno ha creato un assemblatore PDP-11 che girava su Linux.

Così, nel 2000, gli scambi commerciali in miliardi di dollari / anno sono andati a macchine Linux, su un ponte ethernet-decnet, per emulare macchine PDP-11 che eseguivano il commercio su un sistema software che era scritto in alta gruppo PDP-11 ottimizzato. Per velocità.

Non ho avuto alcuna connessione con la società negli ultimi dieci anni. Quindi non posso dirti se sono ancora in esecuzione su PDP-11 emulati. So che la decimalizzazione stava comprimendo i loro margini dolorosamente, quindi avevano ancora un altro sforzo per migrare. (Ho solo imparato la storia perché ho intervistato diverse persone che erano state licenziate da lì, e ho chiesto cosa fosse successo.) Comunque, visti i precedenti fallimenti, darei il meglio delle probabilità che non abbiano sostituito con successo quel sistema.

Sembra una preoccupazione molto genuina dal punto di vista dell'utente. Affinché il marciume sia ritardato o, meglio, evitato, il software in questione deve essere libero dai suoi ceppi. I suoi editori dovrebbero aver impostato il codice sorgente libero o essere nel business della manutenzione e dell'aggiornamento delle fonti fino a quando il suo ultimo utente smette di usarlo. Altrimenti, ci sono ottime possibilità che potrebbero andare fuori mercato a causa di simili marciumi nel mondo degli affari, lasciando così il software completamente aperto ai rots.

Vale a dire, la durata della durata dei diritti d'autore del software e la limitazione delle licenze dovrebbero essere molto brevi, al termine dei quali il software e il suo codice base diventano di dominio pubblico e rimangono lì. In questo modo, è possibile per l'utente continuare a aggiornare i sorgenti o assumere qualcuno per farlo, ritardando e / o evitando i marcatori.

Oppure, se sei un po 'aperto all'idea del software libero, potresti scrivere i tuoi programmi con una licenza libera come AGPL o GPL o altre licenze di software libero. Da quello che ho visto, quando le fonti di un software non attraggono più gli sviluppatori per migliorarlo, per qualsiasi ragione, la base di partenza viene cannibalizzata e riprende vita. I pacchetti nel sistema operativo Debian tendono a seguire questo ciclo di vita, per quanto ho visto.

Avendo supportato una varietà di applicazioni governative e del settore privato, direi che la maggior parte delle aziende e almeno il governo degli Stati Uniti sono ben consapevoli dei pericoli di lasciare marcire il codice e non rimanere al passo con le ultime tendenze in materia di sicurezza.

Dobbiamo regolarmente ottenere il nostro software certificato per varie suscettibilità e la maggior parte dei sistemi elettronici governativi, anche quelli vecchi, ottengono aggiornamenti regolari per mantenerli al sicuro.

Ovviamente ci sono delle eccezioni e gli hacker sono sempre in movimento, ma nel complesso penso che le persone siano abbastanza consapevoli che non puoi semplicemente buttare qualcosa là fuori e non toccarlo più.

Attenzione: questo sarà un po 'in forma libera ...

Penso che ci siano 2 modi per considerare la tua preoccupazione.

Se ci pensi, alcune navette spaziali e satelliti hanno eseguito lo stesso codice che li aveva originariamente lanciati. D'altra parte, alcuni sono stati progettati per essere aggiornati anche se sono (molto) remoti.

Ciò che conta è l'ambiente. Ovviamente, finché non si modifica l'ambiente, il codice non diventerà obsoleto. In questo caso, il codice rot non esiste realmente: il codice stesso (o il file binario prodotto) non può marcire. Potrebbe rompersi se inizi ad attaccarlo da un'angolazione completamente diversa. Non è che sta marcendo, è che non si sta adattando al suo ambiente. Pensala come un problema evolutivo.

Ma il nostro ambiente cambia. E in qualche modo, qual è la chiave del tuo problema è anche la soluzione. Il nostro ambiente cambia così velocemente che al giorno d'oggi non ci aspetteremmo che una soluzione software non si evolva nel tempo. Trascuriamo i progetti software che non sono stati aggiornati nell'ultimo anno e si lamenteranno del prodotto e dell'assistenza clienti che non fornisce una roadmap chiara. E anche quando questo funziona bene - ottieni una chiara roadmap, un buon supporto, aggiornamenti regolari ... - c'è sempre la possibilità che uno sfidante emerga, con una crescita esponenziale. Spesso commettiamo l'errore di pensare che le grandi aziende consolidate domineranno sempre, proprio perché dominano. Tuttavia, allo stesso modo l'elemento dominante in una mandria invecchia, il software / hardware super-massiccio / qualsiasi venditore invecchia. O solo un po 'pigro. E uno sfidante arriva e gira le cose ancora più velocemente di quanto il dominante dominante possa averlo fatto 5 o 10 anni prima. Oppure il dominante subirà un bel colpo, sopravvivendo a malapena mentre vediamo un'interruzione nel mercato (economicamente parlando, con impatti su campi diversi), e poi le cose andranno avanti. Forse sembra imperfetto, ma di per sé è un processo organico.

Quindi, dal punto di vista dell'utente, credo che il problema non sia così grande. La decomposizione del codice non avverrà dal punto di vista dell'utente, poiché utilizzerà un'alternativa (possibilmente con una transizione / migrazione senza soluzione di continuità ... si spera).

Ora assumendo che non stiamo vedendo le cose dal punto di vista dell'utente, o che stiamo parlando di un sistema che è immune - per ragioni sconosciute, sviluppo governativo, viaggi spaziali, ecc ... - alla concorrenza e è pensato per essere costruito per sopravvivere / sopravvivere per un tempo molto lungo, abbiamo bisogno di guardare i testi che hai fatto riferimento. E probabilmente un po 'più di letteratura sui sistemi affidabili e sul sistema fault-tolerant. Anche se probabilmente vorremmo spingerci oltre. Non vogliamo solo tolleranza ai guasti, vogliamo sistemi evolutivi.

Il problema con l'evoluzione è che introduce cambiamenti e cambiamenti introducono punti di errore. Diamo un'occhiata a questi ora e a cosa possiamo fare per affrontarli.

Possiamo ancora fare affidamento sulla metafora infrastruttura / architettura / ingegneria mentre lo facciamo (dopotutto, siamo tutti noi stessi ingegneri del software, anche se non c'è probabilmente nulla di simile all'ingegneria del software ... per ora). C'è un motivo mentre il sistema a valvole è ancora attivo (con alcuni problemi), mentre il Big Ben funziona ancora (con alcuni difetti) o la Torre Eiffel è ancora in piedi. È perché facciamo con elementi vitali (o non così vitali) di un'infrastruttura cosa dovremmo fare con il software altrettanto bene: ispezione continua. Queste entità non erano necessariamente progettate per durare così a lungo, ma hanno beneficiato di una supervisione permanente e di miglioramenti e riparazioni tempestivi quando era necessario. Chiama il tuo hotfix se lo desideri.

D'altra parte, alcuni progetti erano pensati per durare, e funzionare senza interruzioni, anche sapendo che l'ispezione continua non sarebbe possibile. In questo caso ci rivolgiamo verso un buon design e modelli formali. Elementi di affidabilità (disponibilità, affidabilità, sicurezza, integrità, manutenibilità) possono essere quantificati - per un determinato ambiente. Le statistiche fanno il resto per pianificare il resto e il futuro. Il che porta la domanda: è persino possibile per noi costruire sistemi che saranno evolutivi, nel vero senso della parola?

Jeff Langer in Clean Code fa una domanda simile ... senza riferimenti alle pipe a vapore:)

What if there were four simple rules that you could follow that would help you create good designs as you worked? What if by following these rules you gained insights into the structure and design of your code, making it easier to apply principles such as SRP and DIP? What if these four rules facilitated the emergence of good designs?

Many of us feel that Kent Beck’s four rules of Simple Design are of significant help in creating well-designed software.

Secondo Kent (in Extreme Programming Explained), un design è "Semplice" se segue queste regole:

• Esegue tutti i test
• Non contiene duplicati
• Esprime l'intento del programmatore
• Riduce al minimo il numero di classi e metodi

Per poter eseguire tutti i test ... abbiamo bisogno di test da eseguire e questo è un enorme indicatore del debito tecnico. Ad esempio, se ci sono 10.000 casi di test in un sistema come Mercury Quality Center e nessuno di questi test sono automatizzati, questo è un chiaro indicatore del debito tecnico che è stato accumulato.

Ed è qui che entra in gioco Feathers e il suo libro "Working Effectively with Legacy Code".