Come determinare l'efficacia di un processo di revisione del codice?

Ci sono un certo numero di metriche che possono essere raccolte dalle revisioni del codice, alcune addirittura estese per tutto il ciclo di vita del progetto.

La prima metrica che consiglierei di raccogliere è l'efficacia della rimozione dei difetti (DRE) . Per ogni difetto, identifica in quale fase è stato introdotto il difetto e in quale fase è stato rimosso. Le varie tecniche di rilevamento dei difetti che utilizzi vengono valutate simultaneamente, quindi si applica allo stesso modo a recensioni dei requisiti, revisioni del progetto, revisioni del codice, test unitari , e così via. Sareste particolarmente interessati al numero di difetti rilevati nella fase di codice, poiché probabilmente comprenderebbero i vostri test unitari e le revisioni del codice. Se molti difetti della fase di codice passano alla fase di test di integrazione o addirittura al campo, sai che le pratiche di post-codifica dovrebbero essere valutate.

Anche le varie metriche delle riunioni sarebbero pertinenti. Questi includono il tempo di preparazione, l'ora in riunione, le righe di codice lette, i difetti rilevati nella revisione e così via. Alcune osservazioni possono essere fatte da questi dati. Ad esempio, se i revisori stanno spendendo molto tempo a leggere il codice in preparazione per la revisione, ma a trovare pochissimi problemi. In combinazione con i dati DRE, è possibile trarre la conclusione che se i difetti vengono verificati in test di integrazione o sul campo, allora il team deve concentrarsi sulle proprie tecniche di revisione per essere in grado di trovare problemi. Un'altra nota interessante sarebbero le righe di codice (o altre misure di misura) lette in una riunione rispetto al momento della riunione. La ricerca ha rilevato che la velocità di una revisione tipica del codice è di 150 righe di codice all'ora.

Con una di queste metriche, è quindi importante capire il loro impatto sul processo. Analisi delle cause principali, utilizzando tecniche come perché-perché , Five Whys , o I diagrammi di Ishikawa possono essere utilizzati per identificare i motivi per cui le revisioni del codice (o qualsiasi altra tecnica di miglioramento della qualità) sono (in) efficaci.

Potresti anche essere interessato a questo articolo sulle ispezioni da The Ganssle Group e un articolo di Capers Jones in Crosstalk su Defect Potentials e DRE .

Anche se in gran parte è vero che la revisione del codice potrebbe sollevare problemi che sono piuttosto latenti che il test può o non può cogliere. Tuttavia, a mio parere si può avere un codice veramente stabile (praticamente privo di bug), ma comunque scritto in modo tale che sia estremamente non leggibile o non abbastanza mantenibile. Quindi potrebbe essere che la revisione del codice NON trovi bug se non ci sono problemi reali nel codice.

Detto questo, vorrei davvero chiedere, perché si dovrebbe fare una revisione del codice? La semplice ragione per cui è importante è che il codice debba essere migliorato per essere reso più leggibile, manutenibile ed evolutivo. Molte persone dovrebbero essere in grado di leggere il codice più pulito e dare un senso a questo. In questo senso, l'obiettivo più semplice del processo di revisione del codice è produrre codice pulito. Quindi la misura dell'efficacia è quanto è più pulito il codice ora.

Come volevi avere un'efficacia misurabile - ecco cosa suggerirei:

1. Metrica relativa alla quantità di rilavorazione - Il numero di volte in cui la rilavorazione è applicata in uno stesso modulo / oggetto / oggetto di lavoro è una misura di come scarso quel codice è in termini di manutenibilità. Quando viene applicata un'efficace revisione del codice, con quale frequenza riusciamo a ridurre la richiesta di rielaborazione sullo stesso modulo?

2. Metrica relativa alla quantità di modifiche che ogni richiesta di modifica comporta. Ogni volta che si verifica una richiesta di modifica, un codice fattorizzato male avrà sempre un numero maggiore di moduli interessati. Una misura probabilmente indicherà che dopo una revisione del codice - è stata una riduzione di tale spread di cambiamento per una richiesta di modifica simile in passato?

3. Metrica relativa alla velocità media con cui è possibile rispondere a una richiesta di modifica. Quando il codice è più pulito, più veloce e meglio è rispondere alle modifiche richieste. Dopo che il codice è stato ripulito nel processo di revisione, il risultato è stato accelerato nel rispondere alla richiesta di dimensioni simili.

Non sto mettendo le unità di misura esatte - probabilmente si può creare una misura più accurata su questo approccio. Ci può essere più formalismo di estensione negli approcci sopra su questo.

Fondamentalmente, il mio punto è che invece di considerare il numero di bug identificati dal processo di revisione del codice; dovremmo misurare l'efficacia in termini di se la revisione del codice è stata in grado di portare il codice in uno stato più pulito, più snello e di facile manutenzione; quindi, possiamo valutare questa efficacia se vediamo che richieste di cambiamento simili in futuro diventano più efficienti per essere soddisfatte.