Cosa rende legacy il codice?

Question

Ho sentito molti sviluppatori riferirsi al codice come " legacy " ;. Il più delle volte è il codice che è stato scritto da qualcuno che non lavora più sul progetto. Cosa rende codice, codice legacy?

Aggiornamento in risposta a: " Qualcosa tramandato da un antenato o da un predecessore o dal passato " http://www.thefreedictionary.com/legacy . Chiaramente volevi sapere qualcos'altro. Potresti chiarire o espandere la tua domanda? S. Lott

Sto cercando i sintomi del codice legacy che lo rendono inutilizzabile o un incubo con cui lavorare. Quando è meglio buttarlo via? Ritengo che il codice debba essere gettato via più spesso e che reinventare la ruota sia una parte preziosa dello sviluppo. L'ideale accademico di non reinventare la ruota è bello ma non è molto pratico.

D'altra parte c'è ovviamente un codice legacy che vale la pena conservare.

Answer 1

Usando hardware, software, API, lingue, tecnologie o funzionalità che non sono più supportate o sono state superate, in genere combinate con poca o nessuna possibilità di sostituire mai quel codice, invece di usarlo fino a quando il sistema non si spegne.

Answer 2

  

Cosa rende codice, codice legacy?

Come per la semplice eredità, quando l'autore è morto o scomparso, tu come erede ottieni tutto o parte del suo codice.

Hai versato alcune lacrime e hai cercato di capire cosa fare con tutta questa spazzatura.

Answer 3

Michael Feathers ha una definizione interessante nel suo libro Working Effectively with Legacy Code. Secondo lui il codice legacy è un codice senza test automatici.

Answer 4

È un termine molto generale (e spesso abusato), ma una delle seguenti sarebbe legittime ragioni per chiamare un'eredità dell'app:

1. La base di codice si basa su una lingua / piattaforma completamente non supportata dal produttore del prodotto originale (spesso detto produttore non è più attivo).

2. (in realtà 1a) La base di codice o la piattaforma su cui è costruita è così vecchia che ottenere sviluppatori qualificati o esperti per il sistema è sia difficile che costoso.

3. L'applicazione supporta alcuni aspetti del business che non sono più attivamente sviluppati e per i quali le alterazioni sono estremamente rare, normalmente per risolverlo se qualcosa di completamente inatteso cambia attorno ad esso (l'esempio canonico è il problema Y2K) o se un po 'di regolazione / pressione esterna lo forza. Dal momento che entrambe le ragioni sono pressanti e normalmente inevitabili, ma non si è verificato uno sviluppo significativo nel progetto, è probabile che le persone incaricate di occuparsene non abbiano familiarità con il sistema (e con i suoi comportamenti e complicazioni accumulati). In questi casi questo sarebbe spesso motivo di aumentare il rischio percepito e pianificato per il rischio associato al progetto.

4. Il sistema ha / o viene sostituito con un altro. In quanto tale, il sistema può essere utilizzato per molto meno di quanto originariamente previsto, o forse solo come mezzo per visualizzare i dati storici.

Answer 5

L'eredità generalmente si riferisce al codice che non è più in fase di sviluppo, il che significa che se lo si utilizza, è necessario utilizzarlo ai termini originali, non è possibile modificarlo per supportare l'aspetto del mondo oggi. Ad esempio, il codice legacy deve essere eseguito su hardware che potrebbe non esistere oggi o che non è più supportato.

Answer 6

Secondo Michael Feathers, l'autore dell'eccellente Lavorare in modo efficace con il codice legacy , il codice legacy è un codice che non ha test. Quando non c'è modo di sapere cosa si interrompe quando questo codice cambia.

  

La cosa principale che distingue   codice legacy da codice non legacy è   test, o piuttosto una mancanza di test. Noi   posso avere un'idea di ciò con un po '   esperimento mentale: quanto sarebbe facile   essere per modificare la tua base di codice se lo è   potrebbe mordere, se potesse dirtelo   quando hai fatto un errore? Sarebbe   abbastanza facile, no? La maggior parte della   paura coinvolta nel fare cambiamenti a   basi di codice di grandi dimensioni sono la paura   introdurre bug sottili; paura di   cambiando le cose inavvertitamente. Con   test, puoi migliorare le cose con   impunità. Per me, la differenza è così   critico, travolge qualsiasi altro   distinzione. Con i test, puoi fare   cose migliori. Senza di loro, tu solo   don & # 8217; t so se le cose stanno arrivando   meglio o peggio.

Answer 7

Una volta un collega mi ha detto che il codice legacy era un codice che non avevi scritto tu.

Probabilmente, è solo un termine peggiorativo per codice che non ci piace più per qualsiasi motivo (in genere perché non è bello o alla moda ma funziona).

La brigata TDD potrebbe suggerire che qualsiasi codice senza test sia un codice legacy.

Answer 8

Codice legacy è il codice sorgente che si riferisce a un sistema operativo non più supportato o prodotto o altra tecnologia informatica.

Answer 9

Nessuno leggerà questo, ma sento che le altre risposte non lo capiscono perfettamente:

1. Ha valore, se non fosse utile sarebbe stato gettato via molto tempo fa
2. È difficile da ragionare perché uno dei due
   1. Mancanza di documentazione,
   2. L'autore originale non può essere trovato o dimenticato (sì, 2 mesi dopo anche il tuo codice può essere un codice legacy !!),
   3. Mancanza di test o tipi di sistema
   4. Non segue le pratiche moderne (vale a dire nessun contesto a cui aggrapparsi)
3. È necessario modificarlo o estenderlo. Se non è necessario modificarlo, non è un codice legacy poiché a nessuno importa. Fa le sue cose e non c'è nessuno in giro per chiamarlo codice legacy.

Answer 10

http://en.wikipedia.org/wiki/Legacy_code

" Il codice legacy è il codice sorgente che si riferisce a un " non più supportato o prodotto;

Answer 11

Manca qualsiasi codice con supporto (o documentazione). Sia esso:

• commenti incorporati
• documentazione tecnica
• documentazione parlata (la persona che l'ha scritta)
• unit test che documentano il funzionamento del codice

Answer 12

Per me il codice legacy è un codice che è stato scritto prima di un cambio di paradigma. Potrebbe essere ancora molto in uso ma è in fase di refactoring per renderlo in linea.
per esempio. Vecchio codice procedurale in giro in un sistema altrimenti OO.

Answer 13

Il codice (o qualsiasi altra cosa, in realtà) diventa " legacy " quando è stato sostituito da qualcosa di più nuovo / migliore, eppure nonostante ciò è ancora usato e mantenuto in vita! " allo stato selvatico " ;.

Answer 14

Preservare il codice legacy non è tanto un ideale accademico quanto è mantenere il codice che funziona, non importa quanto male. In molte situazioni aziendali conservative, ciò sarebbe considerato più pratico che buttarlo via e ricominciare da zero. Meglio il diavolo che conosci ...

Answer 15

Il codice legacy è un codice che è doloroso / costoso per essere aggiornato con i requisiti in evoluzione.

Esistono due modi in cui ciò può accadere:

1. Il codice non è adatto per la modifica
2. La semantica del codice è stata scambiata con silicio

1) è il più facile da riconoscere dei due. È un software che ha limiti fondamentali che lo rendono incapace di tenere il passo con l'ecosistema che lo circonda. Ad esempio, un sistema costruito attorno all'algoritmo O (n ^ 2) non si ridimensionerà oltre un certo punto e deve essere riscritto se i requisiti si spostano in quella direzione. Un altro esempio è l'utilizzo di librerie di codice che non sono supportate sulle ultime versioni del sistema operativo.

2) È più difficile da riconoscere, ma tutto il codice di questo tipo condivide la caratteristica che le persone hanno paura di cambiarlo. Ciò potrebbe essere dovuto al fatto che è stato scritto / documentato male all'inizio, perché non è stato testato o perché non è banale e gli autori originali che l'hanno capito hanno lasciato il team.

I caratteri ASCII / Unicode che comprendono il codice vivente hanno un significato semantico, il " perché è " ;, " cos'è " e in qualche misura il " come sta " ;, nelle menti delle persone ad esso associate. Il codice legacy non è di proprietà o i proprietari non hanno significato associato a grandi parti di esso. Una volta che ciò accade (e potrebbe accadere il giorno successivo con un codice scritto in modo molto scadente), per modificare questo codice, qualcuno deve impararlo e capirlo. Questo processo è una frazione significativa del tempo necessario per scriverlo in primo luogo.

Answer 16

Il giorno in cui hai paura di riformattare il tuo codice è il giorno in cui il tuo codice è diventato legacy.

Answer 17

Considero il codice " legacy " se si applicano alcune o tutte le seguenti condizioni:

• È stato scritto usando un linguaggio o una metodologia che è una generazione dietro gli standard attuali
• Il codice è un casino completo senza pianificazione o progettazione dietro
• È scritto in lingue obsolete e in uno stile obsoleto, non orientato agli oggetti
• È difficile trovare sviluppatori che conoscano la lingua perché è così vecchio

A differenza di alcune delle altre opinioni qui, ho visto molte applicazioni moderne che funzionano decentemente senza unit test. I test unitari non hanno ancora attecchito con tutti. Forse tra dieci anni la prossima generazione di programmatori esaminerà le nostre attuali applicazioni e le considererà & Quot; legacy & Quot; per non contenere test unitari, così come considero legacy le applicazioni non orientate agli oggetti.

Se è necessario apportare poche modifiche a una base di codice legacy, è meglio lasciarlo così com'è e seguire il flusso. Se l'applicazione necessita di drastiche modifiche alla funzionalità, una revisione della GUI e / o non riesci a trovare nessuno che conosca il linguaggio di programmazione, è tempo di buttarlo via e ricominciare da capo. Un avvertimento, tuttavia: riscrivere da zero può richiedere molto tempo ed è difficile sapere se hai replicato tutte le funzionalità. Probabilmente vorrai avere casi di test e unit test scritti per l'applicazione legacy e la nuova applicazione.

Answer 18

Il codice legacy è onestamente qualsiasi codice, framework, api, di altri costrutti software che non è " cool " più. Ad esempio, COBOL è considerato all'unanimità come eredità, mentre APL non lo è. Ora si può anche affermare che COBOL è consegnato legacy e APL non perché ha circa 1m volte la base di installazione come APL. Tuttavia, se dici che devi lavorare sul codice APL la risposta non sarebbe & Quot; oh no, quella roba legacy & Quot; ma piuttosto " oh mio dio, immagino che non farai nulla per il prossimo secolo " vedi la differenza?

Answer 19

Questo è un termine generale usato abbastanza spesso (e abbastanza genericamente) nell'ecosistema software.

Beh, mi piace pensare al codice legacy come codice ereditato . Questo è semplicemente un codice che è stato scritto in passato. Nella maggior parte dei casi, il codice legacy non segue le pratiche nuove / attuali ed è spesso considerato arcaico.

Answer 20

Il codice legacy è qualsiasi cosa scritta più di un mese fa :-)

Answer 21

Spesso è un codice che non è scritto nel linguaggio di scripting trendy du jour, e io sto solo scherzando a metà.