La revisione del codice è una buona pratica?

Le recensioni dei codici sono un'ottima pratica.

Probabilmente è il modo migliore per imparare dagli errori e vedere come alcuni problemi vengono risolti da altri. È anche uno dei modi migliori per mantenere la qualità in una base di codice.

Le revisioni del codice si verificano in molte aziende, sebbene sia difficile affermare che esiste un processo specifico seguito da tutti.

Nella revisione più formale del codice, un senior (o diversi senior) siederanno insieme a uno sviluppatore per rivedere il loro codice, offrendo suggerimenti e insegnando allo stesso tempo.

Ulteriori vantaggi per le revisioni del codice (come commentato per questa domanda), includono:

• Un ottimo modo per insegnare e imparare
• Sono uno dei modi migliori per migliorare e mantenere la coerenza di una base di codice (stile e idiomi)
• Aiutano a garantire che tutti i membri del team comprendano lo stile e gli idiomi utilizzati nel progetto e come usarli
• Le revisioni del codice accelerano lo sviluppo poiché individuano bug e difetti di progettazione precocemente (quindi, sebbene possano rallentare lo sviluppo iniziale, pagano dividendi nei cicli di sviluppo successivi)
• È disponibile un supporto per gli strumenti che semplifica il processo di revisione del codice

Le recensioni di codice sono strumenti molto utili per l'apprendimento molto utili, soprattutto quando hai un nuovo membro del team a bordo. Beh, è anche noto come processo di revisione tra pari:)

Esistono diversi tipi di revisioni del codice:

• Over-the-shoulder - in cui uno sviluppatore guarda oltre la spalla dell'autore del codice mentre quest'ultimo percorre il codice.
• Email pass-around : il codice di gestione del codice sorgente invia il codice ai revisori automaticamente dopo il check-in. Estratto dal commento: Avendo fallito nel convincere il management ad allocare il tempo per qualsiasi tipo di revisione formale del codice, ho preso in considerazione le modifiche apportate ai miei colleghi ogni volta che estraggo nuove revisioni dal controllo del codice sorgente usando la cronologia / diff strumenti integrati in Tortise
• Programmazione delle coppie - Due autori sviluppano il codice insieme nella stessa workstation, come avviene comunemente in Extreme Programming.
• Revisione del codice assistita dagli strumenti : gli autori e i revisori utilizzano strumenti specializzati progettati per la revisione del peer code.

Esiste solo un associated disadvantage in cui le revisioni del codice formale richiedono un notevole investimento in preparazione per l'evento di revisione e il tempo di esecuzione.

Altri riferimenti sono elencati di seguito (per ulteriori letture approfondite)

• MSDN - Analisi del codice
• Trova e correggi le vulnerabilità prima che l'applicazione salvi
• link Wiki

Quella particolare pratica sembra inefficiente e verosimilmente imbarazzante - chi vuole che i propri errori siano puntati su un intero gruppo di persone. Quindi, se non possono scegliere cosa deve essere rivisto e il codice non è ancora in produzione, è probabile che ciò possa rendere le persone a disagio.

A seconda di quando il codice viene riesaminato, può fare una grande differenza se i commenti di revisione del codice lo fanno nel codice oppure no. Se lo sviluppatore può scegliere e scegliere solo il codice di produzione, è improbabile che i commenti di revisione vengano implementati. È bello avere riunioni in cui gli sviluppatori possono mostrare una tecnica ingegnosa che hanno appreso che altre persone potrebbero essere interessate, ma non è una revisione del codice. Questo è l'allenamento.

Facciamo una revisione del codice di ogni pezzo di codice prima che venga spostato al QA. Ogni pezzo Coinvolge generalmente solo il revisore del codice e lo sviluppatore. Non passa al controllo qualità finché il revisore del codice non lo inoltra formalmente. Quindi lo sviluppatore deve apportare le modifiche. Abbiamo trovato e risolto rapidamente molti problemi che il controllo di qualità potrebbe non aver trovato (trovano anche cose che non vediamo nella revisione del codice). Inoltre, riduce la codifica dei cowboy e identifica rapidamente quelle persone che non stanno ottenendo buoni risultati in modo da poter risolvere i loro problemi e addestrarli o eliminarli prima che danneggino la nostra applicazione. Il tempo di revisione del codice fa parte della nostra stima del tempo quando si pianifica il lavoro in modo da non avere alcun impatto sulla scadenza. In realtà, a lungo termine si risparmia tempo perché prima si trova un problema più è facile da risolvere. Tra l'altro i revisori del codice sono peer non manager e coinvolgiamo persone a tutti i livelli nella revisione del codice.

Personalmente ho insegnato agli sviluppatori meno esperti molte tecniche migliori attraverso la revisione del codice e ho imparato alcune tecniche migliori personalmente rivedendo il codice di altre persone e i loro commenti sul mio codice. Un'ulteriore revisione del codice fa in modo che qualcun altro comprenda il codice che è molto importante per renderlo più gestibile. A volte, il codice funziona, ma le domande della revisione rendono chiaro che ci saranno problemi di mantenimento perché il codice è difficile da capire. Meglio rifattorici in questi casi, mentre è ancora tutto fresco nella tua mente di un anno dopo, quando anche l'autore del codice viene lasciato a grattarsi la testa e si chiede perché il codice fa così e così.

Il problema con questo tipo di revisione del codice, uno sviluppatore ogni due settimane, il progresso sarà lento. Potrebbero passare mesi prima che tutti abbiano una svolta sotto i riflettori.

Sebbene le recensioni del codice possano essere valide, deve esserci un motivo dietro di esse e dietro la procedura per eseguirle.

Diversi problemi dovrebbero essere risolti:

• Chi sceglierebbe lo sviluppatore e quanto preavviso sarebbero stati forniti. Nessuna recensione di avviso è trappola.
• Chi sceglierebbe la porzione di codice da rivedere: la gestione, lo sviluppatore senior del progetto o lo sviluppatore in fase di revisione.
• È lo scopo di insegnare alla persona il cui codice è sul proiettore come fare qualcosa di meglio, o è lo scopo della persona il cui codice è sul proiettore per insegnare a tutti gli altri intorno alla stanza come migliorare il proprio codice.
• Quale percentuale di codice verrà esaminata in questo modo, questa sarà una parte della procedura di QA?

Se le persone che hanno proposto questo piano non hanno già risposto a queste domande, è possibile che leggano un articolo su come tutte le grandi aziende fanno revisioni del codice, quindi dovremmo fare anche loro, senza capire lo scopo dietro di esse.

La revisione del codice è una buona pratica, solo quando l'idea per la revisione del codice proviene dal team di sviluppo. Gli sviluppatori non hanno bisogno di proiettori e presentazioni per rivedere gli altri codici. Se lo desiderano, preferiranno andare alla conferenza.

Quando l'idea della revisione del codice viene dal management - può sembrare un'indagine sulla scarsa qualità del software e può demoralizzare il team di sviluppo. Non penso che il team di gestione debba essere coinvolto nel processo di revisione del codice. Revisione del codice fianco a fianco con il team di gestione: pratica molto brutta, omicida e distruttiva.

La revisione del codice è una pratica eccellente, in particolare se viene svolta dagli sviluppatori per condividere le conoscenze e le regole di base vengono impostate anticipatamente che suggerimenti e critiche intendono essere COSTRUTTIVI e non utilizzare un singolo sviluppatore per la pratica del target .

I manager che non sono sviluppatori saranno accolti con sospetto dagli sviluppatori se decidono di fare revisioni del codice. La maggior parte dei tipi di manager non vuole entrare nei dettagli che gli sviluppatori intrinsecamente entrano nel guardare il codice. La maggior parte dei manager non capirà perché gli sviluppatori criticano un approccio rispetto a un altro.

Se vuoi mostrare il buon lavoro che gli sviluppatori stanno facendo alla gestione, la "revisione del codice" ha un significato diverso e non dovrebbe essere così dettagliata come le revisioni del codice che vengono fatte per istruire / migliorare la qualità del codice tra gli sviluppatori. Questo tipo di presentazione può essere utile per dimostrare cosa fanno gli sviluppatori se la presentazione può essere di livello superiore e meno specifica del codice, concentrandosi su ciò che i manager comprendono (valore, ROI, ecc.). Potrebbe far capire ai manager che Joe ha aggiunto un valore significativo alla società costruendo X, che possiamo mostrare un risparmio di tempo Y, o Z dollari per ordine, ecc. Penso che valga la pena di mostrare il valore dei singoli membri della tua squadra. Ricorda, tuttavia, che devi stare attento a non sovraccaricare il tuo pubblico con espressioni gergali o troppi livelli di dettaglio.

Pur condividendo pienamente l'idea che le revisioni del codice siano molto costruttive per l'insegnamento, vorrei comunque evidenziare, per me, che i modelli di progettazione della squadra vengono seguiti correttamente.

Scriviamo un piccolo prototipo di lavoro e rifattiamo bit di codice e mentre ci sentiamo a nostro agio con il prodotto alla fine la leggibilità è stata danneggiata - le persone non possono guardarlo e vedere chiaramente cosa sta succedendo.

Gli occhi indipendenti sono sempre benefici che trovo quando vieni bloccato in certi modi di pensare e questo è a tutti i livelli di esperienza. Hai investito ore nel design e nel codice e quindi le recensioni del codice sono difficili da gestire quando c'è il timore che il tuo sforzo venga gettato via. Eppure alla fine tu, si spera, finisci con un'applicazione più pulita, più snella e più gestibile e l'esperienza è radicata in te.

Per il nostro team facciamo come @ElYusubov menzionato e utilizziamo uno strumento specifico per Code Review - Crucible. Le persone recensiscono, commentano e firmano il codice. Ogni settimana ci sediamo e esaminiamo faccia a faccia pezzi di codice interessanti e / o complessi.

Come stagista di ingegneria del software, ho trovato le recensioni del codice estremamente utili.

Nel mio team, è necessaria una revisione del codice per ogni commit (i grandi cambiamenti finiscono per essere formali, i cambiamenti minori diventano "quick look"). Sicuramente mi sento come se le mie costellazioni ingegneristiche / di progettazione siano state potenziate da questo, soprattutto perché sono più propenso a tirare fuori la lavagna rispetto al terminale fin da quando so di essere "osservato". :)

In effetti, penso che produca un codice molto migliore con l'unico lieve inconveniente di un tempo di sviluppo leggermente più lento (che a mio parere vale la pena nel lungo periodo quando non è necessario correggere / estendere codice progettato in modo eccessivo ). Inoltre, penso che se hai junior / stagisti nel team apprezzeranno la possibilità di avere un feedback prezioso. So che lo faccio!

Dalla mia esperienza Code Review è davvero una grande cosa se la esegui bene. Quando hai membri e manager di team professionisti / maturi. Noi come programmatori siamo "risolutori di soluzioni". Il nostro compito non è creare linee di "testo". Ecco perché dobbiamo condividere idee, errori, problemi, esperienze. La revisione del codice è davvero una buona pratica per raggiungere questo obiettivo.

Sfortunatamente sembra fantastico ma è davvero difficile da implementare nella maggior parte delle aziende. La tua squadra ha bisogno di molta "autonomia". Convincere i tuoi manager o il reparto finanziario che non creano nuove funzionalità è proficuo sembra difficile.

Nella mia azienda stiamo provando a fare qualche revisione del codice. Ma trascorre troppo tempo con "inseguire il coniglio" (creare feature).

Gran parte dello stile e dei controlli di tipo sintattico di base vengono rilevati utilizzando gli strumenti al giorno d'oggi (FXCop, ecc.).

Tuttavia, le revisioni del codice sono buone, specialmente con i nuovi membri di un team, roba complessa o di alto impatto (ad esempio qualcosa che sarà visibile a persone importanti se fallisce o causa un impatto sul business) e soprattutto quando si esternalizza o usa gli appaltatori a breve termine (specialmente quando non sono madrelingua come errori di traduzione / problemi linguistici possono consentire al software di superare tutti i test ma non effettivamente fare ciò che si suppone).

Non sono un fan di mettere il codice su un proiettore per una squadra a scegliere - molto meglio avere una riunione di revisione del codice in cui un altro membro del team (team leader, ecc.) passa attraverso un elenco con lo sviluppatore. Questo ha un impatto minore sulle persone - si ferma un sacco di tempo sprecato per argomenti di stile - ed è meno imbarazzante per lo sviluppo. È più costruttivo e più facile per lo sviluppatore assorbire problemi reali e non essere accecato da "Avrei fatto questo ...".

Penso anche che le revisioni non forzate del codice, come mettere il codice su una condivisione o inviarlo via email nella speranza che qualcuno rinunci all'ora di pranzo per affrontarlo, è una perdita di tempo.

Sedersi con una pila di annunci, un pennarello e una tazza di caffè nella zona del caffè è perfetto per questo.

Questo tipo di show e tell di gruppo andrebbe bene per le nuove tecnologie o per ottenere più jr. si evolve alla velocità, ma non penso che sia buono come una revisione coerente del nuovo codice. È più efficiente doverlo fare uno contro uno.

La revisione del codice aiuta a vedere "il tutto". Gli sviluppatori separati hanno la tendenza a vedere solo i loro requisiti / problemi. CR scopre idee e soluzioni da tutta la prospettiva. Il CR aiuta principalmente a eliminare lo spreco di lavoro non necessario. L'intero prodotto è più economico e di migliore qualità.