Passaggio 0: backup su SCM

Perché, come suggerito da JBRWilkinson nei commenti, controllo della versione è il tuo primo linea di difesa contro il disastro (irreversibile).

Esegui anche il backup dei dettagli di configurazione del software, le procedure per creare risultati, ecc ...

Passaggio 1: prova prima

Quindi inizia con Scrittura test :

• per ciò che funziona,
• e per ciò che fallisce.

Non importa cosa tu decida di fare, sei coperto. Ora puoi:

• inizia da zero e riscrivi ,
• o risolvi it.

Il mio consiglio è di avviare l'architettura generale da zero , ma estrai dal disordine le parti che convalidano i checkpoint e di rifattorizzarli come meglio credi.

Passaggio 2: verifica e monitoraggio

Configura un sistema Integrazione continua (per completare passaggio 0 e passaggio 1 ) AND a Ispezione continua sistema (per preparare passaggio 4 ).

Passaggio 3: Stand sulle spalle dei giganti

(come dovrebbe sempre ...)

• Refactoring to Patterns
• Refactoring: migliorare la progettazione del codice esistente .
• Funzionante in modo efficace con il codice legacy (come raccomandato da Jason Baker )
• Refactoring

Passaggio 4: Pulisci

Questo è ovvio, ma anziché scremare il codice da soli, potresti semplicemente eseguire linters / analizzatori statici e altri strumenti sulla base di codice danneggiata per trovare errori nella progettazione e nell'implementazione.

Quindi potresti anche voler eseguire un formattatore di codice, che aiuterà già un po 'le pulizie.

Passaggio 5: verifica

È facile introdurre minuscoli bug refactoring o pulire le cose. Ci vuole solo una selezione sbagliata e un rapido colpo su un tasto, e potresti cancellare qualcosa di abbastanza importante senza rendersene conto all'inizio. E a volte l'effetto apparirà solo alcuni mesi più tardi. Ovviamente, i passaggi sopra riportati ti aiutano ad evitarlo (specialmente implementando una robusta test harness), ma non sai mai cosa può e ti farà scivolare. Assicurati quindi di rivedere i tuoi refactoring con almeno un altro paio di oculari dedicati (e preferibilmente più di quello).

Passaggio 6: prova del futuro del processo di sviluppo

Prendi tutto quanto sopra e rendilo parte integrante del tuo solito processo di sviluppo, se già non lo è. Non permettere che ciò accada di nuovo sul tuo orologio e collabora con il tuo team per implementare le misure di sicurezza nel tuo processo e applicarlo (se possibile) nelle tue policy. Rendi produttiva Pulisci codice una priorità.

Ma davvero, test . Molto .

Personalmente, non inizierei questo progetto finché non avrò una copia di Lavorare efficacemente con il codice legacy a portata di mano . Seriamente, è stato scritto esattamente per questo tipo di cose. È pieno di strategie per gestire il codice complicato e fornisce molti più dettagli di quelli che posso darti qui.

Ci sono stato diverse volte. La mia regola è: se il software non è banale (più di 1 settimana lavora per la risorsa che hai) e funziona, quindi mantienilo e procedi con il refactoring incrementale.

Se il software non funziona veramente (numero elevato di bug, requisiti poco chiari, ecc.) allora è meglio riscriverlo da zero. Lo stesso se è abbastanza piccolo.

Il punto del refactoring (come nel libro di Fowler e quello di Kerievsky link ) è che mantiene il sistema funzionante , forse il refactoring impiegherà il doppio tempo ma i rischi sono zero.

Riscrivere da zero potrebbe introdurre molti rischi, dai requisiti di incomprensione all'implementazione sbagliata (dopotutto la maggior parte della squadra sarà la stessa).

In realtà ho visto una procedura complessa riscritta da zero due volte e ancora non funziona come previsto.

Vorrei riscriverlo completamente. A volte è impossibile riparare un tale codice. Un'altra opzione è di farlo funzionare, senza aggiungere nuove funzionalità. Per insegnare al team a scrivere un buon codice (ben progettato, documentato, con test) lascia che siano loro a correggere il codice che hai ora. Permetti a tutti di correggere bug / rivedere il codice di altri sviluppatori, non di lei / sua parte. Dopo alcuni tentativi capiranno che è quasi impossibile rivedere / correggere tali codici.

L'aggiunta di persone ai progetti in ritardo aiuta molto raramente. Di solito si rompe le scadenze. Dovresti fare tutto il possibile per completare il progetto con successo, e poi pensare di andartene.

Il mio consiglio è di non scartare completamente l'intero codice. Questo è il problema della vita quotidiana, ogni faccia del team di sviluppo. Attacca una parte del codice alla volta. Risolvilo, puliscilo, documentalo. E poi passare all'altra parte. La cosa principale è sempre tenere a portata di mano qualche codice spedibile. Riscrivere l'intero codice da zero richiederà l'ammontare del tempo che è stato speso fino ad ora e non ci sarà alcuna garanzia che sarà più bello di quello attuale.
Ma poi anche le persone dovrebbero evitare di scrivere il codice in questo modo. Dedica ancora più tempo alle revisioni del codice. Adatta a uno stile di codifica uniforme. Discutere prima il progetto e poi scrivere il codice. Cose così semplici faranno grandi cambiamenti.

Bel blog che spiega perché Netscape si è sciolto

Se funziona, refactoring. Ci sono strumenti per aiutarti a farlo. Se non funziona, usa il comando di miglioramento magico codice, cioè deltree su Windows risp. rm -rf su Linux.

Should we repair the code, and change it to a OOP? We are now debugging it. [... contains errors, no documention ...]

Sono stato lì, hai le mie simpatie. Ho persino scritto un articolo su questo che potrebbe aiutarti a ottenere una certa prospettiva. Ma in breve:

Se il codice contiene lotti di duplicazione, dovresti riscriverlo. Se non c'è una struttura visibile (nessuna interfaccia chiara, spaghetti), il refactoring fallirà e probabilmente dovresti riscriverlo.

How can I teach them to follow all the rules?

Inizia spiegando perché potrebbero voler farlo dimostrando loro cosa possono ottenere da esso personalmente. Quando sono d'accordo con questo e sono disposti a imparare, inizia ad insegnarli usando shuhari .

Il mio suggerimento è una combinazione di @ duros & @Manoj R's risposte.

Inizia da zero, tenendo presente di creare codice buono / OOP / commentato / ecc. questa volta, fai riferimento / copia e incolla dal vecchio codice. Quando incontri le parti cattive del tuo vecchio codice, riscrivi / rifatti.

Se i tuoi sviluppatori non sono ben addestrati, ritengo sia opportuno inviarli per i corsi. È importante per la riqualificazione periodica nel settore IT in rapida evoluzione