Qual è il modo più efficace per eseguire le revisioni del codice? [chiuso]

Non ho mai trovato il modo ideale per eseguire revisioni del codice e tuttavia spesso i miei clienti le richiedono. Ogni cliente sembra farlo in un modo diverso e non mi sono mai sentito soddisfatto in nessuno di essi.

Qual è stato il modo più efficace per eseguire revisioni del codice?

Per esempio:

• Una persona è considerata il gatekeeper per qualità e rivede il codice o il team possiede lo standard?
• Esamini il codice come esercizio di gruppo usando un proiettore?
• Viene fatto di persona, via e-mail o utilizzando uno strumento?
• Eviti le recensioni e usi cose come la programmazione delle coppie e la proprietà del codice collettivo per garantire la qualità del codice?

Nel mio lavoro abbiamo una regola molto semplice: le modifiche devono essere riviste da almeno un altro sviluppatore prima di unire o eseguire il commit nel trunk . Nel nostro caso ciò significa che l'altra persona si siede fisicamente con te sul tuo computer e passa attraverso l'elenco delle modifiche. Questo non è un sistema perfetto, ma ha notevolmente migliorato la qualità del codice.

Se sai che il tuo codice verrà rivisto, ti costringerà a esaminarlo prima. Molti problemi diventano evidenti allora. Sotto il nostro sistema, devi spiegare cosa hai fatto al revisore, il che ti fa notare nuovamente problemi che potresti aver perso prima. Inoltre, se qualcosa nel tuo codice non è immediatamente chiaro al revisore, questa è una buona indicazione della necessità di un nome migliore, un commento o un refactoring. E, naturalmente, anche il recensore potrebbe riscontrare problemi. Inoltre, oltre a esaminare la modifica, il revisore può anche notare problemi nel codice vicino.

Ci sono due principali svantaggi di questo sistema. Quando il cambiamento è banale, ha poco senso rivederlo. Tuttavia, dobbiamo assolutamente attenerci alle regole, per evitare la pendenza scivolosa di dichiarare le modifiche "banali" quando non lo sono. D'altra parte, questo non è un ottimo modo per rivedere modifiche significative al sistema o l'aggiunta di nuovi grandi componenti.

In precedenza abbiamo provato revisioni più formali, quando uno sviluppatore inviava il codice e-mail per essere esaminato dal resto del team, quindi l'intero team si riuniva e ne discuteva. Ciò ha richiesto molto tempo a tutti, e di conseguenza queste recensioni erano poche e lontane tra loro, e solo una piccola percentuale della base di codice è stata rivista. "Un'altra persona che esamina le modifiche prima del commit" ha funzionato molto meglio per noi.

Mi piacciono le recensioni dei codici, anche se possono essere una seccatura. La ragione per cui mi piacciono è che ottengono più occhi sul codice e su una prospettiva diversa. Credo che anche con la programmazione in coppia, il codice dovrebbe essere rivisto. È abbastanza facile per due persone che lavorano sullo stesso codice fare collettivamente lo stesso errore che non può mancare a un diverso set di occhi.

Se fatto come un gruppo con un proiettore, dovrebbe davvero essere esaminato individualmente prima della riunione. Altrimenti, è solo una fastidiosa perdita di tempo.

Ho fatto solo revisioni del codice via e-mail e in gruppo. In generale, non penso che dovrebbero essere fatti di persona. Ti senti un po 'più sotto pressione per correre attraverso il codice con qualcuno che ti guarda alle spalle. Credo che uno strumento progettato per la revisione del codice sarebbe una buona risorsa, in quanto può aiutare con alcuni degli aspetti banali e dovrebbe rendere più semplice la segnalazione di bit problematici di codice rispetto all'e-mail.

Il problema di avere una persona che fa tutte le revisioni del codice è che può essere un collo di bottiglia. Con standard di codifica ben documentati e progettati non dovrebbe essere necessario. A seconda dell'ambiente / programma di rilascio può essere una buona idea avere sempre qualcuno come revisore del codice di standby.

Credo che la proprietà del codice sia una buona idea in quanto questa persona può fare della propria priorità la comprensione di quel codice e potenzialmente svolgere un ruolo di gatekeeper.

In SmartBear non solo realizziamo uno strumento di revisione del codice , ma lo usiamo anche quotidianamente. È una parte essenziale del nostro processo di sviluppo. Esaminiamo ogni modifica che viene verificata.

Penso che sia una cattiva idea avere un singolo revisore del codice gatekeeper per molte ragioni. Quella persona diventa un collo di bottiglia e deve fare troppa revisione del codice (solo per mantenere il progetto in movimento) per essere davvero efficace (60-90 minuti alla volta è il limite di efficacia). Le revisioni del codice sono un ottimo modo per condividere idee e conoscenze. Non importa quanto sia una superstar il tuo gatekeeper, possono imparare dagli altri membri del team. Inoltre, fare in modo che tutti eseguano revisioni del codice crea anche un ambiente di "proprietà del codice collettivo", in cui le persone sentono di possedere la qualità del codice (non è solo QA o gatekeeper).

Abbiamo un white paper gratuito su " Best Practices for Peer Code Review " che contiene 11 suggerimenti per rendere efficaci le revisioni del codice. Gran parte di questo è lo stesso contenuto del libro che John ha menzionato in una forma più distillata.

Niente scuse. Esercitati nella programmazione delle coppie. È la migliore recensione di codice possibile. Qualsiasi altro meccanismo si traduce in un gioco di colpa. La programmazione delle coppie induce lo spirito di squadra e la proprietà collettiva. Inoltre, si discute delle idee con la propria coppia, si fallisce rapidamente, si intraprendono azioni correttive ed è solo il codice codificato e rivisto della coppia che viene inserito in Configuration Management System (CMS). Buona programmazione per coppie!

Se stai lavorando a un progetto in cui più persone contribuiranno alla base di codice, è necessario stabilire uno standard.

A questo punto, nella mia esperienza, è meglio designare una persona come "re" della revisione del codice se lo si desidera e ciò che dice va. A questo proposito, se un utente non aderisce agli standard, il re se ne occuperà.

Come sviluppatore, rivedo il mio codice molte volte per essere leggibile, ragionevole e tutto il resto. Di solito usiamo javadoc o simili in determinate lingue con cui codifichiamo e utilizziamo il tag @author per associare la proprietà a funzioni, classi ecc.

Se una funzione non è corretta, parliamo con il proprietario, lo stesso con la classe ecc.

Nella mia azienda a ogni attività viene assegnato un tester per testare l'attività e anche un revisore del codice per rivedere il codice.

Se il tuo prodotto è già stato rilasciato e vuoi assicurarti di non fare nulla di sbagliato (come una perdita della maniglia o una perdita di memoria), le revisioni del codice sono un'ottima cosa. Penso che durante lo sviluppo iniziale prima di rilasciare il prodotto, le revisioni del codice potrebbero essere troppo impegnative.

Se il tuo team ha tutti gli sviluppatori senior, la revisione tra pari è ancora utile. Tutti commettono errori a volte. Se il tuo team ha degli anziani e degli junior, allora lascia che gli sviluppatori senior facciano le revisioni del codice, ma hanno ancora delle revisioni del codice per il codice dell'anziano.

Una cosa importante della revisione del codice è che può rilevare gli errori che commettiamo, ma non è un sostituto per i test.

Ti consiglio di usare le revisioni del codice se non stai programmando le coppie.

Non discutere i pro ei contro dell'abbinamento, ma è difficile contestare gli effetti positivi di avere il tuo codice costantemente rivisto da (almeno) un'altra persona. Il codice è persino scritto e progettato da (almeno) due programmatori: difficilmente può andare meglio di così. Sto dicendo che "almeno" perché imo, si dovrebbe cercare di cambiare le coppie un sacco in modo che tutti ottiene un colpo a lavorare con il codice.

Una delle cose che cerco di fare nelle revisioni del codice a cui partecipo è dopo aver esaminato il codice da solo, faccio un'analisi statica del codice, usando strumenti come Findbugs, PMD, JavaNCCP et al. il codice da rivedere. In particolare, voglio esaminare tutto ciò che presenta livelli di complessità insolitamente alti, chiedendo loro di spiegare perché è necessario quel livello di complessità o perché la vulnerabilità suggerita non è importante.

YMMV

Dove attualmente lavoro produciamo dispositivi hardware e il software che si interfaccia con essi che vanno in infrastrutture critiche. Di conseguenza, ci concentriamo molto sulla qualità di rilascio. Usiamo una variante di Fagan Inspection e abbiamo un processo di revisione formale. Siamo certificati ISO 9001, tra le altre certificazioni.

Il settore delle infrastrutture critiche è molto interessato all'affidabilità e alla ripetibilità degli stessi. :-)

Nella mia azienda abbiamo revisioni obbligatorie del codice per programmatori junior e revisioni volontarie per gli anziani. Non esiste un revisore del codice designato, le richieste di revisione vengono inviate a tutti gli sviluppatori.

Questo sistema funziona bene - le revisioni vengono eseguite quando il tempo lo consente e le modifiche possono essere riviste da diversi set di bulbi oculari.

L'eccellente e gratuito strumento Review Board funziona davvero bene per noi e ha dimostrato di essere un ottimo modo per comunicare le recensioni.

Nella mia azienda, non effettuiamo mai revisioni formali del codice prima del check-in, a meno che non stiamo modificando una produzione altamente critica e non abbiamo il tempo di eseguire il nostro processo di QA standard.

Ciò che facciamo è che ogni volta che riteniamo utile una revisione del codice, aggiungiamo un commento "// todo: revisione del codice di joe" al codice modificato. Di solito, selezioniamo Joe perché possiede il codice modificato, ma se questo criterio di selezione non si applica (di solito lo fa), abbiamo semplicemente scelto qualcun altro a caso. E, naturalmente, se Joe fosse disponibile in quel momento, useremo il buon vecchio metodo di revisione da sopra le spalle.

Come revisore, l'unica cosa che devi fare è cercare periodicamente l'intero codice "// todo: revisione del codice da parte mia" , rivedere le modifiche e ricontrollare il codice senza il commento "todo ..."

In caso di problemi, torniamo ai metodi di comunicazione tradizionali (posta / chat / ecc.).

Questo metodo ci fornisce le due principali qualità che stiamo cercando in un sistema di revisione:

• sovraccarico molto leggero
• tracciabilità

Troviamo che il modo più efficace per fare le revisioni del codice sia 1 su 1 usando github per mostrare le differenze nel ramo.

• Una persona è considerata il gatekeeper per qualità e rivede il codice o il team possiede lo standard?

  • Dipende dalle dimensioni della squadra: una squadra di 3 avrà 1 anziano che ha la migliore conoscenza delle buone pratiche, mentre una squadra di 12 può avere 3 o 4 persone che ricopriranno quel ruolo.

• Esamini il codice come esercizio di gruppo usando un proiettore?

  • Di persona. 1 su 1 per essere meno minaccioso. A volte fatto nell'area comune anche se per diffusione della conoscenza. Dipende dalla situazione esatta, dalle persone, dagli orari, ecc.

• Viene fatto di persona, via e-mail o utilizzando uno strumento?

  • Di persona. Usiamo git e github e ha ottimi strumenti di revisione del codice e confronto diff per facilitare la revisione del codice.

• Eviti le recensioni e usi cose come la programmazione delle coppie e la proprietà del codice collettivo per garantire la qualità del codice?

  • Cerchiamo di fare entrambi nel modo appropriato. Ciò significa che quando si è bloccati su un problema particolarmente spinoso, o quando si lavora su un'infrastruttura di base o quando si prepara per le vacanze o si lascia la società, è possibile eseguire l'associazione per condividere e trasferire le conoscenze. La maggior parte del codice o codice che ha qualcosa di più delle modifiche estetiche dovrebbe essere rivisto alla fine.

Come per tutti gli elementi di codifica, la risposta giusta dovrebbe tenere conto di:

• Tipo di azienda (ad es. Startup vs. grande società)
• Dimensione aziendale
• Numero di sviluppatori
• bilancio
• Lasso di tempo
• Carico di lavoro
• Complessità del codice
• Capacità del / i revisore / i
• Disponibilità dei revisori

Ho lavorato in molte aziende e ho visto molti processi. La mia squadra attuale gestisce questo il meglio che ho visto finora.

Usiamo un processo di sviluppo agile e come parte di ciò abbiamo porte che ogni storia deve attraversare. Una di queste porte è la revisione del codice. La storia non passa al test fino a quando non viene completata la revisione del codice.

Inoltre, memorizziamo il nostro codice su github.com. Quindi, dopo che uno sviluppatore ha terminato la modifica, pubblica il collegamento ai commit sulla trama.

Quindi taggiamo un collega sviluppatore per esaminarlo. Github ha un sistema di commenti che consente a qualcuno di commentare direttamente sulla riga di codice in questione. Github invia quindi un'e-mail alla distribuzione, quindi a volte otteniamo effettivamente ulteriori occhi da alcuni dei nostri altri team.

Questo processo ha funzionato molto bene per noi. Utilizziamo uno strumento di processo agile che semplifica la pubblicazione degli commit e facilita la comunicazione.

Se un problema è particolarmente appiccicoso, ci sediamo e ne discutiamo. Questo funziona perché è parte integrante del nostro processo e tutti hanno acquisito il merito di come funziona il processo. Siamo in grado di riportare i biglietti in corso se la revisione del codice risulta nella necessaria rielaborazione e quindi può essere riesaminata dopo aver apportato le modifiche, oppure il revisore può notare sulla storia che la correzione degli articoli è sufficiente e non deve essere rivista di nuovo.

Se il test fa tornare indietro qualcosa torna indietro allo stato di avanzamento e anche eventuali ulteriori modifiche vengono riviste.