Come manterresti le applicazioni legacy [chiuso]

Question

Come manterresti le applicazioni legacy che:

1. Nessun test unitario ha metodi grandi

2. con molte logiche duplicate ha

3. non ha separazione delle preoccupazioni
4. ha molti hack rapidi e hard coded stringhe
5. hanno obsoleto e sbagliato documentazione
6. I requisiti non sono adeguatamente documentati ! Ciò ha effettivamente comportato controversie tra tester, sviluppatori e clienti in passato. Naturalmente ci sono alcuni requisiti non funzionali come non dovrebbe essere lento, non scontrarsi e altre logiche aziendali che sono note agli utenti dell'applicazione. Ma al di là dello scenario di buon senso e del flusso di lavoro aziendale di buon senso, ci sono poche indicazioni su ciò che dovrebbe (o non) essere fatto.

???

Answer 1

È necessario il libro Lavorare in modo efficace con il codice legacy di Michael C. Feathers .

Answer 2

Scrivi i test appena puoi. Preferibilmente contro i requisiti (se esistono). Inizia con i test funzionali. Rifrattore in piccoli pezzi. Ogni volta che tocchi il codice, lascialo più pulito e migliore di quando hai iniziato.

Answer 3

Due cose.

1. Scrivi test unitari quando ne hai la possibilità.
2. Quando hai abbastanza unit test per essere sicuro, inizia il refactoring.

La velocità con cui lo realizzi potrebbe essere lenta .... In genere, dovresti " semplicemente mantenerlo " non aggiustarlo.

Durante la fase di "quotazione" su come mantenerla fase, tuttavia, puoi scrivere molti test unitari.

Quindi, man mano che vengono rilevati dei bug e sono richiesti miglioramenti, è possibile aggiungere altri test.

È Agile, applicato all'eredità.

Answer 4

Ho visto, lavorato e sto lavorando in una base di codice che soddisfa tutte le condizioni menzionate nella domanda :-)

L'approccio seguito nel mantenimento di questa base di codice è NON Rompere qualsiasi cosa . FWIW, il codice funziona e gli utenti finali sono felici. Nessuno ascolterà lo sviluppatore che piange che esiste una duplicazione di codice, stringhe codificate, ecc. Abbiamo solo rubato un po 'di tempo per sistemare tutto il possibile e prenderci la massima cura per non introdurre nuovi bug ..

Answer 5

Penso che creerei un piccolo insieme di informazioni aggiornate: quale azione chiama quali funzioni ecc.

Da lì, guarderei al refactoring. La logica duplicata sembra essere qualcosa che potrebbe essere refactored, ma ricordalo

• Questo può essere un compito enorme quando ti rendi conto in quanti molti luoghi viene chiamata la logica e
• Due funzioni che sembrano simili possono avere una minuscola differenza, ovvero a - anziché a +

Penso che il più grande bisogno di resistere sia " Basta ricostruire l'intera dannata cosa! " e ottenere prima una panoramica del sistema, per demistificare la bestia.

Answer 6

sudo rm -rf /

Ma più seriamente, penso che debba essere valutato. Se il codice è continuamente una fonte di richieste di modifica e le modifiche sono difficili, in breve tempo devi considerare se vale la pena provare e riformattare / riprogettare il sistema in qualcosa di più moderno. Naturalmente questo non è sempre pratico, quindi spesso finisci con solo poche persone nel team che sono responsabili del mantenimento delle parti legacy. Per quanto possibile, tutti i membri del team dovrebbero essere in grado di mantenere tutte le parti del sistema ......

Un'altra cosa che ritengo importante è tenere traccia della quantità di tempo e sforzo che un team impiega a lavorare su un sistema legacy per eseguire richieste di manutenzione / funzionalità. Queste metriche possono essere convincenti quando si valuta la pianificazione di un nuovo sforzo per sostituire i sistemi / componenti legacy.

Answer 7

Sono sostanzialmente d'accordo con tutto ciò che ha detto Paul C. Non sono un prete TDD, ma ogni volta che tocchi una base di codice legacy - in particolare una con cui non sei intimamente familiare - devi avere un modo solido per ripetere il test e assicurarti di aver seguito Ippocrate: Primo , non fare danni. Test, buone unità e test di regressione in particolare, sono l'unico modo per farlo.

Consiglio vivamente di ritirare una copia di Inversione: segreti di ingegneria inversa Software se si tratta di una base di codice con cui non si ha familiarità. Sebbene questo libro vada a grandi profondità che sono al di fuori delle tue attuali esigenze (e delle mie, del resto), mi ha insegnato molto su come lavorare in modo sicuro e sano con il codice di qualcun altro.