Convergent Contemporary Software Peer Review Practices

● Peter C. Rigby - Concordia University, Montreal, Canada● Christian Bird – Microsoft Research, Redmond, USAEuropean Software Engineering Conference

August 2013

Outline

2

● Motivazioni● Ipotesi● Metodologia● Background● Condivisione conoscenza● Minacce alla validità● Conclusioni

Motivazioni

3

Pratiche tradizionali di revisione: ● Rigidità● Inefficienza

Assenza di studi sistematici:● Progetti eterogenei● Principi generali● Condivisione della conoscenza

Ipotesi

4

Diversi progetti

+

simili pratiche di revisione

Metodi di revisione di successo

Ipotesi – domanda di ricerca

5

In cosa differiscono le revisioni paritarie in progetti diversi? Processo di revisione Durata e frequenza Dimensione artefatti Persone coinvolte Efficacia (problemi discussi) Conoscenza

Metodologia

6

Molteplici casi di studio Tradizionali, OSS, Ibridi

Chi ha creato la revisione Quali file Quante modifiche Commenti

Background – revisione paritaria

7

Planning Overview Preparation Meeting

Rework

Follow-up

Background – revisione paritaria

8

Open Source Sofftware (OSS): Patch → revisione → modifiche → commit Mailing list / bug tracking system

RTC style (Review-Then-Commit) Talvolta CTR (Commit-Then-Review)

Dati di confronto:

Background – revisione paritaria

9

Tool di supporto (CodeFlow): modifiche → notifiche email → commenti,

domande, risposte → sign off → version control system

Conoscenza, awareness

Nuovi dati Constant development VS sviluppo tradizionale

Background – revisione paritaria

10

Tool di supporto (Gerrit):

Background – revisione paritaria

11

Tool di supporto (CodeCollaborator):1) Caricamento artefatto

2) Assegnazione revisori

3) Discussione (asincrona, chat), fix dei problemi

4) Approvazione e commit● Ruoli● Business rules● Nuovi dati

Contemporary Peer Review

12

1) Un autore sottopone una modifica

2) Sviluppatori discutono e suggeriscono fix (re-submit)

3) Uno o più revisori approvano

4) Main version control repository

No:✗ Grandi Artefatti, incontri co-locati, ruoli

1. Il processo di revisione è leggero e flessibile

Risultati – sviluppo iterativo

13

Intervallo di revisione:● Lucent: 10 giorni ● AMD: 17,5 ore● MS: 14,7 - 19.8 ore● Google: 15,7 – 20,8 ore● OSS: < 1 giorno

Risultati – sviluppo iterativo

14

Numero di revisioni mensili:● AMD: 500● Bing: 2290● Office: 4348 (ciclico)● OSS = Chrome, SQL (stabile)

Contemporary Peer Review

15

● OSS: 11 – 32 linee● Android, AMD: 44 linee● Chrome: 78 linee, 5 file (≈ Bing, Office, SQL)● Lucent: 263 linee

2. Revisioni eseguite presto (prima del commit), velocemente, frequentemente

3. Modifiche di piccole dimensioni

Risultati – selezione revisori

16

● Sviluppatori → revisioni● Revisioni → sviluppatori● Dibattito (costi)● Tool: suggerimenti, notifiche

4. Due revisori trovano un numero ottimale di difetti

● 3 – 4 invitati

Risultati – discussione VS difetti

17

Ispezioni tradizionali Focus: trovare (e non risolvere) difetti Lucent: 3 difetti/revisione ( + 4 falsi positivi)

Revisioni asincrone Focus: discussione di difetti e soluzioni L'autore non è solo al momento del fix

5. La revisione si è evoluta da attività di ricerca dei difetti ad attività di problem solving di gruppo

Risultati – discussione VS difetti

18

Difetti registrati automaticamente Non esplicitamente “Are you sure you don't need to check against

NULL here?” è un difetto? Thread marcato come “risolto”

Misure alternative #re-submit ≤ #difetti ≤ #(argomenti dei) commenti

1 – 2 ≤ ? ≤ 2 – 3 3 - 4

Risultati – condivisione conoscenza

19

# file modificati # ∪file revisionati

Benefici Coinvolgimento Integrazione

+66% +44% +100% +122% +150%

“drive-by developers”

Minacce alla validità

20

Carenza di controllo Anomalie

Revisioni usate impropriamente Dati di sintesi (AMD, Lucent)

Conclusioni

21

1. Il processo di revisione è leggero e flessibile

2. Revisioni eseguite presto (prima del commit), velocemente, frequentemente

3. Modifiche di piccole dimensioni

4. Due revisori trovano un numero ottimale di difetti

5. La revisione si è evoluta da attività di ricerca dei difetti ad attività di problem solving di gruppo

Sviluppi futuri

22

Misure “leggere” Varietà e quantità di discussioni

È più importante discutere del sistema o trovare e riportare i difetti?

Misura di condivisione della conoscenza varietà