Il ruolo di "refactoring" nelle buone pratiche di programmazione?

Prima di tutto, a seconda del sito di refactoring si possono distinguere diversi tipi di esso: refactoring del codice, refactoring del database (schema), refactoring dei test unitari, refactoring della GUI ecc.

Ci sono diverse situazioni in cui puoi incontrare il refactoring durante lo sviluppo del software:

1. Il refactoring è noto per essere un passaggio obbligatorio in alcune tecniche di sviluppo agili come sviluppo basato sui test . Si suppone che esegua un passo di refactoring dopo ogni fase di implementazione. In questo caso il refactoring prende di mira solo l'ultima implementazione e il suo obiettivo è quello di integrare il nuovo codice nel corpus del codice esistente nel modo più ottimale.

2. Il refactoring può essere fatto in modo che vengano rilevati alcuni problemi interni nel codice di lavoro: questo è chiamato " odore di codice ". Questa stima è in molti aspetti piuttosto soggettiva, nonostante il fatto che possa essere effettivamente basata su alcune metriche del codice (come il numero di linee di codice per metodo, complessità ciclomatica del codice ecc.). Qui l'obiettivo del refactoring è migliorare la qualità del codice modificandolo in modo che le metriche utilizzate per la stima della qualità ritornino al dominio previsto.

3. Spesso hai bisogno di rifattorizzare il codice per ottenere determinati principi di programmazione nel tuo codice, cerca Sviluppo del codice pulito per ulteriori informazioni su tali principi.

4. Potrebbe essere necessario eseguire il refactoring del codice e dello schema del database per prepararlo alle modifiche in arrivo, specialmente se non sono state prese in considerazione durante la fase di progettazione del progetto. Ad esempio, la normalizzazione dei dati e la denormalizzazione prendono spesso posto durante lo sviluppo di software basato sui dati per preparare il database per possibili estensioni.

Gli strumenti di refactoring disponibili sul mercato supportano fondamentalmente lo sviluppatore in due modi:

1. Durante la scrittura del codice, ottieni suggerimenti su come migliorarlo "al volo". Mentre molti errori possono essere rilevati direttamente dal tuo IDE, come Visual Studio o Eclipse (ad esempio codice morto, variabili dichiarate ma non utilizzate ecc.), Gli strumenti di refactoring come Resharper possono rivelare problemi che sono molto meno evidenti, come riscrivere il loop in query LINQ ecc.

2. Questi strumenti ti supportano anche con passaggi personalizzati di refactoring, come la rinomina globale dei tuoi identificatori, dividendo le dichiarazioni di classe in file separati con nome appropriato, estraendo interfacce e classi base dall'implementazione di classe ecc. Risparmiano molto lavoro qui, soprattutto se il tuo progetto ha una grande base di codice, ma prima devi sapere cosa vuoi veramente refactoring.

In realtà usare strumenti come ReSharper nello sviluppo di tutti i giorni è così utile che ti rende quasi dipendente da loro: accelera davvero il processo di scrittura del codice, specialmente se sai come usarli in modo appropriato!

Penso che il refactoring sia come lavarsi i denti. È un lavoro ingrato che non offre benefici immediati, ma dovrebbe essere fatto regolarmente e rapidamente prima che il dentista finisca per refactoring i vostri denti per voi.

Il refactoring ha benefici immediati. Quando si programma in modalità Red-Green-Refactor, quando si passa da rosso a verde, ci si trova in modalità "bozza": non ci si deve preoccupare necessariamente della duplicazione, non ci si deve preoccupare della denominazione, non ti preoccupare sulla qualità della tua soluzione. Questo stato produce rapidamente il valore dell'utente. Quando si passa alla transizione tra Verde e Refactored, si passa alla modalità "polacca": non ti preoccupare del dominio e degli utenti, ti preoccupi della qualità del codice. Questo è quando esprimi la tua abilità.

Entrambe le modalità offrono reali vantaggi immediati. (Se per nessun altro motivo, il controllo del codice non elaborato danneggerà la reputazione del proprio team.) Alternando esplicitamente le modalità, è possibile ottenere un "flusso" / produttività generale più elevato.

How does it takes place in the Software development process and how far it effects the system?

Il refactoring spietato è una pratica standard in tutti i team con cui lavoro. L'enfasi è su "spietato". Se il codice non "sente" correttamente, probabilmente non lo è. In genere questo è chiamato "odore del codice".

In generale, ci rifattiamo il prima possibile, di solito in un momento in cui tutti i test passano. Smettiamo di refactoring una volta che non riusciamo a pensare ad altro modo per semplificare il codice.

A volte ci rifattiamo su un particolare modello di progettazione, ad es. quando abbiamo identificato la necessità di una particolare interfaccia. A volte cambiamo l'implementazione per risolvere un problema di prestazioni. In questo senso ci sono casi in cui il refactoring influisce sul sistema. In generale, tuttavia, i nostri refactoring non modificano il comportamento del sistema.

Does Refactoring using these tools really speed up the process of development/maintenance?

L'opzione migliore sarebbe avere i dati per rispondere a questa domanda. Io non. Tuttavia, in base all'osservazione nella mia esperienza, il codice completamente refactored è molto più facile da utilizzare. È più facile da estendere. È più facile individuare la fonte di un bug. Rimuovendo i duplicati del codice non solo segui il principio DRY (Non ripeti te stesso) ma eviti anche di dover correggere lo stesso bug più di una volta.

L'uso degli strumenti è obbligatorio. Il refactoring manuale è possibile ma gli strumenti possono occuparsi della maggior parte dei casi e sono in grado di risparmiare tempo reale.

Sulla base delle mie osservazioni e della mia esperienza di lavoro con numerosi team e sistemi di refactoring supportati da strumenti, accelero sia lo sviluppo che la manutenzione del codice sorgente.