Convergent Contemporary Software Peer Review Practices
Report
Ciro SantoroFollow
Dec. 15, 2013•0 likes•421 views
Convergent Contemporary Software Peer Review Practices
Dec. 15, 2013•0 likes•421 views
Download to read offline
Report
Technology
Presentazione di un articolo scientifico tenuta durante il corso di 'Sistemi per la Collaborazione in Rete'. L'articolo esaminato riguarda le moderne pratiche di revisione paritaria del software utilizzate in ambito aziendale e nelle comunità Open Source. Gli autori dell'articolo sono riportati nella prima slide.
Ciro SantoroFollow
Recommended
2015 figelj presentazioneMatteo Figelj
Assemblea dei Soci 2016 - Presentazione attivitàAlumni Mathematica
(Open) data hackingPierpaolo Basile
Diachronic AnalysisPierpaolo Basile
Diachronic Analysis of the Italian Language exploiting Google NgramPierpaolo Basile
Continuous Integration/Deployment with Docker and JenkinsFrancesco Bruni
More Related Content
Similar to Convergent Contemporary Software Peer Review Practices
Open BqrDavide Taibi
Una fugace occhiata al Test Driven Development (2006)Roberto Bettazzoni
Software Testing e TDDDomenico Briganti
Introduzione alle metodologie e pratiche Agili ... ma l'agile c'entra qualcos...Roberto Bettazzoni
Detailed Model Capturefcospito
Detailed Model Capturefcospito
Convergent Contemporary Software Peer Review Practices
- 1. Convergent Contemporary Software Peer Review Practices Peter C. Rigby - Concordia University, Montreal, Canada ● Christian Bird – Microsoft Research, Redmond, USA ● European Software Engineering Conference August 2013
- 2. Outline Motivazioni ● Ipotesi ● Metodologia ● Background ● Condivisione conoscenza ● Minacce alla validità ● Conclusioni ● 2
- 3. Motivazioni Pratiche tradizionali di revisione: ● Rigidità ● Inefficienza Assenza di studi sistematici: ● Progetti eterogenei ● Principi generali ● Condivisione della conoscenza 3
- 4. Ipotesi Diversi progetti + simili pratiche di revisione Metodi di revisione di successo 4
- 5. Ipotesi – domanda di ricerca In cosa differiscono le revisioni paritarie in progetti diversi? Processo di revisione Durata e frequenza Dimensione artefatti Persone coinvolte Efficacia (problemi discussi) Conoscenza 5
- 6. Metodologia Molteplici casi di studio Tradizionali, OSS, Ibridi Chi ha creato la revisione Quali file Quante modifiche Commenti 6
- 7. Background – revisione paritaria Planning Overview Preparation Meeting Rework Follow-up 7
- 8. Background – revisione paritaria Open Patch → revisione → modifiche → commit Mailing list / bug tracking system RTC Source Sofftware (OSS): style (Review-Then-Commit) Talvolta CTR (Commit-Then-Review) Dati di confronto: 8
- 9. Background – revisione paritaria Tool di supporto (CodeFlow): modifiche → notifiche email → commenti, domande, risposte → sign off → version control system Conoscenza, awareness Nuovi dati Constant development VS sviluppo tradizionale 9
- 10. Background – revisione paritaria Tool di supporto (Gerrit): 10
- 11. Background – revisione paritaria 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 ● 11
- 12. Contemporary Peer Review 1. Il processo di revisione è leggero e flessibile 1) Un autore sottopone una modifica 2) Sviluppatori discutono e suggeriscono fix (resubmit) 3) Uno o più revisori approvano 4) Main version control repository No: ✗ Grandi Artefatti, incontri co-locati, ruoli 12
- 13. Risultati – sviluppo iterativo 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 ● 13
- 14. Risultati – sviluppo iterativo Numero di revisioni mensili: ● AMD: 500 ● Bing: 2290 ● Office: 4348 (ciclico) ● OSS = Chrome, SQL (stabile) 14
- 15. Contemporary Peer Review 2. Revisioni eseguite presto (prima del commit), velocemente, frequentemente 3. Modifiche di piccole dimensioni OSS: 11 – 32 linee ● Android, AMD: 44 linee ● Chrome: 78 linee, 5 file (≈ Bing, Office, SQL) ● Lucent: 263 linee ● 15
- 16. Risultati – selezione revisori Sviluppatori → revisioni ● Revisioni → sviluppatori ● Dibattito (costi) ● Tool: suggerimenti, notifiche ● 4. Due revisori trovano un numero ottimale di difetti ● 3 – 4 invitati 16
- 17. Risultati – discussione VS difetti Ispezioni Focus: trovare (e non risolvere) difetti Lucent: 3 difetti/revisione ( + 4 falsi positivi) Revisioni tradizionali 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 17
- 18. Risultati – discussione VS difetti 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 18
- 19. Risultati – condivisione conoscenza # file modificati ∪ # file revisionati Benefici Coinvolgimento Integrazione “drive-by developers” +66% +44% +100% +122% +150% 19
- 20. Minacce alla validità Carenza di controllo Anomalie Revisioni usate impropriamente Dati di sintesi (AMD, Lucent) 20
- 21. Conclusioni 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 21
- 22. Sviluppi futuri Misure “leggere” Varietà e quantità di discussioni È più importante discutere del sistema o trovare e riportare i difetti? Misura di condivisione della conoscenza varietà 22
Editor's Notes
- Lo studio che vi presento riguarda le pratiche convergenti della moderna revisione del software. È stato svolto da Peter Rigby, ricercatore (Assistant Professor) in Ingegneria del Software presso la Concordia University (Montreal, Canada) e da Christian Bird, ricercatore Microsoft che si occupa di Ingegneria del Software presso l'Empirical Software Engineering Group (ESE), laureatosi alla Brigham Young University (Utah), Ph. D. (dottorato di ricerca) in California. È stato presentato nell'agosto 2013 alla conferenza europea sull'ingegneria del Software a San Pietroburgo (Russia).
- Vedremo le motivazioni che hanno portato gli studiosi a formulare la loro ipotesi, la metodologia che hanno adottato. Segue una carrellata dei progetti software analizzati ed i risultati emersi da tale analisi.
- Innanzitutto precisiamo che per ispezione si intende la revisione formale da parte di colleghi di pari livello di un prodotto del ciclo di vita del software con lo scopo di trovarne i difetti. La prima formalizzazione è dovuta a Fagan che le ha impiegate all'interno di IBM. Le tradizionali pratiche di revisione del software (best practice da 35 anni), nonostante siano efficaci nell'identificare i difetti, presentano dei problemi quali la rigidità dei metodi ed i costi elevati che ne limitano l'adozione, in quanto inefficienti. Le moderne aziende eseguono comunque la revisione paritaria, tramite pratiche moderne che fino ad ora non sono state studiate.
- Si ipotizza che se i processi di revisione paritaria dovessero mostrare caratteristiche simili in diversi progetti software, allora tali caratteristiche possono rappresentare dei metodi generali di revisione da prescrivere in altri progetti. Gli autori ipotizzano che l'attuale revisione paritaria si sia evoluta partendo da quella tradizionale delle ispezioni formali
- Ci si chiede, dunque, in che modo i parametri della revisione paritaria differiscono tra progetti diversi. Questa domanda viene resa operativa per ognuno dei parametri: 1. di quale processo di revisione fa uso il progetto? (Fagan, CTR) 2. quanto tempo durano le revisioni e quanto spesso vengono eseguite? 3. qual è la dimensione del manufatto in esame? 4. quante persone sono coinvolte? 5. quanto è efficace la revisione in termini di problemi disussi? 6. la revisione consente la diffusione di conoscenze riguardo il sistema in tutto il team di sviluppo? Tranne che per l'ultimo punto, questi parametri sono stati studiati in molti esperimenti nel corso degli anni. Il contributo di questo lavoro consiste nel confrontare un insieme diversificato di progetti rispetto a questi parametri.
- Viene usata la metodologia dei casi di studio multipli. I risultati sono trasferibili tramite generalizzazioni analitiche: i ricercatori sviluppano una teoria o un framework relativamente al fenomeno studiato. Viene usato un campionamento teorico per selezionare una serie diversificata di casi, per poi confrontare i risultati sviluppando un framework che descrive le pratiche convergenti e divergenti nella revisione moderna. Il lavoro è iniziato collezionando i dati relativamente ai progetti da studiare, facendo riferimento anche a lavori precedenti. Bisogna stabilire in cosa consiste una revisione per ogni progetto.
- L'ispezione tradizionale è quella più formale. Viene eseguita quando un artefatto soddisfa criteri predefiniti (es. un certo requisito è stato implementato). Definite da Fagan, prevedono le fasi di: 1. pianificazione (planning) – il capo progetto sceglie gli sviluppatori e li incarica dell'ispezione, definizione partecipanti, materiali, luoghi d'incontro 2. panoramica: assegnazione ruoli 3. preparazione – gli ispettori leggono il prodotto e annotano i difetti riscontrati 4. Meeting – ispettori e autore si riuniscono alla presenza di un moderatore 5. rielaborazione (rework) – l'autore modifica il prodotto in base ai difetti trovati (iterazione) 6. follow-up – compilazione documenti evidenziando parti nuove o modificate. Il moderatore verifica che i difetti trovati siano effettivamente risolti. I dati raccolti in esperimenti di ispezione presso Lucent vengono utilizzati per confrontare l'ispezione tradizionale con quella moderna. Questo studio è stato eseguito in un ambiente industriale semi-controllato da Porter, che mirava a determinare l'impatto di alcuni elementi del processo di revisione sulla loro efficacia (dimensione team, numero di sessioni). Il progetto studiato riguarda lo sviluppo di un compilatore (55K nuove linee di codice C++, 6 sviluppatori). la raccolta dei dati è durata 18 mesi, durante i quali furono eseguite 88 ispezioni (4,8 al mese).
- La revisione paritaria è uno strumento importante per garantire la qualità del codice soprattutto nella comunità Open Source, composte da sviluppatori che raramente si incontrano di persona. Mentre nelle aziende software le revisioni vengono assegnate a specifici individui, nell'OSS le modifiche vengono trasmesse a centinaia di potenziali stakeholder. Questo approccio funziona, nonostante le preoccupazioni che le revisioni possano essere ignorate, o che le discussioni possano bloccarsi a causa dei troppi partecipanti coinvolti. I progetti esaminati usano sistemi di tracciamento dei bug, ma gran parte delle revisioni sono condotte tramite mail. Generalmente una revisione: 1 inizia quando uno sviluppatore invia un contributo (patch) 2 una o più persone la revisionano 3 viene modificata fino al raggiungimento degli standard della comunità 4 commit alla code base Molti contributi vengono ignorati. Principalmente RTC, CTR per sviluppatori di fiducia. I dati ricavati da un precedente studio di Rigby sono usati come confronto, e riguardano dei progetti OSS di successo e maturi che differiscono per governance (fondazione/ dittatore), tipo di revisione (RTC o CTR) dimensione, :Apache Server http, progetto di medie dimensioni, oggetto di molti studi, fondazione; Subversion (SVN), sistema di controllo delle versioni, progettato per rimpiazzare CVS, simile ad Apache, fondazione FreeBSD è sia un kernel basato su UNIX sia una distribuzione Unix, simile ai precedenti ma più grande, fondazione Kernel Linux: basato su UNIX, dittatore, solo RTC KDE: ambiente desktop (ecosistema di progetti), come GNOME
- Evoluzione del processo di revisione: da mailing list a strumenti centralizzati. Uno sviluppatore che ha completato una modifica crea una revisione indicando quali file includere, descrivendo i cambiamenti e specificando chi dovrebbe essere coinvolto. Questi revisori ricevono delle notifiche e possono annotare commenti e domande. L'autore può rispondere e presentare nuove modifiche. Quando un recensore si ritiene soddisfatto, può disconnettersi dalla revisione. Le politiche possono variare tra i team: chi/quanti devono disconnettersi. Vengono presentati i nuovi dati di tre progetti MS che usano CodeFlow (strumento collaborativo di revisione del codice usato da 28.000 sviluppatori). I progetti si differenziano per dominio e metodologia di sviluppo: Bing – motore di ricerca, in continuo sviluppo Office – processo di sviluppo più tradizionale: pianificazione, implementazione, consegna SQL Server – database e business intelligence, ciclo di sviluppo simile a Office
- Quando il progetto Android fu rilasciato come Open Source, gli ingegneri Google che ci lavoravano vollero continuare ad usare lo strumento di revisione usato internamente a Google (Mondrian). Gerrit è una implementazione OSS per git delle pratiche di revisione usate da Google. Esso agisce come una barriera tra il repository privato dello sviluppatore ed il repository centralizzato condiviso. Quando uno sviluppatore sottomette delle modifiche, i revisori possono commentarle tramite l'interfaccia web di Gerrit. Sono riportati nuovi dati riguardo due progetti OS guidati da Google: Android – sistema operativo per dispositivi mobili Chrominum OS (Chrome) – sistema operativo che ruota intorno al browser Chromium ed esegue solo web app
- Si fa riferimento a una relazione dei praticanti in merito all'adozione di CodeCollaborator per la revisione paritaria presso AMD (Advanced Micro Devices). Questo strumento permette di specificare regole aziendali, discussioni asincrone o tramite chat. Presso AMD la qualità del software è migliorata integrando una revisione paritaria leggera nel processo di sviluppo. L'idea è che l'integrazione della revisione con il processo di sviluppo possa aiutarlo senza ostacolarlo, usando il tempo in modo efficiente (senza meeting schedulati). Fasi di revisione: 1. l'autore carica il software da revisionare tramite interfaccia web 2. egli sceglie revisori ed osservatori (assegna ruoli) 3. discussione 4. approvazione e archiviazione dell'attività
- Confrontando i precedenti processi di revisione, emerge il fatto che la moderna revisione tra pari è un processo leggero che viene eseguito prima di aggiungere il codice ad un repository dal quale dipendano diversi sviluppatori (es. master branch). La revisione si adatta la team di sviluppo, senza inficiarne le attività prioritarie. Tipicamente è tenuta in modo asincrono e le attività sono tracciate automaticamente. Netto contrasto con le ispezioni tradizionali (manufatti completi di grandi dimensioni vengono revisionati in incontri co-locati, con obiettivi e ruoli ben definiti).
- Il concetto di sviluppo iterativo può essere ritrovato in molti progetti software di successo. Generazioni successive di sviluppatori hanno lavorato in intervalli sempre più corti (es continuous builds, release early, release often); la revisione tra pari non fa eccezione. Inizialmente il tempo che intercorreva dall'inizio della revisione al termine della discussione (Intervallo di revisione) era dell'ordine di settimane. Nel 1998 Porter riportava per Lucent una mediana di 10 giorni. Progetti OSS: da poche ore ad un giorno. AMD, Microsoft ed i progetti Google esemplificano la pratica convergente delle revisioni che avvengono velocemente. Per rappresentare i dati gli autori hanno scelto i beanplot, che mostrano la distribuzione di densità di molteplici campioni lungo l'asse y (invece che lungo l'asse x) per facilitare il confronto visuale. La linea orizzontale è la mediana. I beanplot sono migliori per un ampio intervallo di dati non normali dato che mostrano l'intera distribuzione verticalmente e consentono di evidenziare picchi e avvallamenti. Nella figura sono riportati il tempo di risposta sulla sinistra e l'intervallo totale sulla destra. L'intervallo di revisione mostra una certa consistenza fra tutti i progetti. Si nota che per tutti i progetti la maggior parte delle revisioni sono ritirate in poche ore, quindi i revisori controllano ed eseguono regolarmente le revisioni.
- Un altro dato che emerge è che le revisioni sono eseguite frequentemente. Per AMD il numero di revisioni mensili aumenta dal momento dell'intruduzione di CodeCollaborator fino ad arrivare a 500 revisioni mensili. I tre progetti MS mostrano andamenti diversi: SQL, con una mediana di 3739 revisioni/mese è abbastanza consistente di mese in mese. Invece Bing (2290) ha mostrato un aumento costante nel tempo dall'adozione iniziale di CodeFlow. Office ha la mediana più alta e segue un tipico ciclo di rilascio con un decollo iniziale delle revisioni ed una caduta vicino al rilascio. La frequenza di revisione è molto alta rispetto le ispezioni tradizionali (Lucent: 88 ispezioni in 18 mesi, 5 al mese) ma tende a variare in base allo stadio, allo stile di sviluppo e alla dimensione del progetto (divergenza). Distinguiamo progetti: - di adozione: Bing, AMD – il numero di revisioni è in aumento - ciclici: Office, Android – mostrano forma conica con fluttuazioni graduali - stabili: Chrome, SQL – mostrano un numero di revisioni stabile, come OSS
- Non è possibile ottenere un breve intervallo di revisione senza modificare altri aspetti dello sviluppo. Creando modifiche di piccole dimensioni, gli sviluppatori possono lavorare in intervalli più brevi. Nei progetti OSS studiati da Rigby il numero di linee di codice modificate presenta una mediana che va da 11 a 32, seguite dagli altri progetti che presentano tutti una mediana inferiore rispetto a quella di Lucent.
- Tradizionalmente, gli sviluppatori vengono assegnati alla revisione di un artefatto. Nei progetti OSS gli sviluppatori selezionano le modifiche che sono interessati a revisionare (le revisioni non vengono assegnate). Gli autori si chiedono quale sia il numero ottimale di revisori, questione che ha generato alcune polemiche: le revisioni sono costose, poiché richiedono la lettura, comprensione e critica di un artefatto. Qualunque riduzione del numero di revisori che non porti a una riduzione del numero di difetti trovati porta ad un risparmio. In base a molteplici studi, il consenso sembra essere che due ispettori trovano un numero ottimale di difetti. Strumenti come CodeCollaborator o Gerrit possono suggerire potenziali revisori in base a chi ha lavorato sul file nel recente passato. Gli sviluppatori possono abbonarsi a delle notifiche quando la revisione riguarda una certa parte del sistema. La pratica comune sembra essere quella di invitare 3-4 revisori per poi lasciare che la revisione faccia il suo corso, il che potrebbe portare all'inclusione di partecipanti addizionali.
- I rigidi vincoli temporali dei meeting di revisione sincroni forzavano le ispezioni tradizionali ad essere concentrate esclusivamente nella ricerca di difetti: la discussione di altri argomenti, come le soluzioni ai difetti, erano proibite. Erano previsti ruoli espliciti per assicurare che i difetti venissero registrati senza distrarre gli sviluppatori dal loro compito. Il progetto Lucent presenta una mediana di 3 difetti reali trovati per ogni revisione, + altri 4 falsi positivi. In contrasto, le revisioni asincrone hanno vincoli temporali meno rigidi che consentono una discussione dettagliata del software. Ad esempio nei progetti OSS la scoperta di difetti non è il punto centrale: si discutono invece i potenziali difetti e le soluzioni. Grazie a queste discussioni di gruppo l'autore non è più isolato dagli altri suoi pari quando deve sistemare i difetti trovati.
- Dallo studio delle aziende software si trova una convergenza con l'OSS: i difetti non sono registrati esplicitamente. CodeCollaborator (AMD) ha un campo per registrare il numero di difetti usati, ma non viene usato. CodeFlow (MS) non fornisce un modo per registrare il numero di difetti. I revisori commentano lo stile, l'aderenza alle convenzioni, la documentazione, i difetti e possono fare domande, nell'aiutare l'autore a rendere il codice accettabile. Non è chiaro quale di questi elementi costituiscano dei difetti e quali no (esempio). L'oggetto più vicino a un difetto è un thread di discussione che è stato marcato come risolto (avvertenza: domande, discussione ma no modifiche codice). Dato che il numero di difetti non viene registrato, gli autori propongono delle misure alternative: - Il numero di commenti fatti durante una revisione è un limite superiore del numero di difetti (assunzione: un commento per ogni difetto) - una stima migliore è il numero di argomenti trattati nei commenti: l'assunzione è che ogni argomento contiene un singolo difetto. - un limite inferiore è il numero di ri-sottomissioni di un artefatto: per i difetti non banali un artefatto può essere sottomesso per molteplici revisioni; comunque una revisione coprirà tutti i difetti sistemati durante la sessione di revisione. Queste misure forniscono tecniche non intrusive per approssimare l'efficacia della revisione: il livello di discussione osservato suggerisce che le revisioni moderne trovano difetti ad un livello comparabile con quello delle ispezioni tradizionali.
- In realtà il numero di difetti trovati durante una revisione è una misura limitata dell'efficacia della revisione, poiché ne ignora altri benefici, come la condivisione della conoscenza fra gli sviluppatori, che a sua volta facilita il coinvolgimento di nuovi sviluppatori e consente di avere sviluppatori che possono sostituirsi ad un altro che dovesse abbandonare il progetto. Per quantificare l'effetto di condivisione della conoscenza dovuto alla revisione, viene misurato il numero di file che uno sviluppatore ha modificato (sulla sinistra della figura) ed il numero totale di file che conosce (sulla destra). Tale misura mostra un sostanziale aumento nel numero di file di cui uno sviluppatore è a conoscenza esclusivamente conducendo revisioni. Chrome e Android hanno un grande numero di sviluppatori che hanno modificato o revisionato pochi file, questo è il fenomeno detto degli 'sviluppatori di passaggio', che magari si occupano solo di risolvere un bug che li interessa (tipico nell'OSS). SVILUPPO FUTURO: migliorare la misura per valutare la diversità della conoscenza degli sviluppatori assegnati ad una revisione (meno problemi di integrazione)
- Studiando un grande insieme di progetti, ognuno con i suoi tool, progessi, obiettivi, i dati collezionati non sono controllati come lo sarebbero in un'impostazione sperimentale. Quando un risultato era insolito, ne hanno discusso con gli sviluppatori. Ad esempio gli autori avevano trovato nel dataset Microsoft un certo numero di revisioni che non presentavano alcuna attività (commenti, disconnessioni). Gli sviluppatori intervistati hanno detto che quel tipo di revisioni sono usate per scopi diversi, cioè per avvisare un manager che una feature sta per essere implementata o mostrare ad un tester del codice per cui bisogna scrivere i test). Quindi tali revisioni sono state rimosse dal dataset, ma è possibile che una loro porzione fosse intesa effettivamente come revisione. Per quanto riguarda le ispezioni tradizionali sono stati usati i dati dello studio di Porter et al riguardo il Progetto Lucent, dati ricavati da un solo progetto, in uno specifico dominio, usando un solo linguaggio ed ambiente di sviluppo, in usa sola azienda software. Lo stesso autore dice che i risultati non possono essere generalizzati finché lo studio non viene replicato.
- Ricapitolando la revisione paritaria moderna rappresenta una versione light delle rispezioni software tradizionali, che ne rimuove le rigidità. La revisione si è evoluta in base ai bisogni dei praticanti che hanno guidato lo sviluppo di strumenti appositi. Sono stati confrontati i parametri di revisione (intervallo di revisione, numero di commenti nella discussione) di sei progetti con i dati di uno studio su sei progetti OSS, usando i dati delle ispezioni tenute a Lucent come contrasto. Dunque le pratiche convergenti di revisione del software sono queste
- Resta da verificare che le misure approssimative usate (come la varietà e quantità delle discussioni) possano essere effettivamente usate come nuove misure della qualità dei rilasci. Invece del numero di difetti trovati in un modulo, un manager potrebbe voler sapere se una nuova sezione di codice è stata discussa da sviluppatori con diversi background. A un certo punto gli autori si ponevano una domanda più generale, se sia più importante il dibattito e le discussioni che nascono circa il sistema durante le revisioni o l'effettivo ritrovamento e segnalazione di difetti. Si pensa che la misura di diffusione della conoscenza del sistema sia migliorabile, in modo da cogliere le differenti conoscenze degli sviluppatori assegnati ad una revisione. Se è possibile assegnare ad una revisione sviluppatori provenienti da diverse sezioni del sistema, diminuisce la probabilità che ci siano problemi di integrazione.