Nuove e vecchie tecnologie coesistono nel sistema legacy [chiuso]

1. il problema esiste già:

   Personalmente, non ritengo che le maggiori difficoltà di manutenzione siano rilevanti alla luce dei progetti moderni, che contengono già dozzine di parole chiave tecnologiche (programmazione poliglotta, database, cosa-hai). Allo stesso tempo, non mi aspetterei che qualcuno di nuovo nel progetto sia in grado di eseguire facilmente la manutenzione . Non andranno in giro a conoscere comunque queste tecnologie.

2. non tutti hanno bisogno di sapere tutto:

   Ora, naturalmente, la parte di apprendimento potrebbe essere ridotta non introducendo un'altra tecnologia. Tuttavia, non è così male come sembra, perché i sistemi legacy di grandi dimensioni (e sono in genere di grandi dimensioni, poiché altrimenti verrebbero riscritti in altro modo) di solito vengono modificati solo in questa parte o in quello per correggere un bug o aggiungere una nuova funzionalità. E non devi capire tutto il resto per averlo fatto.

3. migliorare è un must:

   Il punto più strong a favore dell'aggiunta di nuove tecnologie è che semplicemente non puoi permetterti di stare con tecnologie obsolete. Se questo sistema legacy merita qualcosa per la tua azienda, molto probabilmente non andrà via nei prossimi 5-10 anni. Ciò che rende estremamente difficile la manutenzione è usare solo vecchie tecnologie. Non è solo che quelli nuovi ti semplificano la vita, ma immagina di dover mantenere l'intero sistema in Assembler. Ora considera anche che l'ingegnere capo che sa tutto potrebbe non esserci più (colpito da un autobus, ha ottenuto un'offerta migliore, qualunque sia la ragione) - puoi ancora trovare persone sul mercato che conoscono questa vecchia cosa X? Anche solo guardando il mercato di oggi, scoprirai che soprattutto i neolaureati (che sono i più facili ed economici da noleggiare) avranno in genere almeno qualche esperienza JSON, ma solo pochissimi avranno visto SOAP.

   Inoltre, il tempo che le nuove tecnologie risparmiano è altrettanto rilevante, perché il time-to-market è fondamentale nella maggior parte dei mercati attuali. Se ci si attiene alle vecchie tecnologie e ci vuole semplicemente molto più impegno, è necessario molto più tempo - che a un certo punto si legge troppo tardi . A quel punto, avrai un sistema legacy, di cui non puoi fare a meno, ma che non puoi anche migliorare e adattare abbastanza velocemente - in altre parole: tutto ciò che dipende da questo sistema andrà lentamente in malora.

4. definire una roadmap:

   Infine, è importante avere una sorta di tabella di marcia che tenga conto delle tecnologie del proprio sistema e che tutti i membri del team ne siano pienamente consapevoli. Se hai deciso che JSON sostituisce il tuo SOAP, ma non puoi ancora farlo, assicurati almeno che tutti sappiano che le nuove cose dovrebbero essere fatte con JSON e non con SOAP. In questo modo, a seconda delle dimensioni delle funzionalità che si aggiungono, è possibile sostituire in modo incrementale sempre più sottosistemi che hanno utilizzato SOAP fino a un punto, in cui è possibile definire un ETA per quanto tempo occorrerebbe per rimuovere completamente SOAP dal sistema . A seconda della criticità aziendale del sistema, potresti anche decidere di dedicare il tempo esclusivamente alla progressione della tua roadmap tecnologica. Lo chiamerai ripulendo gli angoli tecnologici oscuri e polverosi del sistema - ai manager sarà conosciuto come garantendo la base competitiva del sistema e rendendolo a prova di futuro .

Ci sono molte variabili che dovrebbero essere considerate quando si decide di aggiungere nuove tecnologie a un'applicazione legacy.

Innanzitutto, qual è il piano a lungo termine per questa applicazione? C'è un piano con soldi e una data per ritirarlo? In tal caso, la nuova tecnologia introdotta si riferisce a ciò che sta sostituendo la vecchia app? Se è così, ottimo, vai avanti. Se no, allora perché stai introducendo questa tecnologia? Le vecchie app non sono parchi giochi: di solito servono uno scopo critico in un'organizzazione (sono spesso le prime app create in un'azienda e, di conseguenza, sono fondamentali per la salute finanziaria dell'azienda).

In secondo luogo, qual è la curva di apprendimento della nuova tecnologia? Il tuo popolo è pronto per questo? Ad esempio, diciamo che hai una vecchia applicazione scritta in COBOL / IMS / CICS. È piuttosto improbabile che tu possa trasferire rapidamente le persone che stanno lavorando su questo per dire HTML5 / CSS3 / Javascript / JSON / REST / NoSQL in un breve periodo di tempo. Allora, qual è la tua strategia della forza lavoro? Ne hai uno? Non può essere "lo impareranno mentre vanno". Questo è irresponsabile e rischia di tradire lo staff.

In terzo luogo, sai dove si trova questa nuova tecnologia nella sua fase di diffusione dell'innovazione? Probabilmente la cosa peggiore che puoi fare a un'applicazione legacy è gravarla di innestarla con una "nuova" tecnologia che è già in fase di adozione a maggioranza o ritardo. Perché? Perché tra due anni avrà DUE vecchie tecnologie morenti sotto il suo ombrello, quindi è effettivamente peggiorato. Cerca di limitare le tue introduzioni tecnologiche alle cose all'inizio o alla fase iniziale della maggioranza.

Quarto, quante persone stanno ONESTEmente contribuendo alla salute e al benessere della nuova tecnologia? Ad esempio, se vai a GitHub, quanto sono frequenti i commit e quanto sono importanti questi commit? Ancora una volta, non caricare un'app legacy con una tecnologia morente solo perché è "nuova per te".

Ci sono probabilmente molte altre cose da considerare, ma quelle sono alcune che vengono in mente sulla base dei miei anni di architetto che hanno preso questo tipo di decisioni.

Non solo è ragionevole, è spesso inevitabile e in effetti può essere un utile "piede nella porta" per abbandonare completamente le tecnologie legacy. Ciò ovviamente presuppone che vi sia un vantaggio in termini di costi per abbandonare le vecchie tecnologie in primo luogo, cosa che potrebbe non esserci.