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.