Questo codice dovrebbe essere riscritto o refactored?

È facile.

Riscrivialo.

Dì solo che stai refactoring. Tutti sono felici.

Dal momento che nessuna delle due parole ha una definizione formale, legale e verificabile, esse possono argomentare la semantica sottile di ogni parola mentre si riscrive / rifatta finché non funziona.

Non sembra che il modulo fosse cattivo con, ma che l'aggiunta di "nuove funzionalità" lo ha rotto. A questo punto potrebbe essere difficile capire se la qualità del codice fosse inizialmente bassa o quella fornita con le funzionalità.

O il modulo non è mantenibile (una possibilità distinta) o le persone incaricate di aggiornarlo non hanno le competenze giuste (sembra questo) o entrambi.

In base all'abuso del termine "errore di pagina" (gli errori di pagina sono in realtà normali, sembra più una violazione di accesso), l'idea che un buffer overflow sia una proprietà di un grande modulo di codice piuttosto che un bug in una specifica riga di codice (e potrebbero esserci molti bug di overflow del buffer in un modulo), e il fatto che tu sembri usare la parola "virus" per riferirsi a quel buffer overflow, temo che tu sia tanto il problema come il codice è.

Per lo meno, penso che dovresti stare fuori dal dibattito su "come sistemarlo al meglio" e lasciare che i codificatori più esperti elaborino l'approccio giusto, quindi aiutarli a realizzarlo.

Quindi dedica un po 'di tempo a leggere (i blog sarebbero utili) sulla scrittura di codice robusto, su come evitare buffer overflow, interi wraparound, ecc. in modo che tu possa affrontare meglio tali problemi in futuro.

Non riscrivere finché non sei sicuro di aver capito il codice. Quando non lo sei - ed è l'impressione che offri - è una cattiva idea. Ho iniziato a spiegare perché, ma ricordavo che Joel l'ha fatto meglio .

The project manager wishes to refactor the module on account of the limited time available required to complete the detailed design, coding, code review, unit tests and integration testing which is three months. He thinks the time scales are too tight to do a full rewrite.

Penso che il tuo project manager abbia una cattiva comprensione di cosa significhi refactoring . Quello di cui sta parlando è il miglior patching del codice. Refactoring non implica in alcun modo saltare i passaggi che hai elencato (codifica, revisione, testing) e quindi non vi è alcuna garanzia che sia più veloce di una riscrittura completa, specialmente se il punto di partenza è un codice scritto male.

Sono d'accordo con alcuni degli altri partecipanti sul fatto che refactoring contro riscrittura sta discutendo su sottili differenze semantiche. Il problema è che il tuo project manager sta probabilmente pensando a nessuno dei due.

Refactoring di un modulo è riscrivendolo, senza modificare la sua interfaccia. Quindi se chiedi cosa sarebbe meglio per te, presumo che chiedi se ha senso cambiare l'interfaccia o no.

Cambiare l'interfaccia potrebbe essere un problema, per l'integrazione. Ad ogni modo, se il tuo modulo è usato solo in pochissimi posti, potrebbe essere fattibile una riscrittura, perché sai ora molto meglio di prima cosa dovrebbe fare il modulo e come viene realmente utilizzato. Questa conoscenza dovrebbe aiutarti a progettare un'API e un'architettura dei moduli ottimali, eliminando possibilmente grandi quantità di intricatezze.

In caso contrario, un refactoring è la scelta migliore. Nel tuo caso il modulo dovrebbe già mostrare alcune API, in modo che tu possa iniziare a riscrivere i corpi di quelle funzioni, pur rispettando ciò che attualmente prendono e restituiscono, e come falliscono. In questo refactoring dovresti fare affidamento sulle funzioni ancora da scrivere , in modo top-down, per qualsiasi risultato necessario.

IMHO: riscrivi come ultima risorsa.

Ho sostenuto e approvato un progetto per riscrivere il nostro prodotto di punta. Enorme impresa. L'ho fatto solo dopo che tutti i miei tentativi di refactoring sono falliti. Il prodotto aveva un codice al di là di un cattivo odore, era pieno di costrutti che creavano un comportamento indefinito. Non può essere lavorato in modo efficace.

Se hai qualche speranza nel refactoring, refactoring. Se non ce n'è ... no. A meno che il progetto non sia banale, non dovrebbe essere possibile riscriverlo in meno tempo di quello necessario al refactoring.

Other problems hidden deeper were difficult to find, as well as a virus in the body.

Come è successo QUI ?! Stai usando il controllo della versione?

Generalmente non sono un sostenitore della riscrittura del codice da zero poiché il codice di produzione di solito è stato modificato nel tempo per gestire molte sfumature. Detto questo, l'intera faccenda del "virus" mi renderebbe più incline a ricominciare da zero poiché vorrei comunque rivederlo in un dettaglio microscopico.

Questo mi ha fatto riflettere molto: "Quando vengono aggiunte nuove funzionalità a questo modulo, alcune funzionalità originali non funzionano." Ho visto questo accadere abbastanza spesso e, IMHO, la ragione è principalmente legata al fatto che il principio "apri / chiudi" non è seguito.

Fondamentalmente, non devi aggiungere nuove funzionalità modificando il codice esistente, funzionante e ben testato. Piuttosto, dovresti aggiungere nuove funzionalità scrivendo un nuovo codice su cui il vecchio codice non dipende.

Quindi, se l'estensione del codice interrompe le vecchie funzionalità, può essere che il codice non venga esteso correttamente?