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

12

Di solito quando programmo, ho un compito chiaro davanti a me, ma trovo cose fastidiose che mi piacerebbe ripulire mentre vado avanti.

Qui vedo tre opzioni:

  • Fatelo dopo (potrebbe essere dimenticato / devo passare il tempo ad aggiungere un ticket)
  • Fallo ora e esegui il commit insieme al mio lavoro corrente (non chiaro)
  • Fallo ora e lo commetti separatamente (devi trovarlo, potresti commettere un errore e andare per l'opzione n. 2 involontariamente)

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

    
posta Nattfrosten 02.12.2015 - 07:32
fonte

2 risposte

7

Personalmente, penso che dipenda: -).

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

  • Se è una correzione più grande , crei un ticket. Altrimenti, rischi di essere deragliato costantemente dal tuo compito principale ("Oh, guarda, un'altra opportunità per il refactoring, oh, c'è un altro, e lì, e lì ...").

risposta data 02.12.2015 - 11:56
fonte
5

Considera questo. Quando "trovi cose fastidiose (...) per ripulire" e prendi una decisione esecutiva per farlo, stai tagliando il resto della tua squadra da una discussione e decisione prioritarie. Stai permettendo a il tuo ordine di battere a caso tutti gli altri a causa della tua relazione privilegiata con il codice. Non penso sia carino Dall'esperienza, porta anche a risentimenti di team / azionisti.

Invece, crea un problema / attività per il clean-up / refactoring. Mentre è fresco nella tua mente, elenca le ragioni per cui è importante: stime di maggiore stabilità, facilità di manutenzione, quel genere di cose. Forse include una stima dello sforzo a seconda di come funziona la tua squadra. Quindi, nella riunione successiva di selezione / assegnazione / priorità dell'attività, presentare l'attività di refactoring e posizionarla rispetto ad altre attività. Come squadra, decidi quando dovrebbe essere completato.

Per favore, non pensare che ti sto dicendo di buttar via il buon senso nel nome dei principi. Usa la tua testa. Se c'è qualcosa di brutto nella funzione che stai modificando, non è una nuova attività di refactoring. Risolvi il problema e controlla tutto. Se rinominare la proprietà con cui lavori con qualcosa di più sensibile interessa un paio di file sorgente aggiuntivi, non è una nuova attività di refactoring. Risolvi il problema 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 ha detto la funzione sembra funzionare bene, lascia stare da solo per ora. Crea un'attività di refactoring e presenta il tuo caso al tuo team.

Se il refactoring è sempre sottovalutato dalla tua squadra a favore di nuove funzionalità, inizia a cercare un altro lavoro. È più facile trovare un lavoro quando ne hai già uno.

    
risposta data 02.12.2015 - 22:06
fonte

Leggi altre domande sui tag