Come gestire il codice non proprio legacy? [duplicare]

2

Questo è un argomento frequente ... E ho letto molti post, articoli e sto per leggere il libro Working Effectively with Legacy Code , ma prima e soprattutto perché ci vorranno più di un paio di giorni prima che arrivi il libro e vorrei tenere sotto controllo la sanità mentale, ecco la domanda:

Sto guardando codice non vecchio (1-2 anni) di una società che ho recentemente aderito e ho riscontrato così tante cattive pratiche che è quasi un rompersi ...

Duplicazione di codice massive, variabili globali (che sono usate in modo incoerente) e cose come l'uso di una classe factory per istanziare vari oggetti che estendono un oggetto padre ... e quindi chiamare metodi che non esistono nel genitore, ma sono definito in tutte le sottoclassi ...

Il codice funziona ... È rigorosamente QAed e i bug sono al minimo, il che va bene ... ma mi vergogno tantissimo guardando il codice ...

Recentemente ho chiesto al mio capo se potevo refactoring dell'intero codebase, mi ha chiesto come sarei stato in grado di garantire che le modifiche non si rompessero nulla, ho chiesto che potremmo investire del tempo per creare un'unità reale test, in quanto i loro cosiddetti unit test sono in realtà test end-to-end, quindi dobbiamo tracciare il log di debug molto tempo prima che qualcosa si rompa. Ha detto che non abbiamo abbastanza tempo per creare i test unitari (in realtà il codice non è molto testabile, dal momento che c'è un codice così stretto ... e avrei dovuto riscrivere la maggior parte di le classi), quindi in effetti non potrei nemmeno fare piccole modifiche al codice se non è elencato come bug nel tracker dei problemi ...

Quello che sto facendo in questo momento è un sacco di copia e incolla ... quindi messa a punto fine, dal momento che la logica non è esattamente la stessa ...

Che cosa posso fare? : /

Scusa, penso che mi stia sfogando qui e non c'è nulla che io possa fare a breve / medio termine ... sospiro

    
posta Populus 26.02.2014 - 23:16
fonte

2 risposte

6

Fai NON , in qualsiasi circostanza, modifica il codice fragile che non è necessario. Anche se va bene aggiungere proattivamente i test in modo da poter rifattorizzare le cattive pratiche, farlo nel migliore dei casi è un'attività che consente di fare del tempo, il che non dovrebbe sminuire da ciò che è stato assunto da loro.

Se il codice è un gigantesco mostro di GOTO e un incapsulamento rotto e una follia copiata, e funziona , dovresti lasciarlo il più possibile il più a lungo possibile. Il tuo tempo è meglio speso per impalcature di un framework basato su test per un'eventuale sostituzione, in cui è possibile quindi migrare e refactoring il componente utile di detto brutto behemoth.

(Non che anche farlo sia un dispendio di tempo che vale la pena, a meno che non ci sia una scadenza imminente simile a Y2K che possa distruggere il behemoth.) O i tuoi collaboratori stanno continuando lo sviluppo su detta mostruosità.)

    
risposta data 27.02.2014 - 00:07
fonte
3

Non c'è nulla che ti impedisca di creare test di unità "reali" ogni volta che correggi un bug esistente o aggiungi un nuovo miglioramento, e ci sono alcune buone tecniche in Lavorare efficacemente con il codice legacy su come fare quello.

Se il codice è fragile come sembra, probabilmente avrai molte opportunità per correggere i bug; assicurati che tu porti buoni test per supportare i tuoi bugfix e miglioramenti man mano che si presentano. Nel corso del tempo, o alla fine si svilupperà una sostanziale suite di test o l'applicazione andrà via (a quel punto la mancanza di copertura del test non è più un problema: -)

    
risposta data 27.02.2014 - 01:13
fonte

Leggi altre domande sui tag