Che aspetto ha una revisione del codice? [duplicare]

Una revisione formale del codice potrebbe andare così:

1. Il programmatore invia materiale al revisore
2. Il revisore esamina il materiale
3. Il programmatore e il revisore si siedono attraverso il materiale. Il programmatore prende appunti. Le discussioni sul design sono posticipate.
4. Il programmatore corregge ciò che è uscito dalla recensione.

Il programmatore dovrebbe sempre parlare con i revisori, altrimenti troppe informazioni andranno perse.

Nota che dal momento che sei solo due persone nel team, puoi probabilmente cavartela con qualcosa di molto informale, come la procedura dettagliata del codice sullo schermo dei programmatori.

Nota anche che la programmazione della coppia è un'ottima alternativa alla revisione.

Ciò di cui sembri parlare è ciò che le persone chiamano "Pair Programming", seduti insieme e discutendo del tuo codice per assicurarti che sia privo di difetti. Questa è sempre una grande idea e normalmente incoraggiata. Tuttavia, non esclude la necessità di una revisione formale. Le recensioni formali consentono a tutti i membri del team di familiarizzare con il codice, oltre a un maggior numero di occhi è sempre un vantaggio!

Una revisione formale dovrebbe sempre includere sempre l'autore in modo che siano liberi di fare commenti chiarificatori secondo necessità. Tuttavia, non dovrebbero mai essere il protagonista nella revisione. Ciò impedisce loro di avere molto controllo sul processo e probabilmente di saltare alcuni aspetti importanti del loro codice.

Molte altre risposte spiegano come tenere traccia dei difetti riscontrati durante una revisione del codice, quindi non li ri-enumereremo qui, ma è sempre importante prendere appunti durante questi incontri e riportarli al autore. L'autore dovrebbe quasi sempre essere in ultima analisi responsabile dell'implementazione delle modifiche rilevate durante l'ispezione.

Nella mia scuola, i miei professori hanno creato un video di come dovrebbe essere un'ispezione del codice e quali dovrebbero essere i ruoli principali. Tutti noi lo troviamo piuttosto scadente, ma copre alcuni aspetti positivi. Puoi guardarlo qui: link

Secondo la mia esperienza, fare una revisione del codice in una riunione fisica formale di solito porta a una revisione troppo limitata del codice, o al paragone delle recensioni. Preferisco di gran lunga uno strumento come codice collaboratore , gerrit , o le funzionalità di revisione incorporate di alcuni controlli di versione che ospitano come github o kiln. Ciò ti consente di informare quante persone hai bisogno o desideri, quindi possono rivedere il loro tempo (mi riservo l'ultima ora del giorno). L'autore originale quindi esegue, verifica e carica eventuali correzioni e chiunque abbia rilevato il difetto segnala la correzione. Ciò ti consente di avere un approccio più agile e iterativo alle revisioni, piuttosto che essere un grande evento alla fine.

In azienda per cui lavoro, il processo è piuttosto semplice: la persona responsabile richiede il supporto di un collega (informalmente). Il colleage dovrebbe essere qualcuno che conosce la funzionalità di rilancio (ma questo non è un must).

Facciamo "revisioni di soluzioni concettuali" e recensioni di "implementazione".

Nella revisione "implementazione", il responsabile spiega il problema (se non è ancora noto) e la soluzione (se non è ancora nota) e quindi passa attraverso il codice e la documentazione interna. Questo accade sul computer dello sviluppatore (prima che venga eseguito il commit di qualsiasi codice). Durante questa fase, il revisore può dare suggerimenti per migliorare il codice o la documentazione. È anche comune che il responsabile chieda feedback su specifici problemi di implementazione (cioè mostra due implementazioni della stessa funzione e discuti quale è "migliore").

Idealmente, il responsabile dovrebbe mostrare alcuni test eseguiti con il nuovo codice (e il revisore può anche suggerire altri casi di test).

Questo è un processo semplice, ma spesso trova piccoli problemi.

A volte ci sono due richieste di revisione / revisori (ma questo è dovuto all'organizzazione dell'azienda: il codice è diviso da team specializzati e talvolta è necessario modificare il codice di qualcun altro).

Sono d'accordo con praticamente tutto @Karl Bielefeldt ha detto, ma aggiungerò un punto che ritengo importante:

La revisione del codice è (o dovrebbe essere) la programmazione di coppie asincrone.

La parte asincrona è ovviamente vera solo se il codificatore e il revisore non si trovano nella stessa stanza nello stesso momento. Per me, questo è meglio abilitato da uno strumento come la richiesta pull di github. Esistono sicuramente altri modi per automatizzare il processo, e ho visto una varietà di essi lavorare su domini dai dispositivi medici all'open source; tuttavia, ciò che li separa è l'ampia varianza dell'efficienza. Non conosco nessuno che non sia preoccupato per l'impegno di tempo coinvolto in questi giorni; quindi, penso che sia meglio automatizzare il processo fin dall'inizio.

La richiesta pull di Github ottiene il mio voto perché è individuabile e facilmente accessibile dai principianti tramite l'interfaccia web, e tuttavia, gestisce anche utenti più avanzati che preferiscono la linea di comando.

L'altra cosa che mi piace di questo sistema è che fa un buon lavoro nel separare i metadati di recensione (commenti sul codice) dal codice stesso e focalizza il revisore sulla fornitura di patch che aumentano il tasso di accettazione.

Se ci pensi, l'economia della revisione del codice è qualcosa di simile: la qualità derivata dalla revisione è una funzione dell'iterazione: l'attitudine e l'attitudine del revisore più l'apertura e la reattività del programmatore. Tutto ciò che puoi fare per aumentare la facilità e la velocità con cui avvengono queste iter di revisione offre una migliore qualità e un'esperienza più coesa per il team.

Vedrei anche Come devono essere eseguite le revisioni del codice?

Il processo di revisione che conosco è il seguente:

• Il codice sorgente viene gestito utilizzando un sistema di controllo della versione (ad esempio SVN).
• Qualsiasi modifica al software viene monitorata da un sistema di richiesta di modifica (ad esempio Bugzilla).
• Quando uno sviluppatore verifica alcune modifiche, queste sono allegate alla richiesta di modifica.
• Prima che la richiesta di modifica possa essere chiusa, la modifica deve essere esaminata da un altro sviluppatore. Ciò può avvenire direttamente (uno sviluppatore spiega le modifiche al revisore) o tramite uno strumento (ad es. link ) dopo che questi sono stati controllati -in già. In entrambi i casi, il revisore può approvare le modifiche o suggerire ulteriori modifiche.

In entrambi i casi (revisione diretta o tramite uno strumento), se il revisore approva le modifiche, la richiesta di modifica può essere impostata su "FISSO". Se il revisore richiede ulteriori modifiche, lo sviluppatore li implementa e è necessaria una nuova revisione. È lo sviluppatore originale che implementa queste ulteriori modifiche.

Per modifiche più grandi (ad esempio l'implementazione di nuove funzionalità) lo sviluppatore non spiega il cambiamento fino al più piccolo dettaglio: le idee principali e le tecniche di implementazione sono illustrate nel codice. Per modifiche minori (ad esempio correzioni di bug), c'è tempo per una discussione più dettagliata.

Il modo più semplice per eseguire una revisione del codice è quello di ottenere uno strumento (ho usato codestriker ). Quindi il processo è:

• il programmatore sceglie il codice per la revisione e i revisori
• revisori commentano il codice
• il programmatore passa attraverso i commenti e accetta ciò che è appropriato

In questo modo, i revisori possono farlo quando trovano il tempo per farlo. E il programmatore non ha bisogno di prendere appunti.

Un'alternativa alla revisione del codice è la programmazione in coppia. Alcuni lo chiamano recensione del codice sugli steroidi , ma è molto più di quello.

Il processo di base dovrebbe coinvolgere lo sviluppatore che si siede con i suoi pari e analizza in profondità il suo codice. Quanto è profondo dipende dalle dimensioni del progetto, quanto è importante ecc. I revisori dovrebbero avere accesso al codice prima della riunione in modo che possano concentrarsi sulla discussione dei difetti piuttosto che sulla lettura del codice.

Ogni riunione non dovrebbe essere troppo lunga - un'ora o così, quindi se c'è un sacco di codice diviso in parti più gestibili. È anche perfettamente accettabile rivedere solo una parte del codice, anche se di nuovo dipende dall'importanza del codice ecc.

È possibile passare attraverso il codice online o offline, ma non è necessario apportare modifiche durante la riunione. Prendi nota dei difetti come annotazioni sulla stampa o in un file separato.

Lo sviluppatore quindi torna indietro e corregge i difetti, rieseguendo eventuali test ecc. come richiesto. A seconda del numero e della gravità dei difetti, potrebbe esserci un'altra recensione, anche se questo potrebbe essere solo un esempio del codice.

In sostanza stai facendo due domande:

1. L'autore del lavoro da esaminare deve far parte della recensione?
2. Dovresti tenere traccia del feedback?

Nella mia esperienza, incluso l'autore del lavoro è essenziale .

• L'autore avrà l'opportunità di partecipare a e imparare da qualsiasi discussione che accada.
• L'autore è probabilmente il più adatto a risolvere eventuali difetti riscontrati nel lavoro; se ricevono solo un elenco di elementi di azione senza essere presenti per la revisione, perdono il contesto di qualsiasi discussione.
• L'autore può essere chiamato a difendere il modo in cui è stato scritto un artefatto.

Per quanto riguarda il monitoraggio del feedback della recensione: Sì , dovrebbe essere monitorato.

• Degli elementi trovati, quali sono i problemi di formazione?
• Quali sono le migliori pratiche da seguire per tutti i lavori futuri?
• Quali difetti erano difetti perché il codice è difficile da leggere, scarsamente documentato, ecc.?
• Quali difetti parlano di problemi più grandi che richiedono più lavoro di una risposta all'ispezione - dovrebbero essere meglio rintracciati come ticket di bug distinti da utilizzare quando le risorse lo consentono?

Hai intenzione di ottenere la conformità CMMI di qualsiasi tipo?

• Ti consigliamo di tenere traccia di tutti i difetti rilevati e del fatto che ciascuno di essi è stato risolto.

Il tuo cliente o contratto richiede la revisione di tutto il codice?

• Ti consigliamo di tenere traccia dei problemi e dei materiali di ispezione in modo da poter rispondere "SÌ" e dimostrarlo, se necessario.

La mia vista su un processo di revisione del codice.

In primo luogo, ci sono due regole di base:

1. nessuno può eseguire il commit del codice non revisionato
2. nessuno può esaminare un cambiamento che ha contribuito a

I. Quando un collega sta per commettere un cambiamento, ci sediamo insieme e

• controlla che ogni test case sia verde sul suo computer
• controlla che abbia scritto / modificato i casi di test
• controlla che il suo codice corrisponda alle linee guida di codifica esistenti
• controlla le sue modifiche e concentrati sulla Top 25 elenco di Jeff Atwood
• esaminiamo le sue modifiche e ne discutiamo

Questo è un controllo rapido, può essere fatto in 5 minuti. È un buon modo per ottenere un feedback veloce, conoscere le nuove modifiche e niente si rompe

II. Lo sviluppatore senior / team leader dovrebbe scegliere i commit su base giornaliera e esaminarli attentamente e condividere i suoi pensieri e le sue conclusioni con il team (quelli devono implementare i risultati che hanno scritto il codice sbagliato)

III. durante la retrospettiva (se ne hai) controlla il codice a vicenda per l'apprendimento

Ho bloggato l'argomento qui e here .