Come giustificare i tempi di refactoring del codice?

Avere un progetto molto grande più di 70k LOC.

Il progetto ha sicuramente bisogno del refactoring del codice in Core Framework e anche in altre parti. All'inizio del progetto non è stato fissato alcun tempo per il refactoring. Tuttavia, con il tempo e più di 40 sviluppatori uniti e lasciato il progetto. Dal mio punto di vista è indispensabile.

Quali sarebbero i tuoi punti chiave nella discussione e nella difesa di un corretto principio di sviluppo del software?

Quando si lavora su applicazioni legacy o brownfield, si è tentati di fare una "pulizia di primavera" nella speranza di rimodellare il tutto. Questo non è in alcun modo giustificabile l'uso delle risorse. Dopotutto, come è giustificabile arrestare lo sviluppo del software funzionante (solo il codice funzionante)? Potete garantire che il tempo speso per la fase di grande refactoring ripagherà in seguito e non causerà degenerazione nel progetto?

Come mangi un elefante? Un boccone alla volta. Ogni volta che devi implementare nuove funzionalità o correggere un bug, vedi se quella parte ha bisogno di essere migliorata. Come dice la regola del boy scout: "Lascia sempre il campeggio più pulito di quello che hai trovato." Il refactoring non dovrebbe essere una fase separata, fa parte dello sviluppo quotidiano.

Quando questa cultura della qualità viene presentata al team di sviluppo, la qualità migliorerà. Dopodiché non c'è più nulla da giustificare per la direzione.

In generale, è necessario eseguire il refactoring per consentire un'altra modifica che è necessario apportare al codice o come passaggio di pulizia 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 viene fatturato per l'attività su cui stavi lavorando quando hai eseguito il refactoring.

Se non è stato fatto con piccoli incrementi, allora non è davvero refactoring, eh?

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

PHB: perché?
Tu: renderà le cose più facili da risolvere
PHB: E allora?
Tu: Aumenterà la produttività - avremo nuove build fuori dalla porta più velocemente?
PHB: E allora?
Tu: Err ... Clienti più soddisfatti?
PHB: WTF?
Tu: intendo maggiori raccomandazioni, maggiore soddisfazione, 
     maggiori profitti prima grazie al basso turnaround
PHB: Oh! Suona bene. Ma solo "sembra" bello posso vederlo?
Tu: WTF?
PHB: Mostrami i soldi! (cioè numeri per favore)
Tu: Oh! Brb ... (vai e metti alcuni numeri in un semplice foglio di calcolo per rendere il tuo caso)

Fondamentalmente è necessario presentare un caso aziendale: eseguire alcuni numeri per chiarire il processo di pensiero e ottenere i numeri per riflettere obiettivamente il "beneficio". Saprai anche quanto tempo ci vorrà, i costi approssimativi ecc. Dovrebbe avere senso. Se ne vale la pena, riceverai il segnale verde e forse guiderai anche l'iniziativa :)

Se pensi come posso misurare tutto prova questo libro

Il refactoring, come qualsiasi altra attività, deve avere un obiettivo chiaro definito per questo. Una volta chiarito tale obiettivo, prendere in considerazione lo stato del progetto e la fase del ciclo di vita correnti. Per un progetto di sviluppo completo dell'80%, con un ritardo del 30% nei tempi previsti, è necessario giustificare lo sforzo di refactoring in base all'obiettivo prefissato in precedenza. In questo esempio, se i pezzi di codice sono stati testati in unità 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 quegli 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 aspetto che esistano standard e procedure e che il codice non sia un disastro completo.

Ricorda che il refactoring provocherà la ripetizione di molti, se non tutti, i test effettuati. Inoltre, poiché il refactoring di queste dimensioni non può essere eseguito da uno o due membri senior, il refactoring può introdurre problemi che non esistevano. Questo è un rischio che non deve essere trascurato.

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

Riassumendo, non rifatterò il codice di lavoro di grandi dimensioni in un progetto di grandi dimensioni senza una valida ragione tecnica solida, specialmente perché sappiamo tutti che la maggior parte dei progetti è generalmente in ritardo.

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

O rifatti il ​​muro per costruire una porta, o lo aggiri.

Stimare il tempo per entrambe le soluzioni e ottenere la giustificazione per il refactoring.

Non dimenticare di moltiplicare il tempo nella seconda soluzione per il numero di persone che devono 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 geograficamente dispersi. Dopo aver creato le prime due versioni del software, il team ha concordato che i loro approcci, lo stile di codifica e le soluzioni di costruzione sono incoerenti. Hanno concordato di scrivere nuove parti dell'applicazione seguendo le nuove regole e convenzioni e quando (e solo allora) devono cambiare parte del vecchio codice, prima lo rifattorizzano per soddisfare la nuova convenzione. Tutto funziona abbastanza bene. Il processo di refactoring è quasi al quinto mese, parte del codice viene refactored, altri ancora no. Le nuove funzionalità sono introdotte in tempo, i clienti sono felici, gli sviluppatori sono felici, anche il team QA è felice. Una situazione vantaggiosa per tutti :)

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 realizzati e pochi senza refactoring costante. È generalmente accettato da tutti gli sviluppatori che il refactoring riduce i costi di manutenzione e implementazione delle modifiche, ma è difficile dimostrarlo dal punto di vista aziendale. Il motivo principale per attuare il refactoring è ridurre il debito tecnico .

Inoltre, il refactoring dovrebbe essere un processo continuo e il tempo dedicato al refactoring dovrebbe essere incluso nel compito di sviluppo stesso. Avere un "compito di refactoring" speciale non è una buona idea.