Flusso di lavoro, modifica di elementi non inclusi nell'attività corrente

Di solito, quando programma, ho davanti a me un compito chiaro, ma trovo cose fastidiose che vorrei ripulire mentre proseguo.

Qui vedo tre opzioni:

• Fallo in seguito (potrebbe essere dimenticato / dover passare del tempo ad aggiungere un biglietto)
• Fallo ora e impegnalo insieme al mio lavoro attuale (poco chiaro)
• Fallo ora e commettilo separatamente (devi trovarlo, potrebbe commettere un errore e scegliere l'opzione 2 involontariamente)

Questo è probabilmente abbastanza semplice, ma quali sono alcuni modi per aggirare questo usando svn / git / other?

Personalmente, penso che dipenda :-).

• Per le piccole correzioni , l'opzione tre (ora, in un commit separato) è la migliore, perché il sovraccarico di farlo in un secondo momento non ne vale la pena. In tal caso, devi solo creare un commit separato. Come farlo dipende dal VCS che usi ed è una domanda separata :-).

• Se si tratta di una correzione più grande , si crea un ticket. Altrimenti, rischi di farti deragliare costantemente dal tuo compito principale ("Oh, guarda, un'altra opportunità per il refactoring, oh, ce n'è un'altra, e lì, e lì ...").

Considera questo. Quando "trovi cose fastidiose (...) da ripulire" e prendi una decisione esecutiva per farlo, stai tagliando il resto della tua squadra da una discussione e una decisione prioritaria. Stai lasciando che la tua agenda abbia la meglio su tutti gli altri a causa della tua relazione privilegiata con il codice. Non penso sia carino. Per esperienza, porta anche a risentimenti per team / azionisti.

Invece, creare un problema / attività per la pulizia / refactoring. Mentre è fresco nella tua mente, elenca i motivi per cui è importante: stime di maggiore stabilità, facilità di manutenzione, quel genere di cose. Forse includere una stima dello sforzo a seconda di come funziona il tuo team. Quindi nella prossima riunione di selezione / assegnazione / priorità delle attività, presentare l'attività di refactoring e posizionarla rispetto ad altre attività. Come squadra, decidere quando dovrebbe essere completato.

Per favore, non pensare che ti sto dicendo di gettare il buon senso in nome dei principi. Usa la tua testa. Se c'è qualcosa di brutto nella funzione che stai modificando, non è una nuova attività di refactoring. Risolvilo e controlla tutto. Se la ridenominazione della proprietà con cui stai lavorando con qualcosa di più sensato influisce su un paio di file di origine extra, non è una nuova attività di refactoring. Risolvilo e controlla tutto. Se, d'altra parte, non ti piace il modo in cui un altro sviluppatore (Mitch, odio quel ragazzo) ha fatto qualcosa in una funzione che non stai modificando e che la funzione sembra funzionare bene, lasciarlo solo per ora. Crea un'attività di refactoring e presenta il tuo caso al tuo team.

Se il refactoring viene sempre rifiutato dal tuo team a favore di nuove funzionalità, inizia a cercare un altro lavoro. È più facile trovare un lavoro quando ne hai già uno.