Come giustificare il tempo di refactoring del codice?

Quando si lavora su applicazioni legacy o brownfield, si è tentati di eseguire una "pulizia di primavera" sperando di ridefinire l'intera struttura. Questo non è in alcun modo giustificabile l'uso delle risorse. Dopo tutto, come si può giustificare la limitazione dello sviluppo del software di lavoro (solo il codice funzionante può essere rifattorizzato)? Riesci a garantire che il tempo speso per la fase di rifattorizzazione totale ripagherà in seguito e non causerà la degenerazione del progetto?

Come mangi un elefante? Un morso alla volta. Ogni volta che devi implementare una nuova funzionalità o correggere un bug, vedi se quella parte ha bisogno di un miglioramento. Come dice la regola del boy scout: "Lascia sempre il campeggio più pulito di quanto tu non abbia trovato." Il refactoring non dovrebbe essere una fase separata, è parte dello sviluppo di ogni giorno.

Quando la cultura della qualità viene introdotta nel team di sviluppo, la qualità migliorerà. Dopodiché non c'è nulla da giustificare alla direzione.

In generale, il refactoring dovrebbe essere fatto per abilitare un altro cambiamento che è necessario apportare al codice o come una fase di clean-up naturale dopo che è stata apportata una modifica al codice. In tal caso, non c'è nulla da giustificare. Il refactoring è semplicemente parte del processo di lavoro sul progetto. Il tempo è fatturato per il compito a cui stavi lavorando quando hai eseguito il refactoring.

Se non viene eseguito in piccoli incrementi, non si tratta di un vero e proprio refactoring, eh?

Tutte le buone risposte qui - ma potrei aggiungere una dimensione aziendale a questo. Lascia che ti chieda PERCHÉ / So-What? (pensa al tuo capo a punta di capelli (PHB) :)

PHB: why?
You: It'll make things easier to fix
PHB: So-what?
You: It'll increase throughput - we'll get new builds out the door quicker?
PHB: So-what?
You: Err...Happier customers?
PHB: WTF?
You: I mean increased recommendations, greater satisfaction, 
     more profit sooner due to low turnaround
PHB: Oh! Sounds nice. But it only "sounds" nice can I see it?
You: WTF?
PHB: Show me the money! (i.e. numbers please)
You: Oh! Brb...(go and put some numbers in simple spreadsheet to make your case)

Fondamentalmente devi fare un business case - eseguire alcuni numeri per chiarire il tuo processo di pensiero e far sì che i numeri riflettano il "beneficio" oggettivamente. Saprai anche quanto tempo ci vorrà, approssimerai i costi, ecc. Avrebbe senso. Se ne vale la pena, riceverai il segnale verde e forse guiderà anche l'iniziativa:)

Se pensi come posso misurare tutto prova questo libro

Il refactoring, come qualsiasi altra attività, deve avere un chiaro obiettivo definito per questo. Una volta che l'obiettivo è chiaro, si prenderà in considerazione lo stato attuale del progetto e la fase del ciclo di vita. Per un progetto di sviluppo completo all'80%, con un ritardo del 30% rispetto alla pianificazione, è necessario giustificare lo sforzo di refactoring basato sull'obiettivo prefissato. In questo esempio, se i pezzi del codice sono stati testati unitamente e funzionano bene in un ambiente di sviluppo, è difficile giustificare il refactoring.

Il fatto che 40 sviluppatori se ne siano andati potrebbe non essere così drammatico come sembra. Mi aspetto che questi sviluppatori abbiano consegnato codice funzionante che è stato rivisto e testato. Quindi, a meno che non ci siano problemi noti in questo codice, lo lascerei così com'è. L'idea è che in un grande progetto come il tuo, mi aspetterei che esistessero standard e procedure e che il codice non fosse un disastro completo.

Ricorda che il refactoring causerà molti se non tutti i test che sono stati fatti per essere ripetuti. Inoltre, poiché il refactoring di queste dimensioni non può essere eseguito da uno o due membri senior, il refactoring potrebbe introdurre problemi che non esistevano. Questo è un rischio che non dovrebbe essere trascurato.

Detto questo, non è insolito aggiungere compiti a un progetto quando accade l'imprevisto. Quindi, se gli sviluppatori scomparissero per qualche motivo, ciò sarebbe considerato un evento di natura speciale e qualsiasi azione per porre rimedio alla situazione deve essere presa. Sarebbe trattato come un incendio o un terremoto, ecc.

In sintesi, non rifarei un grande codice di lavoro in un grande progetto per nessuna buona ragione tecnica solida, specialmente perché sappiamo tutti che la maggior parte dei progetti di solito sono in ritardo.

Immagina di essere di fronte a un muro lungo e enorme. Devi andare dall'altra parte.

O si refactoring il muro al fine di costruire una porta, o si aggira intorno.

Valuta il tempo per entrambe le soluzioni e ottieni la tua giustificazione per il refactoring.

Non dimenticare di moltiplicare il tempo nella seconda soluzione per il numero di persone che hanno bisogno di andare dall'altra parte del muro.

Mentre leggo in una delle altre risposte, mangia questo elefante un boccone alla volta. Sono coinvolto nell'auditing di un grande progetto internazionale, in cui i membri del team sono distribuiti geograficamente. Dopo aver creato le prime due versioni del software, il team ha convenuto che i loro approcci, lo stile di codifica e le soluzioni di costruzione sono incoerenti. Hanno accettato di scrivere nuove parti dell'applicazione seguendo le nuove regole e convenzioni e quando (e solo allora) hanno dovuto modificare parte del vecchio codice, prima lo hanno rifattorizzato per soddisfare la nuova convenzione. Tutto funziona abbastanza bene. Il processo di refactoring è quasi al 5 ° mese, parte del codice è refactored, altri ancora non lo sono. Le nuove funzionalità sono portate in tempo, i clienti sono felici, gli sviluppatori sono felici, anche il team di controllo qualità è felice. Una situazione win-win:)

Il punto principale del refactoring è rendere le cose più facili in futuro. Non è possibile mostrare i profitti del refactoring a meno che non si confrontino più progetti a lungo termine con pochi e pochi, senza un costante refactoring. È generalmente accettato tra gli sviluppatori, che il refactoring riduce i costi di manutenzione e l'implementazione delle modifiche, ma è difficile provarlo dal punto di vista del business. La ragione principale per implementare il refactoring è ridurre Debito tecnico .

Inoltre, il refactoring dovrebbe essere un processo continuo e la spesa temporale per il refactoring dovrebbe essere inclusa nello stesso task di sviluppo. Avere uno speciale "compito di refactoring" non è una buona idea.