come pianificherai i giorni di refactoring mensili per eliminare il debito tecnico nella tua squadra?

Gli sforzi di refactoring dovrebbero essere definiti, pianificati e trattati come problemi regolari, non considerati come un grosso blob di reparti tecnici che dovrebbe sparire nel tempo a causa del fatto che alcuni intervalli di tempo sono stati riservati per questo. Prendilo sul serio, definisci quali sono i tuoi problemi e trattali come lavoro. È un lavoro.

Non inizierei in modo specifico a rielaborare le cose casuali a cui altrimenti non stai lavorando, a meno che non siano ESTREMAMENTE male. I test ignorati potrebbero essere un caso del genere se significa che la funzionalità che stanno testando non funziona.

Piuttosto, applicherei la filosofia di lasciare il codice in uno stato migliore di quello che hai trovato, ogni volta che devi toccarlo. Questo è molto più facile da vendere al business dell'azienda, anche se le funzionalità di implementazione potrebbero inizialmente richiedere un po 'più di tempo. Inoltre, riduce notevolmente le "oopsie" in cui si introduce un nuovo bug durante il refactoring, mentre non si trova nella funzionalità che si stava toccando.

Naturalmente, se il codice è inutilizzato, gettalo via. Hai il controllo della versione per quello.

Come nota a margine, ti consiglio di non usare il codice TODO se non hai intenzione di farlo nel ramo su cui stai lavorando. Puoi farlo subito o utilizzare un tracker dei problemi o qualcosa di simile per le modifiche rimanenti.

Questo riguarda anche il fatto che non si dovrebbe scendere a compromessi sulla qualità troppo spesso. A volte ci sono scenari di business validi per questo, ma alla fine voi come sviluppatori siete responsabili del buon codice. La spinta dal lato delle attività a fare le cose più velocemente sarà SEMPRE letteralmente lì, ma se ciò significa che stai scrivendo regolarmente codice di scarsa qualità e / o non verificato, questa è la tua responsabilità.

Nella mia esperienza di riduzione del debito tecnico, dovrai assicurarti di avere una buona copertura del codice. È difficile (e noioso) farlo in un colpo solo o anche se si mette da parte il tempo per farlo. Di solito l'ingegnere avrà un compito per risolvere un problema o implementare una nuova funzione.

Risolvi un problema

1. Scrivi test dove passa sotto lo scenario corrente (buggy).
2. Scrivi test che falliscono, cioè passerà dopo aver corretto il bug.
3. Fai meno lavoro per fare fallire il test 1 e testare 2 per passare. Non c'è bisogno di fare niente di speciale qui, vogliamo solo passare i test corretti.
4. Elimina il primo test che ora dovrebbe fallire.
5. Ora è sicuro rifattorizzare il codice poiché esistono test che supportano la logica aziendale. I principi SOLID ti aiuteranno qui.
6. Ora puoi rifattorizzare anche i test.

Implementa nuovo codice

1. In alcuni casi l'ingegnere dovrà prima scrivere dei test di passaggio sul codice che sarà interessato dalla nuova funzione.
2. Scrive test falliti per la nuova funzione, che passeranno in seguito dopo l'implementazione della nuova funzione.
3. Fai meno lavoro per far passare i test.
4. Ora refactoring il codice. I principi SOLID ti aiuteranno qui.
5. Adesso rifattori anche i test.

Il codice apparirà perfetto quando viene implementato per la prima volta. Più tardi (forse tra un mese) non sembrerà così carino. Se ci sono già test adatti, allora è facile e sicuro rifattorizzare il codice per adattarsi al nuovo ambiente di codice. Questo è un passo importante per mantenere il debito tecnico.

Le note di refactoring di Martin Fowler sono un ottimo punto di partenza.