Come trattate il codice (e i dati) legacy?

Question

Attualmente sto ristrutturando il mio repository Subversion locale aggiungendo alcuni nuovi progetti e unendo al suo interno codice e dati legacy da un paio di repository più vecchi.

Quando l'ho fatto in passato, di solito mettevo il codice legacy in una cartella "legacy" dedicata, per non "disturbare" il nuovo e "ben strutturato" albero del codice.Tuttavia, nello spirito del refactoring, ritengo che questo sia in qualche modo sbagliato.In teoria, il codice legacy verrà sottoposto a refactoring nel tempo e spostato nella nuova posizione, ma in pratica ciò accade raramente.

Come tratti il ​​tuo codice legacy?Per quanto mi senta tentato di riporre i vecchi peccati nella cartella "eredità", per non guardarla mai più, a un certo livello spero che, costringendolo a vivere tra gli abitanti più "sani" del deposito, forse l'eredità il codice avrà maggiori possibilità di guarire un giorno?

(Sì, lo sappiamo tutti non dovremmo riscrivere le cose, ma questo è il mio repository "divertente", non i miei progetti di business...)

Aggiornamento

Non sono preoccupato per gli aspetti tecnici legati al tenere traccia delle varie versioni.So come usare tag e rami per questo.Questo è più un aspetto psicologico, poiché preferisco avere una struttura "ordinata" nel repository, che ne renda la navigazione molto più semplice, per gli esseri umani.

Answer 1

Tutto il codice un giorno diventerà "legacy", perché separarlo del tutto?Il controllo del codice sorgente avviene per progetto/ramo o progetto/piattaforma/ramo e quel tipo di gerarchia.A chi importa quanto tempo è nel dente?

Answer 2

L'etichettatura è un'operazione molto economica nella sovversione.Tagga il tuo codice quando inizi il refactoring e a fasi regolari mentre procedi.In questo modo è facile accedere ancora al vecchio codice (ma funzionante) come riferimento per il tuo nuovo codice (ma rotto).:-)

Answer 3

Ecco la tua analisi psicologica gratuita:

Quello che hai qui è un desiderio profondamente radicato di correggere il tuo codice legacy in modo che non sia più legacy.Quando lo nascondi, stai semplicemente reprimendo quel desiderio, cercando di evitarlo perché è una sensazione spiacevole.Se lo lasci allo scoperto, accadrà una delle due cose:alla fine ti farà impazzire e dovrai ucciderti, o (più ottimisticamente), ti verrà ricordato ogni pezzo disordinato ancora e ancora finché non crollerai e ripulirai tutto.

Non nascondere il disordine;puliscilo.Altrimenti prima o poi tornerà a morderti.

Answer 4

Dipende da cosa chiami eredità.Se dicendo legacy intendi veramente "codice di qualche applicazione ritirata che è così pessima che non lo useremo mai più", dovrebbe essere separato dal tuo codice attuale.Se si tratta di qualcosa del tuo progetto attuale ma è stato scritto da altre persone o non è all'altezza dei tuoi standard attuali, trattalo normalmente ma contrassegnalo per il refactoring in futuro nel tuo tracker dei problemi.

Answer 5

Utilizzo Definizioni esterne (svn: esterni property) per fare riferimento al codice legacy come faresti con un repository di terze parti.

Quindi puoi separare il tuo lavoro di refactoring dai tuoi progetti dipendenti e (usando riferimenti di revisione fissi, ad es.-r1234) essere molto esplicito su quale revisione del codice legacy da cui dipende il progetto dipendente.