Come gestisco il refactoring che richiede più tempo di uno sprint?

Se hai il lusso di ritardare il refactoring, ti suggerisco di focalizzare le iterazioni sull'aggiunta di test unitari e test di integrazione automatizzati al punto in cui puoi rifattare il codice base in modo constrongvole e quindi effettuare il refactoring in un singolo sprint.

Il mio suggerimento:

1. Crea un ramo
2. Unisci quotidianamente dal tronco al tuo ramo e risolvi i conflitti.
3. Lavora finché non è finito. Il tuo ramo potrebbe trovarsi al di fuori dello sviluppo del core per diversi sprint.
4. Unisci di nuovo al tronco.

Non c'è modo di aggirare il fatto che probabilmente diventerà brutto. Non ti invidio. Nella mia esperienza, quando cambi drasticamente un progetto, è più facile fondere lo sviluppo continuo nel nuovo paradigma, anziché fondere in qualche modo il nuovo paradigma in un tronco ora cambiato dopo che tutto è finito. Eppure, farà male.

Non è possibile eseguire tutte le attività in uno sprint (artificiale) di 2 settimane, quindi è necessario il buon senso. Se non può più essere rotto, e deve essere fatto, vai avanti e fallo. Il processo non è più importante del risultato finale, e dovrebbe essere visto come una linea guida piuttosto che come una legge irrisolta.

Fai solo uno sprint di 3, 4 o 5 settimane. Che importa? Ovviamente sei convinto che nulla può essere fatto in un arco di tempo più breve, quindi smetti di combatterlo.

Basta non dire ai tuoi compagni della Royal Society of Blind Agile Adherance.

Raccomando di iniziare con il libro Lavorare efficacemente con il codice legacy , di Michael Feathers. Egli copre una varietà di tecniche per ridurre l'ambito delle modifiche allo stile di refactoring.

Nel nostro negozio, quando abbiamo grandi attività di refactoring o riscrittura che non possono essere completate in una finestra di rilascio, lasciamo la funzionalità così com'è nel sistema. Ma, iniziamo le nuove funzioni lego-block refactored come il tempo lo consente. Alla fine, arriviamo a uno stato in cui abbiamo abbastanza blocchi lego, che uno sprint fornisce tempo sufficiente per collegare i blocchi lego nell'applicazione e accenderlo per gli utenti.

Più concisamente, interrompiamo o rielaboriamo grandi funzioni usando nuovi nomi. Poi, alla fine, usiamo il nostro lavoro rinominato, refactored invece del vecchio codice.

Dedica uno sprint a come mantenere il corretto funzionamento del codice a metà refactoring. Questo può assumere la forma di metodi e classi deprecati, wrapper, adattatori e simili. Il tuo refactoring può rendere il codice più sporco per un breve periodo di tempo per essere più pulito a lungo termine; va bene. In questo momento stai dicendo che non può essere fatto. Non penso che sia giusto - pensa a come sarebbe il tuo processo se potrebbe essere fatto, pensa a quali passi puoi fare per renderlo tale. Quindi tuffati.

+1 sulla risposta di Corbin March, questo è esattamente quello che stavo pensando. Sembra che la tua base di codice sia un po 'brutta e ci vorrà più di un singolo ciclo di sprint per ripulirlo.
Quindi, proprio come ha detto Corbin,

1. diramalo in un "progetto di refactoring"
2. verifica il cambio del tuo ramo
3. promuovere l'ambiente di test per il test del QA
4. si uniscono di nuovo in modo incrementale nel trunk fino al termine del refactoring.

Sono sicuro che non avresti problemi a venderlo al tuo responsabile di sviluppo, se i tuoi PM hanno difficoltà a vederlo poi spiegano loro che Roma non è stata costruita in un giorno e ripulire tutta la spazzatura Gettare per le strade di Roma non si farà neanche in un giorno. Il refactoring richiederà un po 'di tempo, ma alla fine ne varrà la pena in termini di manutenzione più semplice, rilasci di miglioramenti più rapidi, meno ticket di produzione e SLA più soddisfacenti.

Anche se la riprogettazione che si vuole veramente fare è un compito importante, sarebbe possibile rifattorizzare pezzi più piccoli per rompere / disaccoppiare le dipendenze individuali? Sai, quando sei nel dubbio, aggiungi l'indecisione. Ciascuno di questi disaccoppiamenti dovrebbe essere un compito più piccolo di quello mastodontico che non è possibile completare.

Una volta rimosse le dipendenze, dovresti essere in grado di suddividere le restanti attività di refactoring per essere ottenute all'interno degli sprint.

Nel progetto per cui sto lavorando al momento, stiamo utilizzando sprint di 4 settimane. E a volte non possiamo terminare una user story e la riavviamo solo durante lo sprint seguente.

Tuttavia, IMHO dovrebbe essere possibile suddividere un refactoring in storie più piccole che si adattano a uno sprint di 4 settimane. Se non riesci a portare il codice in uno stato coerente entro 4 settimane, ho la sensazione che tu stia riscrivendo la tua applicazione piuttosto che refactoring.

Raccomando che quando alcune attività impiegheranno più tempo del ciclo di sprint di 2 settimane, l'attività verrà eseguita per un'altra volta. Il tuo team ha identificato la necessità di refactoring e questo è importante. A volte, non c'è altra opzione ... e, sì, quello fa schifo.

Quando verrà il momento di iniziare il refactoring, dovrai semplicemente sospendere i normali sprint. Non hai scelta. Usa il controllo della versione smart: branch, refactor, test, unisci. C'è sempre un momento nel quale il refactoring di alcuni progetti di grandi dimensioni ha la priorità sulle funzionalità. Se possibile, tenterei anche di separare le preoccupazioni per una migliore flessibilità.

Avendo recentemente affrontato lo stesso problema con una parte della nostra base di codice (che è anche un po 'più grande), spero di poter condividere alcune considerazioni con voi. Nella mia situazione, il codebase era stato sviluppato da un altro team, quindi nessuno degli sviluppatori originali era coinvolto in questo refactoring. La mia esperienza con il codebase è stata di circa 1 anno, e un altro sviluppatore ha lavorato per 2 anni.

Consentitemi due piccole note riguardanti le altre risposte qui:

• Branching ti aiuterà a creare un parco giochi per te stesso, ma non unire mai le tue modifiche al bagagliaio in un grande set di modifiche. Ti troverai nei guai seri con il resto della squadra.
• Devi farlo in modo incrementale e può essere fatto. Niente scuse. Leggi Lavorando in modo efficiente con il codice legacy . Leggi di nuovo.
• Pensare di poter fare un grande passo è un errore. Anche se sembra più un lavoro, farlo in modo incrementale è molto più facile da gestire.

Passare apparentemente "fuori prenotazione" per due settimane o più non passerà inosservato. Devi assicurarti di essere supportato dalla gestione del progetto e, ancora più importante, dal team. Se la squadra non è impegnata in questo refactoring (e questo significa, fallo ora, non in un lontano futuro), ti troverai nei guai.

Non farlo da solo, usa la programmazione delle coppie. Ciò non significa necessariamente che devi sempre sederti davanti alla stessa tastiera, ma puoi gestire attività piccole e ristrette (ad es. Scrivere test che catturino il comportamento di questa classe) individualmente.

Fai un Refactoring a Scratch e trattalo come tale. (Una sorta di refactoring del prototipo "a tiro", il bit "da buttare via" è importante!) Onestamente, è improbabile che tu conosca tutte le implicazioni che il tuo refactoring avrà. Un refactoring dei graffi ti aiuterà in alcuni aspetti:

• Scoprirai pezzi del sistema che non hai mai saputo di esistere.
• Avrai una visione molto migliore su come i moduli si interconnettono
• Scoprirai un nuovo modo di raggruppare il tuo sistema in moduli, probabilmente molto diversi dalla tua attuale comprensione. Discuti approfondimenti con il tuo partner. Prova a distillare la tua nuova vista. Scrivi un breve whitepaper sull'architettura (o disegna un diagramma) che indichi dove si trovano le cose al momento e dove dovrebbero appartenere logicamente.

Quando hai eseguito il refactoring del tuo scratch, spero che scoprirai che non puoi semplicemente andare e cambiare tutto dappertutto. Ti sentirai male, è solo un gran casino e non puoi semplicemente capovolgere un interruttore e farlo funzionare. Questo è quello che è successo a me, potrebbe essere diverso nella tua situazione.

Tuttavia, il mio partner e io abbiamo avuto una migliore comprensione del nostro sistema. Ora siamo stati in grado di identificare singoli, più piccoli (anche se ancora grandi) refactoring / riprogettazioni. Abbiamo catturato la nostra visione del sistema in un diagramma e l'abbiamo condivisa con il team, insieme agli elementi arretrati che abbiamo elaborato per implementare quella visione. Autorizzati dal consenso comune, abbiamo deciso quali elementi implementeremo nel corso della prossima iterazione.

Un'ultima cosa che ci ha aiutato è stata l'utilizzo di una grande lavagna. Ci sono troppe cose da tenere nella tua testa. È assolutamente importante che tu tenga le note. Scrivi te stesso una nota di de-briefing alla fine della giornata, catturando ciò che hai fatto oggi e che vuoi fare domani. Aiuta a rilassare i grandi tempi e hai bisogno di un momento di relax se vuoi tenere il passo con il compito. Buona fortuna!

Avvia una finestra di manutenzione durante la quale non vengono eseguiti ulteriori sviluppi. Eseguire la riprogettazione, quindi riprendere gli sprint di sviluppo.

Abbiamo due tipi di lavori a nostra disposizione:

1. L'uomo lavora ora
2. Genius funziona

Il refactoring di solito consiste nel primo tipo di lavoro, dal momento che molti metodi sono già noti agli sviluppatori come DRY , SRP , OCP , DI , ecc. Quindi quando un progetto richiede due mesi per essere refactored, semplicemente dura due mesi , non c'è modo di aggirarlo. Pertanto, il mio suggerimento sarebbe quello di non ridefinire il progetto originale e lasciarlo funzionare sulla sua situazione attuale. Smetti di ricevere nuove richieste e requisiti da parti interessate e proprietario del prodotto . Quindi lascia che il team lavori sul progetto fino a quando non viene refactored e pronto per andare.

Un suggerimento che può aiutarti: se hai codice non testato tale da non avere il tempo sufficiente per refactor e riesaminarlo entro lo sprint di due settimane, considera prima di fare qualche altro piccolo cambiamento non correlato ( s) al codice in modo che tu possa concentrarti sulla scrittura di test per il primo sprint o due. Forse puoi identificare diversi client non testati del codice che vuoi refactoring; scegli un cliente e apporta alcune modifiche di qualche utilità all'azienda che ti costringono a scrivere test per quel cliente. Una volta che hai più familiarità con il codice, dal lavorare con esso, e hai più test, e hai ottenuto alcuni piccoli refactoring contribuendo, sarai in una posizione molto migliore per eseguire il refactoring e il (ora più facile ) testare entrambi in un'unica iterazione.

Un altro approccio consiste nel fare una copia del codice incriminato, rifattorizzarlo e quindi spostare i client uno alla volta nel nuovo codice. Questo lavoro può essere suddiviso tra iterazioni.

E non arrenderti: non accettare semplicemente che un grande refactoring non può essere suddiviso in passaggi più piccoli. L'approccio più semplice / veloce / migliore potrebbe richiedere più tempo di un'iterazione. Ma ciò non significa che non ci sia modo di fare blocchi di dimensioni iterative.