Refactoring o... rewrite?

Lunedì ho dato una prima occhiata alle pagine di una parte di applicazione ASP.NET che dovrò espandere nelle prossime settimane.

Sapevo a priori che il tipo di codice che mi sarei trovato davanti era scritto con una metodologia decisamente differente da quella che ormai sono abituato ad utilizzare da un po' di anni ed in effetti ho trovato delle differenze significative: codice nei tag script delle pagine aspx (comunque "spostabile" con pochi click nel code behind), architettura non DD, accesso diretto al db e procedure scritte praticamente in modo quasi sequenziale, oltrettutto in VB.NET, mentre tutto il resto dell'applicativo é in C#.

Sono rimasto parecchio in dubbio sulla scelta fra un profondo refactoring del codice esistente ed una più radicale riscrittura del codice ripartendo dai requisiti.

Inizialmente avevo provato a prendere in considerazione la prima possibilità, ma quando mi sono trovato di fronte ad un metodo di 653 righe ho capito che la mia ormai "impigrita" capoccia (che nel frattempo si è abituata a metodi che non arrivano quasi mai alle 20 righe) avrebbe fatto una bella fatica, ed ancor peggio magari qualche pasticcio, nel cercare di seguire il flusso del codice esistente.

Ho scelto di rinviare la decisione a dopo ferragosto, ma non ho ancora preso una decisione definitiva sulla strada da percorrere: a vantaggio della prima c'è un'ottima intesa con chi ha scritto il codice esistente e la disponibilità ad aiutarmi nel comprenderne il flusso; nel secondo caso, invece, c'è l'ovvio vantaggio che deriva dal ripartire "from scratch" utilizzando le proprie metodologie.

Spero che la notte (o ciò che ne rimane) porti consiglio...

Print | posted @ giovedì 16 agosto 2007 0.44

Comments on this entry:

Gravatar # re: Refactoring o... rewrite?
by Alesssandro Scardova at 16/08/2007 8.11

Codice che gira non si tocca, vecchio mio... Potresti, nella nuova riscrittura inrtodurre dei bug che non sono presenti nel vecchio codice e allora? Diventerebbe meglio il tuo bello e pulito, ma buggato o quello prpre-esistente, 'orendo' ma funzionante?
Gravatar # re: Refactoring o... rewrite?
by Mario Duzioni at 16/08/2007 11.37

Ciao Ale!!

Non concordo molto con quello che dici. Ti assicuro che è molto più facile che permangano eventuali bug sommersi in un codice "monolitico" rispetto ad una analoga versione con componenti e responsabilità separate, anche su più layers. :-)

Non concordo molto neanche sul "codice che gira non si tocca", o meglio: concordo nel senso che poi è davvero difficile rimettere le mani su un codice scritto in quel modo! ;-)

Grazie per gli spunti, mi aiutano comunque!

Ciao!
Gravatar # re: Refactoring o... rewrite?
by Fausto at 16/08/2007 19.33

Io sono di fronte al tuo stesso problema, ti assicuro che è difficile prendere una decisione.
In genere cerco di suddivider il problema ne i seguenti puntoi e ponderarli per ottenere una indicazione:

Percentuale di visualizzazioni modificate

Percentuale di Metodi e/o proprietà modificate

Vengone aggiunte nuove funzionalità, che si possono separare dal codice oppure devo modificare la logica del codice esiste?

L'applicazione dovrà essere mantenuta ed aggiornata?

Generalmente governa il buon senso, ma se si deve moificare la logica di bussines può non essere sufficente un refactoring, irima comunqui importantissimo sapere se la si dovra mantenere nel temopo o se la dovrà mantenere chi ha scritto la versione attuale.
Non ultimo il tempo ed il bugett a disposizione.

Peronlmente penso che sia meglio dire 'Qul che gira è intoccabile ed imutabile', per cui se si deovono apportare modifiche per aggiungere e/o modificare funzionalità sicuramente si possono introdurre errori nelle parti non toccate.

Gravatar # re: Refactoring o... rewrite?
by LudovicoVan at 16/08/2007 20.12

Neanch'io concordo su "quel che gira non si tocca". Questa e' una regola d'oro dei sistemisti da non applicare al software. Ovvero, codice che gira non si tocca magari si', ma solo sino alla prossima richiesta di modifica/estensione, dopodiche' i nodi vengono al pettine, inesorabilmente! Dunque concordo con Mario: siamo proprio sicuri che "gira"? Il cliente vede solo la punta dell'iceberg, ma noi sviluppatori sappiamo cosa c'e' (o cosa *non* c'e') sotto quel "funziona".

Mi trovo proprio adesso a mettere le mani su codice "legacy" (ASP/VBScript/SqlServer): potrebbe essere diversamente visto che il 90% dei progetti sono di questo tipo? Fra sito web e database il codice ammonta a circa 500 mila righe che, a occhio e croce, potrebbero essere ridotte a 20 mila in un'implementazione .Net adeguata.

Inutile dire che in situazioni del genere l'Analisi - sempre se esite - e' la prima cosa a fare acqua, d'altra parte senza Analisi - di nuovo, concordo con Mario - non si va da nessuna parte. Personalmente, se l'intervento che mi e' richiesto e' minimale, cerco di fare tutto senza toccare per niente il codice legacy (wrappando e bridgando qua e la'). Altrimenti, almeno nella mia esperienza, tocca fare entrambe le cose: refactoring e' fondamentale (noi usiamo "pippo" ma qui usano "dude"...), ma, senza un po' di restructuring in parallelo, il refactoring da solo spesso non e' neppure fattibile. E - perlomeno nei casi non banali - senza Analisi non si fa nessun refactoring...

Insomma, i nodi vengono al pettine... e non c'e' scorciatoia che tenga... sempre parlando di software...

Ciao. -LV
Gravatar # re: Refactoring o... rewrite?
by LudovicoVan at 16/08/2007 20.19

@Fausto:

Permettimi un paio di considerazioni:

> Percentuale di visualizzazioni modificate
> Percentuale di Metodi e/o proprietà modificate
> Vengone aggiunte nuove funzionalità, che si possono separare dal codice oppure devo modificare la logica del codice esiste?

A parte che questa lista sembra implicare che non intendi fare refactoring, ma in ogni caso: come fai a fare queste stime su un codice (legacy) non "ingegnerizzato"?

> L'applicazione dovrà essere mantenuta ed aggiornata?

La risposta a questa domanda temo che sia sempre e comunque: si'...

-LV
Gravatar # re: Refactoring o... rewrite?
by LudovicoVan at 16/08/2007 20.26

Errata: pardon, quel "non intendi fare refactoring" dovrebbe essere "non intendi ristrutturare".
Gravatar # re: Refactoring o... rewrite?
by Alesssandro Scardova at 16/08/2007 23.00

Che dire... dipende! Se riesci a convincere il cliente che pagando ora 100 poi potrà eventualmente implementare una nuova feature a 50 e non a 200 sicuramente vai di rewriting, se il cliente non scuce il centone... mmm c'è da pensarci. Poi dipende da quanto pesa quel codice "vecchio" sull'applicazione, da quanto può conviverci, e da quanto hai voglia tu di rimetterci il centone ;)
Gravatar # re: Refactoring o... rewrite?
by LudovicoVan at 17/08/2007 14.08

> se il cliente non scuce il centone... mmm c'è da pensarci.

Dopo anni di questo tipo di quotidiane battaglie il mio approccio e' semplicemente: "Non ci penso proprio! NO WAY!!! O si fa come dico io, che tanto e' solo una questione di fiducia visto che i numeri cantano paradiso e nessun altro nei paraggi ci capisce un'acca, oppure ti trovi un altro consulente."

Non sto scherzando... E ti assicuro che a lungo termine paga, e non parlo (solo) del cliente...

> Poi dipende da quanto pesa quel codice "vecchio" sull'applicazione, da quanto può conviverci, e da quanto hai voglia tu di rimetterci il centone ;)

Sono d'accordo che un'Analisi e' d'obbligo, senza non si va da nessuna parte, ci si rimette solo - appunto - il centone... tanto vale andare a fare il pizzaiolo allora... :)

-LV
Gravatar # re: Refactoring o... rewrite?
by Alesssandro Scardova at 18/08/2007 7.50

>tanto vale andare a fare il pizzaiolo allora...
Azz.. ma se poi ti tocca tirare un impasto fatto da altri? "O l'impasto lo faccio IO o vi trovate un altro pizzaiolo!" E torniamo al punto di partenza... ;)
Gravatar # re: Refactoring o... rewrite?
by Emanuele DelBono at 19/08/2007 9.48

Se non hai una suite di test che garantisce che le tue modifiche non rompano il resto dell'applicazione puoi provare con il refactoring. Altrimenti l'approccio più corretto sarebbe scrivere i test verificare che siano verdi e poi iniziare il refactoring.
Gravatar # re: Refactoring o... rewrite?
by LudovicoVan at 20/08/2007 14.49

>> tanto vale andare a fare il pizzaiolo allora...
> Azz.. ma se poi ti tocca tirare un impasto fatto da altri? "O l'impasto lo faccio IO o vi trovate un altro pizzaiolo!" E torniamo al punto di partenza... ;)

Non ne faccio una questione "personale", forse non mi sono spiegato.

Fuori di metafora:

1) Faccio Analisi (con il supporto del cliente; se non c'e', urge cambiare cliente);

2) Espongo la situazione al cliente ("possiamo/non-possiamo riusare l'impasto", ovvero le 1-2-3 opzioni fattibili);

3) Se *a quel punto* mi dice "si' si', come no, tu intanto comincia a correggere i 'bug' che poi ne parliamo...", e' allora che gli do picche...

Spero che abbia piu' senso. -LV
Gravatar # re: Refactoring o... rewrite?
by LudovicoVan at 20/08/2007 14.51

> Altrimenti l'approccio più corretto sarebbe scrivere i test verificare che siano verdi e poi iniziare il refactoring.

Di nuovo: questo si puo' fare se il codice pre-esistente e' adeguatamente "ingegnerizzato", altrimenti...

-LV
Comments have been closed on this topic.