Quando il codice è "legacy"? [chiuso]

Sono piuttosto parziale a Riepilogo di Wikipedia personalmente:

A legacy system is an old method, technology, computer system, or application program that continues to be used, typically because it still functions for the users' needs, even though newer technology or more efficient methods of performing a task are now available.

Molto di ciò che gli altri stanno descrivendo nelle loro risposte sono ragioni perché il codice diventa "legacy". Ma la domanda essenziale in sé è questa:

But it's still used in the production systems - so is it really legacy? And what makes it legacy?

Il fatto che sia ancora utilizzato nella produzione è precisamente ciò che lo rende legacy . Se il codice non funziona correttamente o non è più utilizzato in produzione, allora quel codice è "rotto" o "ritirato", rispettivamente. Legacy significa che è ancora in uso e funziona bene, ma incorpora disegni o tecniche che non sono più di uso comune.

Qualsiasi codice o sistema che (a) vorresti aggiornare / aggiornare, ma non può, o (b) sono ancora nel mezzo dell'aggiornamento, è un sistema legacy. Questo non significa refactoring o pulizia generale del codice, significa significative modifiche al design, possibilmente utilizzando un nuovo framework o anche una nuova piattaforma.

Ci sono diversi motivi per cui i sistemi o il codice potrebbero diventare legacy:

• Mancanza di manutenzione regolare o decomposizione del software . Chiaramente se l'applicazione non viene mantenuta regolarmente, non manterrà il passo con i principali cambiamenti nel mondo del software. Ciò potrebbe essere dovuto alla semplice negligenza o potrebbe essere una scelta deliberata basata su priorità di business o vincoli di budget.

• Mancanza di test. Un'altra risposta fa riferimento alla rivendicazione iperbolica di un autore popolare di qualsiasi codice non coperto da prova essere un codice legacy. Questa non è una definizione precisa ma è una possibile causa principale; senza buoni test (automatici o manuali), gli sviluppatori diventano timidi e hanno paura di apportare modifiche importanti perché si preoccupano di rompere qualcosa, portando così il "software putrefazione" sopra.

• Rev-locking, un fattore spesso trascurato che è particolarmente insidioso nei progetti che utilizzano librerie o framework open-source di grandi dimensioni (anche se l'ho visto accadere anche con strumenti commerciali). Spesso ci sarà una grande personalizzazione fatta al framework / libreria, rendendo un aggiornamento proibitivamente difficile o costoso. Quindi il sistema diventa legacy perché gira su una piattaforma più vecchia (e probabilmente non più supportata).

• Il codice sorgente non è più disponibile, il che significa che il sistema può essere sempre aggiunto e mai modificato. Dal momento che questi sistemi devono essere riscritti per l'aggiornamento - al contrario di rivedere in modo incrementale / iterativo - molte aziende non si preoccuperanno.

Qualsiasi cosa che rallenta o interrompe gli aggiornamenti di un codice base può portare a quella base di codice diventare legacy.

Ora la domanda separata, non dichiarata ma implicita è, cosa c'è di sbagliato nel codice legacy? Viene spesso usata come termine peggiorativo, da qui la domanda:

Should we shy away from this unwarranted labelling of perfectly functioning code?

E la risposta è no, non dovremmo; l'etichettatura è giustificata e il termine stesso implica chiaramente il codice di funzionamento. Il punto non è che è la sua funzione, ma come sta funzionando.

In alcuni casi non c'è niente di sbagliato nel codice legacy. Non è una parolaccia. Codice / sistemi legacy non sono malvagi. Hanno appena raccolto un po 'di polvere - a volte un po', a volte molto.

Legacy diventa obsoleto quando il sistema non può più servire (tutte) le esigenze del cliente. Quella etichetta è quella di cui dobbiamo fare attenzione. Altrimenti, è semplicemente un'equazione costi / benefici; se il costo dell'aggiornamento sarebbe inferiore al costo dei suoi benefici (compresi i costi di manutenzione futuri inferiori), aggiornare, altrimenti, lasciarlo da solo. Non c'è bisogno di sputare la parola "legacy" nello stesso tono che normalmente si riserva per "audit fiscale". È una situazione perfettamente OK.

Di solito significa che è scritto in una lingua, o basato su un sistema in cui normalmente non si fanno nuovi sviluppi.

Ad esempio, la maggior parte dei posti non scrive nuovi programmi in Cobol. Tuttavia, gran parte della loro attività può essere eseguita su app scritte in Cobol. Quindi, quelle app, sono etichettate come "Legacy".

Legacy significa qualsiasi codice che sostituiresti piuttosto che lavorare con. Dato l'atteggiamento della maggior parte dei programmatori verso la maggior parte del codice esistente, di solito include quasi tutto tranne quello che stai scrivendo attivamente al momento (e su un grande progetto in cui devi codificare un disegno congelato, anche quello che stai scrivendo al anche il momento può essere incluso)

1. L'enfasi "piuttosto" è intesa a trasmettere quel codice legacy significa anche che sei bloccato a lavorare con esso anche se preferiresti non farlo. Non sono sicuro che l'enfasi fosse sufficiente. Le ragioni di ciò possono variare. Alcuni sono davvero troppo grandi e complessi da sostituire. Altri sono interfacce con altri sistemi. Altri ancora sono guidati da politici e personalità (ad esempio, il codice è orribile, ma lo stand è stato fantastico).
2. Un altro punto che forse non ho enfatizzato abbastanza è che mentre la qualità del codice può essere un fattore, raramente (se non mai) è l'unico fattore - e spesso nemmeno particolarmente importante.
3. Penso che le persone che spingono test unitari come fattori determinanti sole siano come il ragazzo guardando sotto il lampione per l'orecchino sua moglie si staccò un isolato di distanza. La luce potrebbe essere migliore, ma stai ancora cercando nel posto sbagliato. Pensa prima di bevi il Kool-Aid .
4. (Un corollario a 3.) Mi sembra che alcune persone parlino più di come desiderano che le cose siano rispetto a come sono realmente. Se John Conways ' Game of Life per un Apple IIc Plus non è legacy, è perché è sufficientemente piccolo e semplice che è facile reimplementare da zero. Il test dell'unità più perfetto mai scritto non cambierà un singolo iota .

L'ultimo punto porta ad altri due punti che penso siano spesso veri.

In primo luogo, il codice viene spesso mantenuto come legacy, anche quando in realtà non dovrebbe essere. I manager di livello superiore generalmente ritengono che la re-implementazione di un sistema costerà molto o più di quanto non abbia fatto l'implementazione iniziale, il che è raramente vero.

In secondo luogo, i test unitari sono un'arma a doppio taglio. Rendono troppo facile pensare che i cambiamenti localizzati nell'implementazione siano ciò che conta davvero. Per apportare miglioramenti significativi in un sistema più ampio, spesso (di solito?) È necessario modificare abbastanza del progetto generale che molti (se non la maggior parte) dei test unitari diventano irrilevanti. Sfortunatamente, la presenza di test unitari e l'atteggiamento che generano possono rendere fin troppo facile ignorare le modifiche realmente necessarie.

Forse un esempio potrebbe aiutare: supponiamo che un programma abbia una UI libreria con ottimi test di unità, e diversi programmi che usano quella libreria. Qualcuno del top management si convince che "web enabled" è importante (e, solo per il gusto di argomentare, assumiamo che in questo caso abbia ragione su questo). Dopo un'attenta revisione, i middle manager scoprono che il loro attuale test unitario è sufficiente per poter passare da un'interfaccia utente visualizzata tramite la funzionalità di windowing del sistema operativo locale per essere visualizzata in remoto tramite HTML / CSS / AJAX, pur mantenendo tutta la convalida dell'input originale.

È fantastico, vero? Mostra quanto può essere utile un test unitario. Abbiamo sostituito l'intera implementazione dell'intera interfaccia utente, ma ci siamo assicurati che l'aspetto, la funzionalità e le funzionalità rimangano praticamente coerenti e che tutti gli input dell'utente siano convalidati per garantire l'integrità dei dati. Il test delle unità ha salvato il giorno!

O no! Quella libreria UI grande, altamente flessibile e attentamente testata unitamente ha contribuito a rendere ciechi tutti coinvolti nel fatto che per questo programma nel suo mercato con i suoi utenti, un'interfaccia utente basata sul web è completamente la cosa sbagliata su cui lavorare. Ciò che è veramente necessario è un servizio web con un'interfaccia RESTful e un'interfaccia utente no assoluta di proprio a tutti.

Ora, è certamente vero che i test unitari non eliminano di per sé la capacità delle persone di comprendere il loro mercato o di rendersi conto di ciò che è veramente necessario. Allo stesso tempo, la vecchia linea di martelli e chiodi mi viene in mente. Può essere anche peggio quando non solo hai un martello, ma hai un lotto di esperienza con questo martello, e sai che è un martello di alta qualità che funziona incredibilmente bene in molte situazioni diverse. Il fatto stesso che sia così bravo in così tante cose in così tante situazioni rende ancora più difficile riconoscere quando è completamente lo strumento sbagliato per il lavoro a portata di mano.

Il codice legacy di solito è in qualche modo orfano. Lo sviluppatore principale, l'unico che l'ha capito, è stato investito da un autobus, e le sue note sono state scritte nel suo dialetto ucraino nativo, che ora è una lingua morta. Oppure, in alternativa, qualsiasi cosa scritta in Visual Basic 6.0 .

Lavoro sempre su codice legacy. Direi che le caratteristiche sono:

• Non può essere esteso senza grandi sforzi
• Non può essere facilmente migrato al nuovo hardware
• È troppo business critical per essere facilmente sostituito

Se non ha queste caratteristiche, probabilmente non è legacy. Se non ti piacciono gli script Perl dei tuoi predecessori, sono solidale, ma non credo che sia legacy. Recentemente ho modernizzato alcuni script Perl di 15 anni che sono stati incorporati in un database obsoleto Sybase . È stata una torta rispetto a fare anche il più piccolo cambiamento al nostro sistema di contabilità pessima COBOL .

Nel suo libro Lavorare efficacemente con il codice legacy , Michael Feathers definisce il codice legacy come codice che non è coperto dai test unitari. Questa è una definizione, che condivido. Vedo anche il codice precedente come vecchio, ma ancora utilizzabile.

Tecnicamente, legacy è qualsiasi codice che sia pronto scritto. Quindi, non appena è in produzione, è un lascito. Perché c'è già un valore lì, non puoi semplicemente buttarlo fuori ... Devi affrontarlo.

È "prima del tuo tempo" ma "ancora il tuo mal di testa" .

Il codice legacy è il codice che rimane solo nella base di codice perché molte cose smetterebbero di funzionare diversamente. In altre parole: è la sola ragione per cui esiste la compatibilità con le versioni precedenti.

Preferiresti cambiarlo o addirittura buttarlo via, ma non puoi perché infrangeresti tutto il codice basandosi su di esso (che potrebbe essere un codice che non puoi adattare di conseguenza). Quindi devi mantenerlo (e talvolta mantenerlo anche), ma desideri che tutto il nuovo codice non venga scritto contro di esso.

Un esempio sono metodi deprecati dell'API di una libreria. Sono ancora lì, quindi se chiunque aggiorna la libreria può ancora costruire il suo progetto, ma sono contrassegnati come deprecati e il compilatore dovrebbe darti un avvertimento.

Un altro esempio sono tutti quei bizzarri trucchi che Microsoft fa per far girare programmi scritti per versioni del proprio sistema operativo che hanno completamente deprecato. L'apice di questo essere:

I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
-- Joel on Software

La legacy comporta l'ereditarietà. Il codice legacy è semplicemente un codice ereditato dal passato. È un codice legacy anche se lo hai scritto tu stesso prima!

Tutte le altre considerazioni discendono fondamentalmente dal fatto che non l'hai scritto specificamente per il tuo progetto attuale. Non è necessariamente una cosa negativa di per sé.

La mia opinione è che ciò che viene considerato un codice legacy dipende da più cose e il tag "legacy" è probabilmente specifico per l'organizzazione.

Se l'hardware / sistema operativo su cui gira sono obsoleti e sono stati interrotti dal venditore - fai clic su 1.

Se è più lavoro cercare di risolverlo, piuttosto che riscriverlo, per qualsiasi motivo perché

• lo / gli / i sviluppatore / i originali / i sono andati
• il programma è scritto male
• può essere fatto meglio su una piattaforma più recente, e ne vale comunque la pena per l'azienda

per farlo

• la fonte originale non è più disponibile e / o manca pezzi

Strike 2.

Una fusione di più organizzazioni in una - Strike 3 - un lato probabilmente verrà etichettato come legacy.

Esiste un'alternativa migliore e più economica venduta come applicazione e / o servizio di terze parti: strike 4.

L'organizzazione è qualcosa come un ospedale o un distretto scolastico in cui la coerenza è valutata rispetto alla nuova tecnologia quando si tratta di operazioni quotidiane? Ci vorrà più tempo per un'applicazione considerata legacy rispetto alla stessa applicazione in un'organizzazione commerciale / competitiva.

Se l'azienda è una piccola società di sviluppo che continua a migliorare / supportare l'applicazione per fare ciò di cui i clienti hanno bisogno, è considerata un codice legacy o semplicemente un codice "vecchio". Conosco una società di nome Mc2Ok - hanno sviluppato il software su quello che sembra essere stato Windows 3.1 e hanno continuato a portarlo avanti. Ha ancora molto l'aspetto di Windows 3.1, ma ha aggiunto anche un'interfaccia web. Si tratta di una società di sviluppo composta da due uomini (suppongo), e direi che quando smetteranno di lavorarci su, sarà considerata legacy e il tempo di migrare di un anno o due dopo l'uso. Ma potrebbero essere altri 10 o più anni.

A volte quando la gestione cambia, può cambiare in onde che hanno molti effetti di gocciolamento ... A seconda del peso della nuova gestione, può rendere molte applicazioni legacy che potrebbero altrimenti andar bene.

Ogni organizzazione, credo, deve definire cosa significhi per loro "codice legacy". Ho guardato attraverso The Sunday Times annunci ogni settimana per vedere quali organizzazioni stessero cercando. Quello era il mio barometro per ciò che non era più rilevante (cioè, eredità). Bene, The Sunday Times non è più pertinente :-) E possiamo generalizzare che COBOL è legacy, ASP Classic è legacy, ecc ... Ma credo che ogni organizzazione debba decidere quando un'applicazione è considerata legacy per questo.

Il codice è ereditario quando si ha paura di cambiarlo, perché potrebbe romperlo. È ancora più doloroso quando l'intero sistema può essere bloccato da modifiche a quel codice.

Questo è il motivo per cui sono d'accordo anche con la definizione di Michael Feathers. Il codice che ha buoni test unitari può essere cambiato senza paura.

Penso anche che il codice legacy non abbia nulla a che fare con quanti anni ha. Si può scrivere codice legacy dall'inizio.