Sembra che dopo aver scritto una quantità significativa di codice ho avuto questa sensazione ansiosa di non averlo fatto nel miglior modo possibile, e finisco per refactoring e spendere continuamente troppo tempo nel progetto, o non farlo mai a volte. Succede mai a qualcun altro, e come ti occupi di questo?
Mi piacciono questi momenti quando capitano a me.
Il motivo: se non guardassi indietro al mio lavoro e pensassi che c'è qualcosa che avrei potuto fare meglio di quanto non avresti fatto da sviluppatore. Pertanto, quando si verificano questi momenti di illuminazione, abbracciali e prendi nota di ciò che hai appreso. Considera il tuo calendario per il progetto corrente e, se possibile, rifatta il codice, se non è possibile, prendi la lezione e usalo nelle future implementazioni per i progetti.
In ogni caso, imparare dai propri errori è una grande cosa!
Sembra che tu possa sempre refactoring, vero? Provo a limitare il refactoring solo quando cerco di risolvere altri problemi. Ad esempio, refactoring quando hai un problema di prestazioni e refactoring con l'aiuto di risolverlo - refactor quando hai bisogno di aggiungere nuove funzionalità e refactoring ti aiuterà a risolverlo
Ecco alcune regole per limitare questa attività e renderla più produttiva:
Ad essere onesti, mi preoccuperei di più se stavi scagliando enormi quantità di codice e pensassi che è tutto perfetto e non ha bisogno di alcun refactoring ...
Quando ero più giovane e inesperto, ero molto arrogante riguardo alle mie capacità di programmazione, e tendevo sempre ad immaginare che è possibile progettare e pianificare davvero bene - e che una volta arrivato alla fase di implementazione lo sbalzo e sarà tutto perfetto.
La realtà è quasi l'opposto. Alcuni dicono addirittura che non appena inizi a programmare dovresti essere in modalità di manutenzione. L'idea qui è che la fase di "Implementazione" di SDLC non esiste realmente come tale, perché non dovresti mai mettere da parte bug fixing o refactoring e fingere che il codice che stai producendo sia "fresco" e perfetto.
Tutto ciò detto, suppongo che IS sia possibile diventare troppo ossessivi riguardo al refactoring. Non l'ho ancora visto. E più esperienza ho, più penso che sarebbe una buona cosa se più team di software rifiutassero di lavorare in modo serrato con scadenze strette e di indebitarsi tecnicamente. Dopotutto, questo è il motivo più comune per cui il refactoring viene messo da parte nel mondo reale.
Suggerirei di non dipendere esclusivamente dal sentimento o dall'odore del codice.
Enumera chiaramente cosa c'è di sbagliato nel codice e quali sono le soluzioni. Scherzi a parte, scrivilo, perché vorrai verificare quanto sia efficace il tuo refactoring contro questo.
Identifica i modi per abbattere il refactoring in blocchi ottenibili e assegnargli la priorità. Fai in modo che la disciplina si concentri solo sullo scopo di ogni blocco, evitando tangenti che possono compromettere il tuo compito.
Inoltre, identifica quali test di unità è possibile scrivere rispetto al codice esistente prima di procedere. Se ci sono già test approfonditi, è una grande cosa. La mancanza di test unitari rappresenta una grande opportunità per fare alcuni.
Non ci sono dubbi che cado in questa trappola, ma alcuni refactoring sono importanti per il futuro supporto / debug.
Quando scrivi una parte importante del codice diventa molto facile mantenere le righe di codice nel metodo che viene attualmente scritto. Quando ho completato una parte importante del codice, inserisco un commento todo: revisione del codice . Poi qualche giorno dopo eseguirò la revisione del codice e il refactoring di conseguenza. Se ho difficoltà a leggerlo qualche giorno dopo, cosa succederà tra qualche mese o qualche anno.
Cado in questa trappola quando imparo per la prima volta una lingua o una tecnologia. Ad esempio, quando impari per la prima volta java, immagina di scrivere un'app web con un servlet, pensando che sia la strada giusta. Poi ti rendi conto che c'è jsp e pensi che quello che è più recente abbia probabilmente ragione. Poi, a metà strada, trovi Struts e forse alcuni oggetti EJB, dopodiché trovi Spring (basato su xml) dopodiché trovi le fantastiche annotazioni @MVC, dopodiché lo trovi fin troppo prolisso e sei rovinato per scelta tra groovy / grails e scala / lift! Questo è perfetto per i progetti personali poiché il punto è di solito quello di imparare e non necessariamente di raggiungere una scadenza.
Anch'io ero un referitore uber al lavoro. Ma visto che ho acquisito più esperienza, sono diventato più selettivo riguardo a cosa farò. Si scopre che quando esci da un'azienda non prendi il codice con te e di solito altri ingegneri possono distruggere il codice quasi più velocemente di quanto tu possa aggiustarlo.
La regola generale che seguo è questa: io refactoring fino a quando non è ottimizzato come può essere in quel momento e quindi non lo refactoring di nuovo a meno che le situazioni cambino, o più raramente se io avere una fonte d'ispirazione per un modo nuovo e migliore di fare le cose (ad esempio usando una nuova funzione linguistica).
Per esempio, una volta ho dovuto scrivere un nuovo modulo di codice per un'applicazione esistente. L'ho scritto in un certo modo, e il giorno successivo ho pensato più e immaginato di poterlo refactoring e renderlo più astratto dato che eravamo abbastanza certi che avrebbe dovuto essere esteso per altri usi. Così ho rifattorizzato il codice. Poi, ho deciso che era un po ' too generico e ho consolidato alcune classi e interfacce che sostanzialmente stavano facendo la stessa cosa, usando Generics (C #) per ottenere la stessa funzionalità. A questo punto probabilmente potrei ulteriormente refactoring per renderlo ancora migliore, ma è "abbastanza buono" - il codice è ben scritto, segue schemi di progettazione e concetti ingegneristici adeguati ed è estensibile. Lo rifatterei di nuovo solo se i requisiti mi obbligavano a rivalutare il codice o se esistesse una funzionalità linguistica che potrebbe rendere il codice più chiaro e / o più leggibile.
Leggi altre domande sui tag code-quality refactoring