Vorrei farti alcune domande sul codice sporco. Ci sono alcuni principianti che hanno programmato un progetto medio. Il codice è un'enorme palla di fango. Non sono programmatori avanzati. Sanno solo come usare un po 'la tastiera di Java. Hanno appena scritto codice con 12.000 righe nella loro classe principale, tuttavia, 6.000 righe appartengono allo stesso NetBeans.

Il mio compito è analizzare il codice e suggerire un buon modo per mantenerlo. La mia idea è quella di eliminare il progetto e avviarne uno nuovo con la metodologia OOP. Recentemente ho raccolto alcune note e idee sul problema, da questo sito e da alcuni altri.

Ora ho le seguenti domande:

1. Dovremmo riparare il codice e cambiarlo in OOP? Lo stiamo ora eseguendo il debug.
2. Il codice non ha commenti, documentazione, stile di programmazione particolare e così via. Cambiarlo è davvero costoso e richiede tempo. Cosa possiamo fare al riguardo?
3. Come posso insegnare loro a seguire tutte le regole (commenti, OOP, buona qualità del codice, ecc.)?
4. Il codice è errato e soggetto a errori. Cosa possiamo fare? Prove? Scriviamo quasi due o tre documenti A4 per la correzione, ma sembra infinito.

Dovrei dire che sono nuovo con loro. Penso di aver infranto le regole sull'aggiunta di persone troppo tardi al progetto. Pensi che devo lasciarli?

Passaggio 0: backup su SCM

Perché, come suggerito da JBR Wilkinson nei commenti, il controllo della versione è la tua prima linea di difesa contro il disastro (irreversibile).

Effettua anche il backup dei dettagli di configurazione del software, delle procedure per creare risultati finali, ecc ...

Passaggio 1: prima prova

Quindi iniziare scrivendo test :

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

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

• ricominciare da capo e riscrivere ,
• o aggiustalo .

Il mio consiglio sarebbe di iniziare da zero l'architettura generale , ma di estrarre dal caos le parti che convalidano i punti di controllo e di riformattare questi come meglio credi.

Passaggio 2: verifica e monitora

Impostare un sistema di integrazione continua (per integrare i passaggi 0 e 1 ) E un sistema di ispezione continua (per preparare il passaggio 4 ).

Step 3: Sali sulle spalle dei giganti

(come dovresti sempre ...)

• Refactoring ai pattern
• Refactoring: migliorare la progettazione del codice esistente .
• Lavorare in modo efficace con il codice legacy (come raccomandato da Jason Baker )
• refactoring

Passaggio 4: pulito

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

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

Passaggio 5: rivedere

E 'facile introdurre minuscoli insetti dal refactoring o pulire le cose. Ci vuole solo una selezione sbagliata e una rapida pressione di un tasto, e potresti cancellare qualcosa di abbastanza importante senza accorgertene all'inizio. E a volte l'effetto apparirà solo mesi dopo. Ovviamente, i passaggi precedenti ti aiutano ad evitare questo (specialmente implementando un forte cablaggio di prova), ma non sai mai cosa può e scivolerà attraverso. Quindi assicurati di far rivedere i tuoi refactoring da almeno un'altra coppia di bulbi oculari dedicati (e preferibilmente più di questo).

Passaggio 6: a prova di futuro il processo di sviluppo

Prendi tutto quanto sopra e rendilo parte integrante del tuo normale processo di sviluppo, se non lo è già. Non lasciare che ciò accada di nuovo sul tuo orologio e collabora con il tuo team per implementare le protezioni nel tuo processo e applicarlo (se possibile) nelle tue politiche. Rendi la produzione di codice pulito una priorità.

Ma davvero, prova . Un sacco .

Personalmente, non inizierei questo progetto fino a quando non avrò una copia di Working Effectively with Legacy Code a portata di mano. Scherzi a parte, è stato scritto esattamente per questo tipo di cose. È pieno di strategie per gestire il codice ingannevole 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 di lavoro per la risorsa che hai) e funziona, quindi mantienilo e procedi con il refactoring incrementale.

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

Il punto nel refactoring (come nel libro di Fowler e in quello di Kerievsky http://www.industriallogic.com/xp/refactoring/ ) è che mantiene il sistema funzionante, forse il refactoring richiederà un doppio tempo ma i rischi sono zero.

La riscrittura da zero potrebbe comportare molti rischi, dai requisiti di incomprensione all'implementazione errata (dopotutto la maggior parte del team sarà la stessa).

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

Lo riscriverei completamente. A volte è impossibile riparare un tale codice. Un'altra opzione è farlo funzionare, senza aggiungere nuove funzionalità. Per insegnare al team a scrivere un buon codice (ben progettato, documentato, con i test), permetti loro di correggere il codice che hai adesso. Consenti a tutti di correggere i bug / rivedere il codice di altri sviluppatori, non la 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 infrange le scadenze. Dovresti fare tutto il possibile per completare con successo il progetto e poi pensare di andartene.

Il mio consiglio sarà di non eliminare completamente l'intero codice. Questo è il problema quotidiano della vita, che ogni team di sviluppo deve affrontare. Attacca una parte del codice alla volta. Riparalo, puliscilo, documentalo. E poi passa all'altra parte. La cosa principale è tenere sempre a portata di mano un codice spedibile. La riscrittura dell'intero codice da zero richiederà la quantità di tempo che è stata impiegata fino ad ora e non ci sarà alcuna garanzia che sarà più bello dell'attuale.
Ma poi anche le persone dovrebbero evitare di scrivere il codice in questo modo. Dedica un po 'più di tempo alle recensioni del codice. Adattarsi a uno stile di codifica uniforme. Discutere prima il disegno e poi scrivere il codice. Cose così semplici apporteranno grandi cambiamenti.

Bel blog che spiega perché Netscape è libero

Se funziona, riformattalo. Ci sono strumenti per aiutarti a farlo. Se non funziona, utilizzare il comando di miglioramento del codice magico, ad es. deltreeSu Windows risp. rm -rfsu Linux.

Dovremmo riparare il codice e cambiarlo in OOP? Lo stiamo ora eseguendo il debug. [... contiene errori, nessuna documentazione ...]

Ci sono stato, hai le mie simpatie. Ho anche scritto un articolo su questo che potrebbe aiutarti a ottenere qualche prospettiva. Ma in breve:

Se il codice contiene molte duplicazioni, è necessario riscrivere. Se non esiste una struttura riconoscibile (nessuna interfaccia chiara, spaghetti), il refactoring fallirà e probabilmente dovresti riscriverlo.

Come posso insegnare loro a seguire tutte le regole?

Inizia spiegando perché potrebbero voler farlo mostrando loro ciò che possono ottenere da esso personalmente. Quando sono d'accordo con questo e sono disposti a imparare, inizia a insegnare loro usando lo shuhari .

Il mio suggerimento è una combinazione delle risposte di @ duros e di @Manoj R.

Inizia da zero, tenendo presente di creare questa volta un buon codice / OOP / commentato / ecc., Fai riferimento / copia e incolla dal tuo vecchio codice. Quando incontri le parti danneggiate del tuo vecchio codice, riscrivile / riformattale.

Se i tuoi sviluppatori non sono ben addestrati, penso che sia buono inviarli per i corsi. È importante per una riqualificazione regolare nel settore IT in rapida evoluzione