Differenza tra Refactoring del codice e Revisione del codice

Differenza tra Refactoring del codice e Revisione del codice

Refactoring del codice e Revisione del codice

Il refactoring del codice, o in inglese Code Refactoring, è un’attività di manutenzione in cui il codice sorgente viene ristrutturato per migliorarne la qualità mentre viene preservato il comportamento esterno del sistema. D’altra parte, invece, il termine revisione del codice, o in inglese Code Review, si riferisce ad una serie di attività, dalla semplice lettura di un po’ di codice sulla spalla del collega di squadra a una riunione di 20 persone in cui si analizza il codice riga per riga.

Il processo di refactoring viene spesso definito processo di ricostruzione del codice sorgente per ridurre al minimo l’errore o il difetto, sia come atto di correzione che di prevenzione. Ad esempio, i cloni di codice e altre ridondanze in un codice sono considerati una minaccia per lo sviluppo futuro del software. Questi errori nel codice sorgente sono noti come “bad smells” nel codice. Un altro vantaggio del refactoring oltre a migliorare la qualità del codice è quello di migliorare la struttura del software in modo che diventi più facile da capire.

Differenza tra Refactoring del codice e Revisione del codice

I vantaggi del refactoring del software sono pochi e sono i seguenti:

  • Per rimuovere il codice duplicato e altri cattivi odori.
  • Per migliorare la qualità di progettazione del software.
  • Per aumentare la comprensibilità del codice.
  • Ridurre i tempi di evoluzione del progetto, in particolare nelle attività di gestione del codice sorgente.

I partecipanti a una revisione del codice sono l’autore, che scrive il codice e lo invia per la revisione, e il revisore, che legge il codice e decide quando è pronto per essere unito alla base di codice del team. Una recensione può avere più revisori.
Prima che inizi la revisione del codice, l’autore deve creare un elenco modifiche. Questa è una serie di modifiche al codice sorgente che l’autore desidera unire alla base di codice del team.

Una recensione inizia quando l’autore invia la lista delle modifiche al revisore. Le revisioni del codice avvengono in round. Ogni round è un round-trip completo tra l’autore e il revisore: l’autore invia le modifiche e il revisore risponde con feedback scritto su tali modifiche. Ogni revisione del codice ha uno o più round. La revisione termina quando il revisore approva le modifiche.
È facile per un autore interpretare le critiche al proprio codice come un’implicazione di essere un programmatore incompetente. Le revisioni del codice sono un’opportunità per condividere conoscenze e prendere decisioni ingegneristiche informate. Ma ciò non può accadere se l’autore percepisce la discussione come un attacco personale.
Alcuni scenari di refactoring sono stati trovati per migliorare alcuni aspetti qualitativi del software e indebolirne altri. Questi risultati portano alla conclusione che il refactoring non migliora sempre tutti gli aspetti della qualità del software.
Gli sviluppatori hanno affermato che il refactoring è “trasformazione del codice che migliora alcuni aspetti del comportamento del programma come leggibilità, manutenibilità o prestazioni”.

Il refactoring richiede una valutazione multidimensionale. Pertanto, riteniamo che sia errato limitare lo studio dell’impatto di un determinato scenario di refactoring sulla qualità a un determinato attributo di qualità, ottenere alcuni risultati negativi e dichiarare una conclusione generale che lo scenario di refactoring considerato provoca un indebolimento della qualità del software.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *