Metriche per misurare il refactoring di successo

Question

Esistono metriche oggettive per misurare il refactoring del codice?

Esecuzione findbugs, CRAP o checkstyle prima e dopo un refactoring può essere un modo utile per verificare se il codice è stato effettivamente migliorato anziché modificato?

Sto cercando le tendenze che possiamo acquisire per aiutarci a migliorare il processo di revisione del codice senza perdere tempo nel codice che viene modificato per semplice preferenza personale.

Answer 1

L'esecuzione di findbugs, CRAP o checkstyle prima e dopo un refactoring può essere un modo utile per verificare se il codice è stato effettivamente migliorato anziché modificato?

In realtà, come ho descritto nella questione "What is the fascination with code metrics?", il tendenza di metriche (findbugs, CRAP, a prescindere) è il vero valore aggiunto di metriche.
It (l'evoluzione delle metriche) si permette di priorità l'azione di fissaggio principale si ha realmente bisogno per rendere al codice (al contrario di cercare ciecamente al rispetto di ogni metrica là fuori)

Uno strumento come Sonar può, in questo ambito (monitoraggio delle metriche) può essere molto utile.

---

Sal aggiunge nei commenti:

Il vero problema è il controllo che codice cambiamenti aggiungono valore, piuttosto che solo l'aggiunta di cambiamento

Per questo, la copertura di test è molto importante, perché solo i test (unit test, ma anche i più grandi "test funzionali") daranno una risposta valida.
Tuttavia, il refactoring non dovrebbe essere fatto senza un obiettivo chiaro. Per farlo solo perché sarebbe "più elegante" o addirittura "più facile da mantenere" potrebbe non essere di per sé una buona ragione sufficiente per cambiare il codice.
Ci dovrebbero essere altre misure come alcuni bug che verranno corretti nel processo, o alcune nuove funzioni che saranno implementate molto più velocemente come risultato del codice "refactored".
In breve, il valore aggiunto di un refactoring non è misurato unicamente con le metriche, ma deve essere valutato anche rispetto agli obiettivi e/o alle pietre miliari.

Answer 2

Numero di Unittests fallite deve essere inferiore o uguale a zero :)

Answer 3

seconda dei tuoi obiettivi specifici, metriche come cyclomatic complexity in grado di fornire un indicatore per il successo. Alla fine ogni metrica può essere sovvertita, dal momento che non possono acquisire intelligenza e/o buon senso.

Un processo di revisione del codice sano potrebbe fare miracoli.

Answer 4

Dimensioni del codice. Tutto ciò che lo riduce senza rompere le funzionalità è un miglioramento nel mio libro (rimuovendo commenti e abbreviamento di identificatori non conterebbe, ovviamente)

Answer 5

Non importa quello che fai assicuratevi che questa metrica non sia usata per valutare le prestazioni del programmatore, decidendo promozione o qualcosa del genere.

Answer 6

Sarei rimasto lontano dalle metriche per misurare il successo del refactoring (a parte i fallimenti #unit test == 0). Invece, vorrei andare con recensioni di codice.

Non ci vuole molto lavoro per trovare obiettivi ovvi per il refactoring: "Non ho visto lo stesso identico codice prima?" Per il resto, dovresti creare alcune linee guida su cosa non fare e assicurarti che i tuoi sviluppatori ne siano a conoscenza. Quindi saranno in grado di trovare luoghi in cui l'altro sviluppatore non ha seguito gli standard.

Per i refactoring di livello superiore, gli sviluppatori e gli architetti più esperti dovranno esaminare il codice in base a dove vedono il codice base in movimento. Ad esempio, potrebbe essere perfettamente ragionevole che il codice abbia una struttura statica oggi; ma se sanno o sospettano che sarà richiesta una struttura più dinamica, potrebbero suggerire di usare un metodo di fabbrica invece di usare nuovo o di estrarre un'interfaccia da una classe perché sanno che ci sarà un'altra implementazione nella prossima versione.

Nessuna di queste cose trarrebbe vantaggio dalle metriche.

Answer 7

Ci sono due risultati desiderati dal refactoring. Vuoi team per mantenere un ritmo sostenibile e vuoi zero difetti nella produzione.

Il refactoring avviene sul codice e sul build test dell'unità durante il Test Driven Development (TDD). Il refactoring può essere piccolo e completato su un pezzo di codice necessario per completare una story card. Oppure, il refactoring può essere ampio e richiede una scheda tecnica per affrontare il debito tecnico. La story card può essere inserita nel backlog del prodotto e assegnata la priorità al business partner.

Inoltre, mentre si scrivono i test di unità mentre si esegue il TDD, si continuerà a rifasare il test man mano che il codice viene sviluppato.

Ricordare, in modo agile, le pratiche di gestione definite in SCRUM forniranno la collaborazione e assicureranno di comprendere le esigenze del business partner e il codice che si è sviluppato soddisfa le esigenze aziendali. Tuttavia, senza le corrette pratiche ingegneristiche (come definite da Extreme Programming) il tuo progetto andrà incontro a ritmi sostenibili. Molti progetti agili che non impiegavano pratiche ingegneristiche avevano bisogno di essere salvati. D'altra parte, un team che è stato disciplinato e ha impiegato sia la pratica agile di management che di ingegneria è stato in grado di sostenere la consegna a tempo indeterminato.

Quindi, se il tuo codice viene rilasciato con molti difetti o il tuo team perde velocità, il refactoring e altre pratiche ingegneristiche (TDD, paring, test automatizzati, design evolutivo semplice, ecc.) Non vengono impiegati correttamente.

Answer 8

Sì, diverse misure di qualità del codice possono dirti se un refactoring migliora la qualità del tuo codice.

• Duplicazione. In generale, meno duplicazioni sono migliori. Tuttavia, i cercatori di duplicazioni che ho usato a volte identificano blocchi duplicati che sono semplicemente strutturalmente simili ma che non hanno nulla a che fare l'uno con l'altro semanticamente e quindi non dovrebbero essere deduplicati. Siate pronti a sopprimere o ignorare quei falsi positivi.

• Copertura del codice. Questa è di gran lunga la mia metrica preferita in generale, ma è solo indirettamente correlata al refactoring. Puoi e dovresti aumentare la copertura scrivendo più test, ma non è un refactoring. Tuttavia, è necessario monitorare la copertura del codice durante il refactoring (come con qualsiasi altra modifica al codice) per assicurarsi che non scenda.Il refactoring può migliorare la copertura del codice rimuovendo le copie non testate del codice duplicato.

• Dimensioni metriche come righe di codice, totale e per classe, metodo, funzione, ecc. A Jeff Atwood post elenca un po 'di più. Se un refactoring riduce le linee di codice pur mantenendo la chiarezza, la qualità è aumentata. Classi, metodi, ecc. Insolitamente lunghi sono probabilmente dei buoni obiettivi per il refactoring. Siate pronti a usare il giudizio nel decidere quando una classe, un metodo, ecc. Ha davvero bisogno di essere più lungo del solito per svolgere il proprio lavoro.

• Metriche di complessità come complessità ciclomatica. Il refactoring dovrebbe cercare di ridurre la complessità e non aumentarla senza una ragione ben ponderata. Metodi/funzioni ad alta complessità sono buoni obiettivi di refactoring.

• di Robert C. Martin package-design metriche: astrattezza, instabilità e distanza dalla sequenza principale astrattezza-instabilità. Li ha descritti in his article on Stability in C++ Report e nel suo libro Agile Software Development, Principles, Patterns, and Practices. JDepend è uno strumento che li misura. Il refactoring che migliora il design della confezione dovrebbe ridurre D.

Ho utilizzato e continuo a utilizzare tutti questi strumenti per monitorare la qualità dei miei progetti software.

Answer 9

Vedo la domanda dal punto di vista olfattivo. Gli odori potrebbero essere trattati come indicatori di problemi di qualità e, quindi, il volume delle istanze di odore identificate potrebbe rivelare la qualità del codice del software.

Gli odori possono essere classificati in base alla loro granularità e al loro potenziale impatto. Ad esempio, potrebbero esserci odori di implementazione, odori di design e odori architettonici. È necessario identificare gli odori a tutti i livelli di granularità prima e dopo per mostrare il guadagno da un esercizio di refactoring. In effetti, il refactoring potrebbe essere guidato da odori identificati.

Esempi:

• Attuazione odori: metodo Lungo,, caso complesso condizionale mancante di default, complesso metodo, dichiarazione a lungo, e numeri magici.
• Odori di progettazione: Astrazione sfaccettata, astrazione mancante, incapsulamento insufficiente, incapsulamento non sfruttato, modularizzazione hub-like, modularizzazione ciclicamente dipendente, gerarchia estesa e gerarchia interrotta. Ulteriori informazioni sugli odori di progettazione sono disponibili in questo book.
• Odori di architettura: Livello mancante, Dipendenza ciclica nei pacchetti, Livello violato, Interfacce ambigue e Funzionalità parassita sparsa. Trova ulteriori informazioni sugli odori di architettura here.