Mettere un carico supplementare sulla revisione del codice sul team a causa del refactoring

Il refactoring per motivi di refactoring, anche se serve un codice migliore, semplicemente non vale la pena, soprattutto in un contesto di business.

Come hai sottolineato, le tue revisioni del codice sono lunghe e impegnative per consentire al tuo team di rivedere adeguatamente. Tuttavia, non dare loro una revisione adeguata non è un'opzione praticabile. Cosa succede se non sei disponibile (o se ne vattene) e queste altre persone hanno bisogno di mantenere il codice? Possono capire lo stato attuale del codice e possono risolverlo. Se non hanno l'opportunità di rivedere e porre domande, tu saresti l'unico a capire i cambiamenti e il loro impatto sul sistema. Un altro paio di occhi o due è anche utile per assicurarsi di non aver introdotto un bug (forse la copertura del test non è così buona come si pensa) o problemi di prestazioni. Non vuoi timbrare le richieste di pull.

La mia raccomandazione è di lavorare meglio con il tuo team per pianificare queste modifiche. Dal momento che hai identificato alcuni refactoring che, secondo te, renderanno il software più facile da capire e da mantenere, dovresti registrarli da qualche parte in modo che non vengano dimenticati e possano essere pianificati correttamente con l'altro lavoro che deve essere fatto da Il gruppo. Sui team con cui ho lavorato, in genere hanno utilizzato il tracker dei difetti, spesso con un tipo di biglietto o un'etichetta o un tag specifico per il debito tecnico. Puoi ottenere il dettaglio che vuoi in ciò che pensi che dovrebbe accadere. In questo caso, forse collega le richieste di pull al lavoro, ma non aspettarti che si uniscano subito.

Invece di lavorare su queste modifiche al codice, in futuro ti consiglio semplicemente di registrare il potenziale per lavorare e parlare con il tuo team per assicurarti di lavorare sul valore aggiunto. Forse il team sarà d'accordo sul fatto che questo tipo di lavoro è prezioso. Se lo è, faranno il tempo per fare le revisioni del codice appropriate. Tuttavia, se non è prezioso, è uno spreco (nel senso più snello del termine - un lavoro parzialmente svolto che non è fuso per il rilascio potenziale e l'attesa sono entrambi sprechi e magra cerca di eliminare gli sprechi dai processi di sviluppo).

Il refactoring è una tecnica, non un deliverable.

Il codice sottoposto a revisione dovrebbe essere più facile da mantenere, più facile da estendere o più facile da comprendere. Se lo è, allora il refactoring è un approccio "paga in avanti" per essere pronto a consegnare la prossima sfida, in meno tempo. Tale flessibilità può talvolta aiutare la tua squadra a conquistare quote di mercato o almeno a tollerare la prossima emergenza.

Ora, se il codice sottoposto a revisione non può dimostrare tali benefici (e preferisco le dimostrazioni sui patter verbali), il refactoring potrebbe aver reso il codice più difficile da mantenere, più difficile da estendere o più difficile da comprendere. Il refactoring da solo non è un indicatore della qualità del codice, ma come ci si sposta tra diversi stati di qualità del codice.

Se i vantaggi sono evidenti, l'argomento contro il refactoring è solo un argomento contro il lavoro. Tali argomenti probabilmente hanno portato il codice in uno stato povero. Ora che è il momento di estinguere il debito tecnico, il team sta chiedendo se possono differire il pagamento di qualche altro mese (o anni).

Se i benefici non sono chiari, l'argomento contro il refactoring è un argomento contro il lavoro con valore dubbio. Tali argomenti sono salutari e indicano che la squadra non è disposta a sprecare tempo e sforzi.

Il problema è di valutazione, ma è più difficile valutare il valore quando il reclamo riguarda la tecnica e non il valore. Cercherò di fare in modo che i reclami del team includano commenti sul valore e questo dovrebbe aiutarti a determinare se il valore è in questione o solo la quantità di lavoro da svolgere.

Per illustrare (si spera con umorismo), potrei lamentarmi di non volere più tollerare il vostro camminare e chiedere che smettiamo di camminare perché ci vuole così tanto tempo e fatica. Questo è un argomento sciocco o buono, a seconda che tu stia camminando nella giusta direzione (presumendo che tu sappia anche come si presenta la destinazione).

I principali motivi per il refactoring:

1. Refactoring per semplificare l'aggiunta di una funzione con valore per il cliente.
2. Refactoring per rimuovere una cattiva scelta di stile che ha causato un bug con priorità alta.
3. Refactoring per aiutare a mettere il codice sotto test che ha una logica interessante e difficile da prevedere.
4. Refactoring per rendere leggibile questo codice .... aspetta, perché stiamo guardando questo codice se non abbiamo lavoro da fare qui?

Il quarto è quello con cui faccio sempre i conti. Vedo un refactoring e voglio farlo ma non posso giustificarlo. A volte rifatto cose del genere e non lo faccio mai perché tutto quello che sto facendo è cercare di schiarirmi le idee. Lo scarico in una cartella di posta indesiderata dove probabilmente non vedrà mai più la luce del giorno. Se qualcuno mi chiede cosa sto facendo, io dico "Oh, sto solo cercando di ingannare il codice base. A volte leggo con le dita".

Niente di sbagliato in questo, quando non hai niente di meglio da fare.

I rifattori possono essere grandi, ma possono anche essere complicati e devono essere affrontati in quanto tali.

Al lavoro seguiamo la regola boy-scout che significa che ogni volta che tocchiamo il codice, proviamo anche a pulirlo nell'ambito dello scopo del nostro lavoro.

Ad esempio, se sto lavorando per correggere un bug in una singola classe, potrei anche cercare errori di battitura, nomi di metodi confusi o codice ridondante. Se ho un problema con il design e la struttura generale di quella classe e sono genitori / figli / clienti, prenderò nota del mio problema con la mia squadra e la mia richiesta di pull, ma non cambierò la questione .

Quando si tratta di refactoring come l'aggiornamento di una classe estremamente comune o di un'interfaccia comune o di una logica confusionaria, SRP, ecc. Di solito costruisco lentamente un elenco di quelli nel tempo e una volta per sprint o 2 se qualcuno ha cicli extra, possono prendere un paio di punti per un refactoring dove affrontano tutto in una volta, e tutta la squadra è consapevole e preparata per questo.

Qualcosa da notare qui non c'è fine a un refactoring perfetto ... è una tana del coniglio che andrà sempre avanti. Pertanto, i refattatori dovrebbero essere ben pianificati, con un ambito ben definito e un intervallo di tempo adeguato.

Buona fortuna!