Il codice di refactoring casuale è consentito nella mischia

sfondo

• La mia squadra usa la mischia
• Al momento non sono stati assegnati compiti
• Non ci sono più attività in sospeso nel backlog
• Oggi è la festa del lavoro per il mio cliente.

Non avendo molte cose da fare oggi volevo iniziare a refactoring del codice che continuo a vedere nel progetto a cui sto lavorando, ma al momento non mi è stato assegnato alcun compito di sprint per eseguire refactoring su larga scala.

Va bene in Scrum se inizio a eseguire il refactoring casuale del codice che ho e non ho scritto che mi disturba sempre ma non ho tempo altri giorni per ripararlo a causa di incarichi di altri giorni?

Che dire di altri giorni in cui ho tempo libero tra gli sprint.

In realtà lo faccio e credo nel refactoring continuo. Lo faccio sempre sui pezzi di codice su cui sto lavorando quando mi viene assegnata una storia, ma che dire di qualche altro codice che vedo che non è attualmente correlato a ciò su cui sto lavorando in quel momento?

Davvero non intendo attaccare altre risposte, ma nessun altro sta scrivendo test automatici qui? Ecco una lettura divertente di Martin Fowler per chiunque stia facendo Scrum senza adeguate pratiche di ingegneria del software. Anche Robert C. Martin dice molto su questo qui .

Quindi, alla mia risposta ... In breve, va così:

Sì, il codice di refactoring "a caso" è consentito in Scrum , a condizione che il team decida che dovrebbe essere fatto. (Dopotutto, si auto-organizza)

E ora per la lunga risposta:

È evidente che lasciare un debito sempre più tecnico dopo ogni Sprint è una ricetta per il disastro. Presto tutti rallenteranno man mano che il codice diventa più disordinato; ogni modifica sarà più difficile da apportare perché il codice è così complicato e disordinato che ci vuole più tempo per trovare i punti da cambiare che per apportare la modifica effettiva. È ancora peggio se si deve apportare una modifica in un modulo grande e disordinato di cui non si sa nulla, diventa impossibile ottenere / mantenere la produttività quando si aggiungono / cambiano persone nel progetto e così via.

Se una squadra vuole mantenere costante la sua velocità, deve essere in grado di mantenere pulita la base di codice per incrementare continuamente il software. Il refactoring è una pratica obbligatoria se si desidera mantenere la velocità per tutto il ciclo di vita del progetto e se si desidera mitigare il rischio di aggiungere / cambiare persone nel progetto e se si desidera essere in grado di apportare modifiche ai moduli, non si sa nulla circa e così via.

Tuttavia, il refactoring è un'attività molto pericolosa. Ripeto: è un'attività molto pericolosa . Cioè, a meno che non si disponga di una copertura di prova sufficiente per poter cambiare in modo sicuro e libero la base di codice. Se puoi semplicemente premere un pulsante per verificare se non si è rotto nulla, il refactoring diventa un'attività molto sicura; così sicuro, infatti, che fa parte del ciclo di TDD , che è la pratica che ti consente di creare una tale suite di test in primo luogo.

Ma, poiché i team di Scrum si autoorganizzano, alla fine il tuo team deve decidere qual è la cosa giusta da fare. Spero di averti dato alcuni argomenti nel caso tu debba convincere qualcuno. (Prestare particolare attenzione ai collegamenti nel primo paragrafo e ogni altro articolo a cui fanno riferimento)

Scrum non dice davvero nulla sul refactoring.

Ciò che Scrum dice è che se non hai compiti all'interno dello sprint su cui lavorare, dovresti supportare il resto della tua squadra per raggiungere l'obiettivo dello sprint. Anche se ciò significa prendere loro il caffè.
Se il tuo team concorda sul fatto che il refactoring del codice è il modo migliore per supportarlo (e che include l'infrastruttura in atto per garantire che il refactoring non introduca troppi nuovi bug), allora cerca di farlo.

Direi di no, non lo è. Questo è indipendentemente dal tipo di lavoro (refactoring, ecc.).

Come minimo, le attività dovrebbero essere create e inserite nello sprint corrente. Lo scopo del monitoraggio del tempo è catturare la tua velocità per essere in grado di tracciare gli sprint futuri. Se stai lavorando su cose senza tracciarle, avrai un impatto sulla velocità e non migliorerà nel tempo come previsto con una tracciabilità corretta (probabilmente non avrai abbastanza lavoro perché la tua velocità proiettata è inferiore alla tua velocità reale ).

Per quanto riguarda il lavoro di refactoring in sé, posso fare una tirata a riguardo, ma non lo farò perché non penso che sia la domanda principale a cui stai cercando di rispondere.

Sto per dire anche di no. Il re-factoring porta spesso a bug involontari se non viene gestito nel modo giusto.

Come GM, periodicamente mettevo tutti su un altro progetto e passavo una settimana a fare revisioni del codice / re-factoring / rinominare e applicare le convenzioni su un progetto. Questi sprint di re-factoring sarebbero quasi sempre di natura cosmetica. Qualsiasi riassestamento funzionale sarebbe pianificato in anticipo e coinvolgerebbe lo sviluppatore originale.

Il re-factoring funzionale dovrebbe sempre essere pianificato e coordinato come parte del processo di mischia in modo che il tempo possa essere monitorato e tutti i membri del team necessari siano disponibili per convalidare il processo. Uno sviluppatore non dovrebbe smettere di cambiare il codice scritto da un altro fuoripista perché molto probabilmente rovinerà lo sprint corrente per tutti. Soprattutto quando si tratta di tempo di unione del codice.

Se si tratta di un progetto che sei l'unico manutentore ed è il tuo tempo libero, allora può essere diverso supponendo che tu prenda provvedimenti per assicurarti di non causare ritardi inutili nello sprint corrente.

In caso di dubbi, chiedi al tuo responsabile.

EDIT: Voglio anche menzionare che un determinato pezzo di codice che non ti piace potrebbe avere un determinato obiettivo prestazionale associato ad esso. Potrebbe non piacerti, ma potrebbe essere più veloce di qualsiasi cosa tu possa costruire che si adatti al modo in cui vuoi usarlo. Solo un altro motivo per cui il re-factoring funzionale dovrebbe essere sempre un processo gestito.

Scrum non dice nulla sul refactoring (vedi una lezione di Robert C. Martin, "La terra che la mischia ha dimenticato").

In Scrum le attività riguardano le funzionalità del software specificate dal cliente, non i debiti tecnici da rimborsare mediante refactoring. Questi sono livelli di astrazione totalmente diversi. Il cliente per lo più non è in grado di valutare la necessità.

Scrum è la gestione di progetti statistici. Per ottenere misure significative di "quanto tempo ci vuole" devi conoscere le prestazioni (output per sprint). Confronti la stima e la durata reale di una funzione per almeno più di uno sprint per entrare nella statistica. Raccomando 5 sprint. Ma questo dipende dalla tua squadra.

La cosa principale è mantenere misure significative e comparabili per rendere possibile qualsiasi previsione. Ciò non accadrà se le prestazioni diminuiscono a causa di debiti tecnici.

Se ora pensi ancora alle attività di refactoring hai due problemi: 1. Un cliente, che non capisce, perché deve accettare un'attività che non produrrà una nuova funzionalità 2. Distorci totalmente le tue statistiche e quindi la tua capacità di prevedere quando cambi improvvisamente una variabile diversa che non era stata considerata negli sprint precedenti

In entrambi i casi, comprometti l'idea di mischia perché desideri parlare delle funzionalità con il cliente e fai previsioni affidabili per "Quanto tempo ci vuole?" in modo statistico. Per sicurezza devi mantenere la tua base di codice in una qualità costante (forse alta).

Il refactoring è per lo più un compito sotterraneo. "Grandi" refactoring significano che "piccoli" refactoring non sono stati elaborati in passato.

Un'ultima nota: se esegui refactoring assicurati di avere il componente sotto test che stai eseguendo il refactoring. Ohh, non hai dei test? Compiti un compito per scrivere test. Il tuo cliente sarà felice di sapere che il software che sta attualmente utilizzando non ha una copertura di prova sufficiente ...

Tieni le cose tecniche lontano dal cliente e fai il tuo lavoro come sviluppatore professionista.

Ecco un approccio: fai entrambi!

Il refactoring è spesso soggetto a errori o richiede più tempo che originariamente stimato come sottolinea @misterbiscuit.

Quindi considera un tentativo di farlo una bozza o un picco. In questa fase non è necessario chiedere l'approvazione o fare pubblicità.

Quindi, cerca di includerlo attraverso uno dei due canali:

• un biglietto esistente che tocca lo stesso codice / funzionalità in cui è possibile inserirlo in modo ragionevole. Ragionevolmente concordato con i membri del team.
• intero un biglietto da rivedere al prossimo incontro (o incontro settimanale, ecc. se a cascata). In quel momento puoi fare il caso.

Una volta ottenuto il buy-in effettivo, puoi cercare di applicare o ripetere il tuo picco e avere il codice effettivo unito nel ramo mainline (master, ecc.).

Ciò avrà diversi vantaggi:

• Tutti i tuoi codici attraverso lo stesso processo, vengono testati, QA, nella pipeline di rilascio, ecc.
• Ottieni un buy-in formale, anche dal responsabile del prodotto, che il refactoring fa parte del mestiere e non qualcosa che deve essere "nascosto" in vacanza. Chiediti perché non stai 'entrando di soppiatto' in una funzione reale può aiutare per la prospettiva.
• Puoi chiedere l'associazione, la revisione del codice, il qa, gli devops e tutto il resto del supporto che potrebbe essere necessario per la modifica del codice di factoring. Sarà tutto ufficiale, secondo la Politica e la Procedura e sopra la commissione.
• Se sei una società quotata in borsa con conformità SOX, probabilmente desideri / devi eseguire questo tipo di processo formale (ovvero documentarlo e quindi seguirlo).
• Ottieni una migliore reputazione sia con il product manager (il cambiamento è stato fatto rapidamente) sia con il team di sviluppo (codebase è stato migliorato).
• L'organizzazione sta cercando di preoccuparsi della qualità del codice, che è buona per produttività, morale, fidelizzazione dei dipendenti e molte altre ragioni.
• L'effetto sulla velocità del progetto può essere monitorato più facilmente quando tutto il lavoro è incluso. Può essere giusto non nominare alcun punto poiché la presenza stessa può essere usata per influenzare la velocità.
• È probabile che gli sviluppatori vedano strumenti che incoraggiano revisioni del codice più semplici come Fisheye, Github, ecc.
• È più probabile che gli sviluppatori vedano alcuni standard di base (a volte documentati, a volte no) che rendono più semplice la condivisione del codice e quindi il refactoring. A volte gran parte del refactoring è scegliere uno stile e quindi applicarlo in senso lato (sostituendo un mix di approcci con uno).

Un commento finale: evitare che il product manager ascolti la parola "random". Possono rispondere in modo più favorevole con l'aggiornamento del codice "mirato, strategico, che migliora le prestazioni". O service pack dell'applicazione. O qualunque sia la lingua che ti offre copertura.

Il refactoring casuale non ha senso. Ciò che ha senso è il refactoring di un codice che introdurrà la maggior parte dei vantaggi. Questo significa :

• risolvere un problema di progettazione o architettura
• migliorare l'attuazione

Va bene in Scrum se inizio a eseguire il refactoring casuale del codice che ho e non ho scritto che mi disturba sempre ma non ho tempo altri giorni per ripararlo a causa di incarichi di altri giorni?

Da questa risposta :

Mantenere il codice mantenibile deve essere un elemento nell'elenco di burn-down (se si utilizza uno Scrum). È importante quanto il nuovo sviluppo. Anche se potrebbe non sembrare qualcosa di "visibile all'utente", ignorarlo aumenta il tuo debito tecnico. Lungo la strada quando il debito tecnico si accumula in modo tale che la mancanza di manutenibilità del codice rallenta lo sviluppo, i ritardi nello sviluppo di nuove funzionalità saranno visibili ai clienti.

Nel mio lavoro precedente, abbiamo avuto una sorta di mischia, con sprint più grandi (2-3 mesi). Dato che abbiamo avuto alcuni ritardi tra gli sprint (1 mese), questa volta abbiamo usato per analizzare il software e refactoring il codice.