.NET - codice di refactoring

Refactoring o no, dovresti usare il controllo del codice sorgente. Salvi il tuo bacon se il team è uno sviluppatore o un migliaio.

Se si tenta di mantenere due rami di sviluppo simultanei della versione corrente e della versione refactored miticamente bella, non si otterrà mai il refactored del codebase nel modo desiderato. Ha molto più senso per il codice refactoring hai un motivo per toccarlo. Carve un po 'di tempo in più qua e là per questo. Quando qualcuno ti chiede di correggere un bug nel modulo A, devi rifattorizzare alcune cose. Qui e li. Poco per volta.

Prima di eseguire qualsiasi altro refactoring, inizierei con quello di base (che molti sembrano dimenticare)

Corregge la gestione delle eccezioni

Ho visto un sacco di applicazioni che "gestisce" le eccezioni. cioè provano l'eccezione, la registrano e poi la rilancia (e se si è fortunati senza fare throw ex; ). Un'eccezione viene davvero gestita quando il metodo può fornire il risultato promesso. Questi sono gli unici blocchi catch che dovrebbero essere lasciati.

Rimuovi tutti quei blocchi prova. In ASP.NET puoi prendere (e registrare l'eccezione + la richiesta) in global.asax.

Ottenere le eccezioni corrette è di vitale importanza quando si esegue il refactoring (in modo da sapere dove si rovina).

Convalida argomenti

Questo è un altro problema comune. Molti sviluppatori sembrano pensare di avere il pieno controllo della loro applicazione e di ciò che passano a ciascun metodo. Quindi non convalidano gli argomenti del metodo.

Sii gentile, lancia presto. In questo modo si ridurrà anche la necessità di registrazione di base, poiché l'errore verrà rilevato all'inizio dello stack di chiamate anziché in profondità.

Un vantaggio è che devi dedicare del tempo a capire i metodi per essere in grado di convalidare gli argomenti. Potresti anche voler documentarli con le tue scoperte fino alla prossima visita.

Continua su

Quando hai finito puoi continuare con il resto come rifattorizzare i metodi di grandi dimensioni ecc.

Il refactoring dovrebbe essere fatto sul tuo progetto live - come parte di un altro lavoro. Questo ha diversi vantaggi, soprattutto, in realtà viene fatto. Altrettanto importante, le tue modifiche sono fatte lentamente, in modo che quando ti perdi qualcosa, e lo spezzi (e lo farai), c'è una cosa che va bene e non funziona e non cento.

In una nota correlata, assegna il "costo" del refactoring in modo appropriato - se hai un modulo che è o poco usato, o brutto ma privo di problemi, fissarlo è meno importante di un modulo che viene usato molto o effettivamente impedendo un nuovo sviluppo. Quindi, quando stai correggendo il bug X, o aggiungendo la caratteristica Y, e devi lavorare attorno ai prblemi della classe z, z dovrebbe essere ripulito.

Penso che dovresti imparare il controllo del codice sorgente in modo che, se apporti una modifica che interrompa un altro componente, puoi facilmente tornare alla versione precedente.

Per quanto riguarda il modo in cui si esegue il refactoring, non esiste una metodologia migliore. È un processo che richiede tempo ma, se fatto bene, ne vale la pena. Nel libro Clean Code, sento che l'autore ha un ottimo approccio al refactoring. Suggerisce che ogni volta che è necessario apportare un cambiamento in un file, anche un refactoring e lasciare il file in una forma migliore di quella che hai trovato. Questo approccio ti consente di lavorare sul tuo compito, dal momento che hai familiarità con il codice, sarà più facile da refactoring.

Mi trovo in una situazione leggermente simile (il codice è probabilmente di qualità molto migliore, ma abbiamo appena abbandonato il supporto per .Net 1.0)

Quello che facciamo bene per noi è il refactoring mentre andiamo a spendere qualsiasi refactoring per il tempo libero. Quindi ... Dì, hai una funzione che mette il titolo sulla pagina o qualcosa del genere. Ora, il tuo capo ha bisogno che tu modifichi la funzione del titolo in modo che il nome del sito web sia incluso in esso, non solo nella pagina specifica. Quindi, vai a sistemarlo e scopri che ci sono 5 diverse funzioni Title che fanno cose simili. Dovresti refactoring quelli a 1 funzione in modo da non dover risolvere il problema in 5 posti. Potresti anche scoprire che potrebbe essere necessario creare una classe PageTitle o qualcosa di

Sono sicuro che alcune persone non saranno d'accordo con me, ma a volte, il codice di lavoro è abbastanza buono. Se hai un enorme metodo di 1000 linee che non hai dovuto cambiare in 5 anni e non causa grossi problemi di integrazione, perché cambiarlo? Molto probabilmente non verrà toccato per i prossimi 5 anni dopo averlo refactato. Hai davvero bisogno di avere priorità quando refactoring su un programma. Questo è l'ordine generale che seguo

1. Codice che sto modificando (di solito con scope per una o due classi)
2. Codice che non devo necessariamente modificare, ma che causa problemi di integrazione nel codice che devo scrivere.
3. Codice difficile da leggere
4. Codice non facile da leggere, ma mai interrotto.
5. (cioè, mai di solito) codice che potrebbe essere più pulito, ma altrimenti è decentemente leggibile e modificabile.

Esempio di vita reale di queste priorità. C'è un parser nel prodotto che sostengo che viene generato da un file di grammatica usando alcuni strumenti. È il codice più orribile che abbia mai visto, ma non è stato toccato in 5 anni o più. Non mi aspetto di doverlo toccare neanche perché non è mai stato rotto. (e abbiamo prove per essere sicuri di quello).

Tuttavia, abbiamo un punto dolente molto grande nella nostra conversione da .Net 1.0 a moderna. Un genio ha deciso di utilizzare IEnumerator anziché IEnumerable su tutto il codice base. Questo impedisce che i cicli foreach funzionino. Quasi ogni pezzo di codice che scrivo finisco per imbattersi nel bisogno di usare uno di questi IEnumerator. Invece di continuare a usare questo anti-pattern, lo aggiusto. Sempre. A volte, richiede la modifica di 50 o più righe di codice, ma è qualcosa che abbassa il debito tecnico dove è importante.

E lascerò un ultimo punto. UTILIZZARE IL CONTROLLO VERSIONE. Fidati di me! Se sei l'unico manutentore e il management non se ne preoccupa, quindi usa git o mercurial. Non hai nemmeno bisogno di un repository centrale per questi e ottieni comunque la maggior parte dei benefici. Il controllo della versione ha un valore inestimabile quando decidi di intraprendere un'attività di refactoring e scoprire che rompe in modo significativo le cose. Con il controllo della versione, si ripristina l'ultimo commit. Senza, incrocia le dita hai fatto una copia della directory di recente.

In realtà sei sulla giusta strada menzionando la mancanza di controllo del codice sorgente nella tua azienda / azienda di sviluppo. Questo è un must per avere per lo sviluppo di applicazioni SOLID e il corretto lavoro di manutenzione del progetto.

Come sapresti quale insieme di modifiche frena la logica legacy? e come faresti a tornare allo stato precedente senza utilizzare strumenti di controllo della versione come Git, TFS, SVN, ecc? ...

Anche meglio NON mantenere due basi di codice diverse per un progetto. È un errore incline e il dolore nella fusione del codice, specialmente un dolore più grande nello sviluppo di un team.

Per ri-factoring: installa uno strumento per il refactoring del codice (come, JustCode, Re-sharper, ecc.). Ci sono alcuni componenti aggiuntivi gratuiti che puoi ottenere dai pacchetti NuGet. Ti farà risparmiare un sacco di volte e ti fornirà suggerimenti per prendersi cura dei blocchi di codice odoranti .