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

Abbiamo introdotto un processo di revisione del codice all'interno della nostra organizzazione e sembra funzionare bene. Tuttavia, vorrei essere in grado di misurare l'efficacia del processo nel tempo, vale a dire che non stiamo trovando bug perché il codice è pulito o le persone non stanno semplicemente raccogliendo bug?

Al momento, non disponiamo di un efficace processo di test completamente automatizzato. Utilizziamo principalmente test manuali, quindi non possiamo fare affidamento sui difetti rilevati in questa fase per garantire che il processo di revisione del codice funzioni.

Qualcuno ha riscontrato questo problema prima o ha qualche idea su cosa funzioni bene nella misurazione delle revisioni del codice?

Esistono numerose metriche che possono essere raccolte dalle revisioni del codice, alcune anche estendendosi durante il ciclo di vita del progetto.

La prima metrica che consiglierei di raccogliere è l' efficacia della rimozione dei difetti (DRE) . Per ogni difetto, si identifica in quale fase è stato introdotto il difetto e in quale fase è stato rimosso. Le varie tecniche di rilevamento dei difetti che si utilizzano vengono tutte valutate simultaneamente, quindi si applica ugualmente a revisioni dei requisiti, revisioni del progetto, revisioni del codice, test unitari , e così via. Saresti particolarmente interessato al numero di difetti rilevati nella fase del codice, dal momento che probabilmente includerebbe i test unitari e le revisioni del codice. Se molti difetti dalla fase del codice stanno passando alla fase del test di integrazione o persino al campo, sai che le tue pratiche di post-codifica dovrebbero essere valutate.

Anche le varie metriche delle riunioni sarebbero rilevanti. Questi includono il tempo di preparazione, il tempo necessario per la riunione, le linee di lettura del codice, i difetti riscontrati nella revisione e così via. Alcune osservazioni possono essere fatte da questi dati. Ad esempio, se i revisori impiegano molto tempo a leggere il codice in preparazione per la revisione, ma riscontrano pochissimi problemi. Insieme ai dati DRE, puoi trarre la conclusione che se i difetti vengono testati nei test di integrazione o sul campo, il tuo team deve concentrarsi sulle loro tecniche di revisione per poter trovare problemi. Un'altra nota interessante sarebbero le righe di codice (o qualche altra misura delle dimensioni) lette in una riunione rispetto al tempo della riunione. La ricerca ha scoperto che la velocità di una tipica revisione del codice è di 150 righe di codice all'ora.

Con una qualsiasi di queste metriche, è quindi importante capire il loro impatto sul processo. L'analisi della causa principale, usando tecniche come why-because , i diagrammi Five Whys o Ishikawa possono essere utilizzate 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 su Crosstalk su Defect Potentials e DRE .

Sebbene in gran parte sia vero che la revisione del codice rileverebbe problemi che sono piuttosto latenti che il test può o meno rilevare. Tuttavia, secondo me potresti avere un codice veramente stabile (praticamente privo di bug) ma ancora scritto in modo tale da essere estremamente non leggibile o non del tutto 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 voler fare la revisione del codice? Il semplice motivo per cui è importante è che il codice dovrebbe essere migliorato per essere reso più leggibile, mantenibile ed evolvibile. Molte persone dovrebbero essere in grado di leggere un codice più pulito e dargli un senso. In tal 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 correlata alla quantità di rilavorazione - Il numero di volte in cui la rilavorazione viene applicata in uno stesso modulo / oggetto / oggetto di lavoro è una misura di quanto sia scadente quel codice in termini di manutenibilità. Quando viene applicata un'efficace revisione del codice, con quale frequenza possiamo ridurre la richiesta di rilavorazione sullo stesso modulo?

2. Metrica correlata alla quantità di modifica sostenuta da ogni richiesta di modifica. Ogni volta che si verifica una richiesta di modifica, un codice scarsamente considerato avrà sempre un numero maggiore di moduli interessati. Una misura indicherebbe probabilmente che dopo una revisione del codice - c'era una riduzione di tale diffusione del cambiamento per una richiesta di cambiamento simile in passato?

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

Non sto mettendo unità esatte di misure - probabilmente con questo approccio è possibile elaborare misure più accurate al riguardo. Ci può essere più formalismo di estensione negli approcci sopra su questo.

Fondamentalmente, il mio punto è che invece di esaminare il numero di bug identificato 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; pertanto, possiamo valutare tale efficacia se vediamo che richieste di modifica simili in futuro diventano più efficienti per rispondere.