Qualcun altro ha un problema di refactoring? [chiuso]

Sembra che dopo aver scritto una quantità significativa di codice ottengo questa sensazione ansiosa di non averlo fatto nel migliore dei modi, e finisco per effettuare continuamente il refactoring e passare troppo tempo nel progetto, o non ottenere mai a volte. Questo succede mai a qualcun altro, e come lo affronti?

Mi piacciono questi momenti in cui accadono a me.

Il motivo: se non guardassi indietro al mio lavoro e pensassi che ci fosse qualcosa che avrei potuto fare meglio di quanto non avrei avanzato come sviluppatore. Pertanto, quando si verificano questi momenti di illuminazione, abbracciali e prendi nota di ciò che hai imparato. Considera il tuo calendario per il progetto corrente e, se possibile, rifatti il ​​codice, se non è possibile, prendi la lezione e usala nelle future implementazioni per i progetti.

Ad ogni modo, imparare dai propri errori è un'ottima cosa!

Ecco alcune regole per limitare questa attività e renderla più produttiva:

• impostare il tempo, ad es. impostare il timer su 25 minuti
• fallo solo quando hai una copertura decente del test.
• cerca di rendere il refactoring utile allo sviluppo delle prossime funzionalità

Sembra che tu possa sempre refactoring, vero? Cerco di limitare il refactoring solo quando provo a risolvere altri problemi. Ad esempio, refactoring quando si riscontra un problema di prestazioni e refactoring con aiuto per risolverlo - refactor quando è necessario aggiungere nuove funzionalità e refactoring ti aiuterà a risolverlo

Ad essere sincero, mi preoccuperei di più se stavi tirando fuori enormi risme di codice e pensando che sia tutto perfetto e non abbia bisogno di alcun refactoring ...

Quando ero più giovane e inesperto, ero molto arrogante riguardo alla mia capacità di programmazione e tendevo sempre a immaginare che fosse possibile progettare e pianificare davvero bene - e che una volta arrivato alla fase di implementazione, lo sbattevo fuori ed è ' Sarà tutto perfetto.

La realtà è quasi l'opposto. Alcuni sostengono addirittura che non appena inizi a scrivere codice, dovresti essere in modalità Manutenzione. L'idea qui è che la fase di "Implementazione" dell'SDLC non esiste davvero come tale, perché non dovresti mai mettere da parte la correzione dei bug o il refactoring e fingere che il codice che stai producendo sia "fresco" e perfetto.

Detto questo, suppongo che È possibile ottenere troppo ossessivo sulla refactoring. Non l'ho ancora visto. E più esperienza ho, più penso che sarebbe una buona cosa se più team di software si rifiutassero palesemente di lavorare a scadenze strette e dovessero indebitarsi a livello tecnico. Dopotutto, questa è la ragione più comune per cui il refactoring viene messo da parte nel mondo reale.

Suggerirei di non dipendere esclusivamente dalla sensazione o dall'odore del codice.

Enumera chiaramente cosa non va nel codice e quali sono le soluzioni. Seriamente, scrivilo, perché vorrai rivedere quanto sia stato efficace il tuo refactor contro questo.

Individua i modi per suddividere il refattore in blocchi realizzabili e assegnali le priorità. Avere la disciplina di concentrarsi solo sulla portata di ogni blocco, evitando tangenti che possono minare il tuo compito.

Inoltre, identificare quali unit test è possibile scrivere rispetto al codice esistente prima di procedere. Se ci sono già numerosi test, questa è un'ottima cosa. La mancanza di test unitari rappresenta una grande opportunità per realizzarne alcuni.

Non c'è dubbio che cado in questa trappola, ma alcuni refactoring sono importanti per il futuro supporto / debugging.

Quando si scrive un pezzo di codice importante, diventa molto facile tenere traccia delle righe di codice nel metodo attualmente in fase di scrittura. Quando ho completato un grosso pezzo di codice, inserisco un commento : commento di revisione del codice . Quindi qualche giorno dopo farò la revisione del codice e il refactor di conseguenza. Se ho problemi a leggerlo qualche giorno dopo, cosa succederà tra qualche mese o addirittura anni.

Cado in questa trappola quando imparo per la prima volta una lingua o una tecnologia. Ad esempio, quando impari java per la prima volta, immagina di scrivere un'app Web con un servlet, pensando che sia la strada giusta. Quindi ti rendi conto che c'è jsp e pensi che sia più recente che probabilmente sia giusto. Quindi, una volta a metà strada, trovi Struts e forse alcune cose EJB, dopo di che trovi la primavera (basata su xml) dopo di che trovi le fantastiche annotazioni @MVC, dopo di che trovi tutto troppo verboso e sei viziato per scelta tra groovy / grails e scala / lift! Questo va perfettamente bene per i progetti personali poiché il punto è di solito imparare e non necessariamente rispettare una scadenza.

Al lavoro ero anche un grande refattore. Ma man mano che ho acquisito più esperienza, sono diventato più selettivo su ciò che rifletterò. Si scopre che quando lasci un'azienda non porti il ​​codice con te, e di solito altri ingegneri possono distruggere il codice quasi più velocemente di quanto tu possa risolvere.

La regola empirica che seguo è questa: faccio il refactoring fino a quando non è ottimizzato come può essere in quel momento e quindi non lo refacturing nuovamente a meno che le situazioni non cambino, o più raramente se ho l'ispirazione su un modo nuovo e migliore per fare le cose (ad esempio usando una nuova funzione linguistica).

Ad 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 dopo ho pensato più a fondo e ho pensato di poterlo riformattare e renderlo più astratto dato che eravamo abbastanza certi che avrebbe dovuto essere esteso lungo la strada per altri usi. Quindi ho riformulato il codice. Quindi, ho deciso che era un po ' troppo 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 avrei potutoulteriore refactoring per renderlo ancora migliore, ma è "abbastanza buono" - il codice è ben scritto, segue schemi di progettazione e concetti ingegneristici adeguati ed è estensibile. Riformulerei di nuovo solo se i requisiti mi costringessero a rivalutare il codice o se ci fosse una funzionalità linguistica che potesse rendere il codice più chiaro e / o più leggibile.