Qual è lo scopo di una revisione del codice

76

Sto tentando di vendere la mia organizzazione sul valore delle revisioni del codice. Ho lavorato in diversi posti dove sono stati impiegati. Li ho visti abituati a scegliere le scelte stilistiche e le decisioni funzionali, e li ho visti usati come nient'altro che un controllo dell'intestino per assicurarsi che non venisse implementato nulla di pericoloso. La mia sensazione è che lo scopo più efficace sia tra le due opzioni.

Quindi, qual è lo scopo di una revisione del codice?

code-reviews theory

— SoylentGray
fonte

16

Correlato (su Stack Overflow): The Purpose of Code Reviews

— yannis

16

- Come faresti a sapere se hai scritto un codice leggibile e facilmente gestibile? - Il tuo peer ti dice dopo aver esaminato il codice. 'Motivazione: Non puoi determinarlo da solo perché sai più come autore di quanto il codice dice da solo. Un computer non può dirti, per gli stessi motivi che non può dire se un dipinto è arte o no. Quindi, hai bisogno di un altro essere umano - in grado di mantenere il software - per guardare ciò che hai scritto e dare la sua opinione. Il nome formale di detto processo è "Revisione tra pari" . "

— moscerino

3

"Qual è lo scopo di una revisione del codice?" per impedire agli sviluppatori di scrivere codice terribad e guidarli nella giusta direzione.

— zzzzBov,

7

Sembra che Code Review possa avere una risposta indiretta a questa domanda .. basta cercare le domande e le risposte lì, lo scopo di una revisione del codice diventa abbastanza evidente :)

— Mathieu Guindon,

3

Mi chiedo quante volte i programmatori hanno scoperto bug nel proprio codice proprio attraverso il semplice processo di spiegazione del loro codice durante una revisione?

— ascia inattiva

75

Esistono diversi motivi per cui si desidera condurre una revisione del codice:

Formazione di altri sviluppatori. Assicurarsi che tutti vedano la modifica associata a una correzione o un miglioramento dei difetti in modo da poter comprendere il resto del software. Ciò è particolarmente utile quando le persone stanno lavorando su componenti che devono essere integrati o su sistemi complessi in cui una persona può andare per lunghi periodi senza guardare determinati moduli.
Individuazione di difetti o opportunità di miglioramento. Sia il codice consegnabile che il codice di prova e i dati possono essere esaminati per trovare punti deboli. Ciò garantisce che il codice di test sia solido e valido e che la progettazione e l'implementazione siano coerenti in tutta l'applicazione. Se è necessario apportare ulteriori modifiche, coglie l'opportunità più vicino al punto di entrata.

Esistono diversi casi aziendali per lo svolgimento di recensioni:

Individuazione di difetti o problemi che dovrebbero essere rielaborati più vicino alla loro iniezione. Questo è più economico.
Comprensione condivisa del sistema e formazione incrociata. Meno tempo per uno sviluppatore di accelerare per apportare modifiche.
Individuazione di possibili miglioramenti del sistema.
Aprire l'implementazione per garantire che i tester forniscano una copertura adeguata. Trasformare una scatola nera in una scatola grigia o scatola bianca dal punto di vista del test.

Se stai cercando una discussione completa sui vantaggi e sulle strategie di implementazione per le revisioni tra pari, ti consiglio di dare un'occhiata alle Recensioni tra pari nel software: una guida pratica di Karl Wiegers .

— Thomas Owens
fonte

7

+1, penso che tu abbia individuato bene i punti principali, con le priorità corrette. Mantenere il design coerente quando si tratta di colleghi che trovano costantemente soluzioni "WTF" molto creative può essere ottenuto solo attraverso revisioni periodiche del codice.

— Doc Brown,

Eseguiamo revisioni del codice nel nostro codice JavaScript, principalmente per garantire che gli sviluppatori si attengano agli standard delineati, utilizzando lo schema definito durante la progettazione dei moduli, utilizzando i componenti forniti e non iniziando a fare la codifica ninja (intenzionalmente o meno) attorno a problemi che già abbiamo soluzioni per. Sono anche ottimi per individuare qualcuno che sovrascrive accidentalmente il thiscontesto, non usandolo .hasOwnPropertyin luoghi in cui dovrebbe trovarsi, ecc. Ecc. - Quindi, principalmente per gli standard. In una lingua gestita come C #, ovviamente, hai molte meno ragioni per le lingue dinamiche.

— No l'

1

Finora la tua risposta allude solo a miglioramenti della correttezza del codice. Non riesce a indirizzare la leggibilità / manutenibilità del codice, che raramente può essere quantificato con precisione dallo sviluppatore in via di sviluppo.

— Art

51

Le revisioni del codice sono uno strumento per il trasferimento delle conoscenze .

Quando gli sviluppatori riesaminano il codice reciproco, acquisiscono familiarità in tutte le aree del sistema. Ciò riduce il fattore di bus di un progetto e rende gli sviluppatori più efficienti quando devono eseguire la manutenzione su una parte del sistema che non hanno scritto.
Quando un programmatore junior rivede il codice di un senior, il programmatore junior può raccogliere trucchi altrimenti appresi solo attraverso l'esperienza. Questo può anche funzionare come un correttivo contro il codice eccessivamente complicato.

Una revisione approfondita del codice richiederà controlli frequenti rispetto a vari documenti. È un ottimo modo per imparare una lingua o un'API.
Quando un programmatore senior rivede il codice di un junior, questa è un'opportunità per appianare i problemi prima che si traducano in debito tecnico. Una revisione del codice può essere una buona impostazione per tutorare i programmatori junior.

Le revisioni del codice non riguardano:

... alla ricerca di bug. Ecco a cosa servono i test. Accadrà spesso che una revisione del codice rilevi qualche problema.
... puntando su problemi di stile: accontentati di uno stile e usa i formattatori automatici per applicarlo. Ma ci sono molte cose che uno strumento automatico non può controllare. Le revisioni del codice sono un buon posto per assicurarsi che il codice sia sufficientemente documentato o autocompattante.

— amon
fonte

2

il tuo ultimo punto su problemi di stile di nitpicking con cui non sono completamente d'accordo - abbiamo appena avuto un'esperienza straziante rivedere il codice di uno sviluppatore junior e la lamentela più evidente era in realtà sullo stile, ma non sui tipi di problemi di stile che sono facilmente programmabili fatto valere .... waaaaaay troppi se dichiarazioni per edgecase ecc; problemi che sì, potresti trovare un computer in alcuni casi, ma la maggior parte non erano problemi che vale la pena trovare genericamente tramite script. Ci vogliono 30 secondi per leggere per iniziare a vederlo, altri 30 per spiegare allo sviluppatore e speriamo di risolvere il problema. Ancora sotto shock: /

— pacifista,

7

@pacifist Questo non è il tipo di stile che il risponditore sta descrivendo. Lo stile riguarda le posizioni di parentesi graffe, rientri e così via. Se il tuo sviluppatore junior sta usando troppe istruzioni if hai un problema completamente diverso dallo stile; un attributo generale della codifica STILE è che non influisce sulle prestazioni. E penso che una quantità significativa di dichiarazioni if avrà un impatto sulle prestazioni.

— Pimgd,

12

Quando faccio una recensione, rilevo spesso cose in cui penso "questo assomiglia a un bug", quindi scrivo un caso di prova specifico per dimostrare che si tratta di un bug. Quindi uno dei tanti obiettivi delle revisioni del codice è trovare bug. Ecco perché penso che il punto di vista "revisione del codice o test" sia un po 'troppo semplice.

— Doc Brown,

2

Oltre a @DocBrown ci sono casi che non possono essere facilmente verificabili: gare di dati, alcuni tipi di deadlock, livelock, comportamenti / valori indefiniti (principalmente in C / C ++ ma l'ordine degli elementi nelle tabelle hash anche non definito) o porro di risorse (l'apertura di un file in un ciclo potrebbe essere una cattiva idea anche con GC). Alcune di queste cose possono essere rilevate mediante un'analisi statica del compilatore sufficientemente intelligente .

— Maciej Piechotka,

2

@pacifist il tuo esempio specifico verrebbe completamente distrutto in una revisione del codice. Sarebbe anche una bandiera rossa per qualsiasi analizzatore di codice statico (complessità ciclica 17!). Una revisione del codice identificherebbe rapidamente questa funzione come un problema in stile semantico (o addirittura l'algoritmo!). Però. Questo tipo di problema non è solo un problema di "stile". Se lo tratti come tale, avrai presto un codice davvero brutto nel tuo repository; è solo "stile", dopo tutto.

— Pimgd

12

La cosa più preziosa che ottengo personalmente da una revisione del codice è la sicurezza che il codice sia chiaro a un'altra persona. Le variabili hanno un nome chiaro? Lo scopo di ogni blocco di codice è ragionevolmente ovvio? C'è qualcosa di ambiguo chiarito con un commento? I casi limite e i valori validi per i parametri sono indicati nei commenti e controllati nel codice?

2

questo non sembra offrire nulla di sostanziale rispetto alle precedenti 4 risposte

— moscerino

2

@gnat: le altre risposte riguardano il trasferimento di conoscenze e l'individuazione di bug. Questi sono importanti, ma c'è di più per una revisione del codice.

1

per quanto ne so, c'è un'altra parte che è ragionevolmente affrontata in questa risposta : "Se stai cercando una discussione completa sui vantaggi e sulle strategie di implementazione per le revisioni tra pari, ti consiglio di dare un'occhiata alle Recensioni tra pari nel software: Una guida pratica di Karl Wiegers. " Questa risposta copre anche: "un correttivo contro un codice eccessivamente complicato"

— moscerino

2

@gnat Sottolinea un aspetto diverso dei punti sollevati in altre risposte. Sei mai stato perplesso dal tuo codice che hai scritto sei mesi fa? La revisione del codice consente di accelerare tale processo. Se il tuo collega è perplesso dal tuo codice, puoi ancora chiarirlo mentre il problema è ancora aggiornato nella tua memoria.

— 200_success

1

@ 200_success forse. Ma questo punto, se è davvero lì, sembra davvero mal presentato. Anche il tuo commento riesce a comunicarlo meglio di questa "risposta". Per non parlare del fatto che ripete solo ciò che è stato sottolineato in un precedente commento che si riferisce alla risposta canonica che spiega questo in una domanda correlata

— moscerino

7

Vorrei aggiungere due aree non coperte dalle altre grandi risposte:

Una grande ragione per la revisione del codice è l' effetto Hawthorne che nel nostro caso si traduce in: Se sai che qualcuno guarderà il tuo codice in seguito, allora avrai molte più probabilità di scriverlo meglio in primo luogo.

Un'altra grande ragione è per le migliori pratiche di sviluppo sicure. Basta guardare al fallimento di Apple (una linea di codice duplicata accidentale) o al bug Heartbleed (un errore di base nella convalida dell'input) per comprendere l'importanza delle revisioni del codice corrette in un ciclo di vita dello sviluppo sicuro.

— Chris Knight
fonte