Come migliorare la recensione del codice?

Non c'è modo di migliorare la revisione del codice. L'unica cosa che puoi fare è continuare a migliorare con l'apprendimento e l'esperienza.

Normalmente le cose che seguo

- Use variables judiciously
- Keep things in scope loose boundaries will generate more errors
- Orient your language of coding in domain specific terms, they make more sense
- Keep loops to minimum 2 for each method if needed
- use ternary operators
- Arrange methods alphabetically
- Keep errors at handling ease
- write less but efficient code

Penso che ci sia molto da aggiungere.

Chiediti che cosa rende gli altri un buon recensore per te?

anche quando si passa attraverso il codice;

• fermati a qualsiasi cosa che non capisci ora scrivi che è necessario un commento
• identifica se è conforme agli standard di codifica: spazi, parentesi, camelCase..etc
• controlla che includa tutte le funzionalità
• fai semplici test della logica per vedere se passa le condizioni al contorno ecc.

Cerco solo

• spiegando perché è necessario un cambiamento suggerito. Assicurandomi di ottenere il motivo attraverso non solo la correzione
• accettando la formattazione del codice, in modo che il codice di tutti sia identico / familiare
• condivisione di un elenco di tratti di codice che si desidera mantenere. Metti su una wiki in modo che tutti non debbano fare ogni errore una volta. Aggiornalo frequentemente.

A parte questo, "sapere cosa cercare" viene solo con l'esperienza, la pratica e la lettura.

Nella mia esperienza, il modo migliore è quello di lasciare che il team del buco faccia la revisione del codice. Utilizziamo una mailing list di commit in ogni progetto in cui è possibile seguire tutte le modifiche al codice del sistema di controllo della versione. La maggior parte dei nostri sviluppatori si sono iscritti alla loro mailing list specifica per il progetto perché sono interessati alle modifiche al codice.

Quando qualcuno nota un brutto modo nel nuovo codice sorgente o spiega al committer come può farlo in un modo migliore, se il committer è un tirocinante, o inizia una discussione a riguardo, se è stato un committer più esperto .

Ovviamente questo metodo non garantisce che tutto il nuovo codice venga revisionato, specialmente in momenti di stress quando nessuno dei membri del team ha il piacere di seguire ogni cambio di codice. Inoltre, non tutti gli sviluppatori sono responsabili per garantire che ogni sviluppatore faccia il proprio lavoro, ma di questo non si può garantire che venga esaminato. Ma, almeno nei nostri team, c'è sempre un responsabile tecnico responsabile della qualità tecnica.

Sono un vero fan delle recensioni di codice se sono conformi ai seguenti punteggi:

• ogni sviluppatore ha la possibilità di rivedere tutto il codice e gli argomenti a suo parere
• nessuno ha il diritto di abusare del codice altrui
• non solo il codice errato attiva una discussione ma anche un buon codice
• le discussioni si concludono con felicità per ogni persona coinvolta
• la revisione avviene quasi in tempo reale, almeno prima che la funzionalità sia completata

Quello che ho imparato è che se sei qualcuno che esamina ogni riga di codice e pensa di dover controllare cose come la qualità del codice in termini di formattazione del codice o efficienza del codice, allora sei molto inefficiente perché fai cose che macchine può fare per te. L'obiettivo dovrebbe essere quello di utilizzare un sistema di integrazione continua che controlli la qualità di creazione e di codice di ciascun contributo del codice. Se questo sistema genera report e li invia ai contributori, tutto è perfetto.

Devo ammettere che se devi rivedere il codice perché devi controllare, o per classificare la qualità di un programmatore, i miei suggerimenti non hanno senso. In questo caso non vorrei rivedere il codice sorgente riga per riga. Vorrei rivedere cose come:

• ci sono problemi relativi alla sicurezza
• sono le API utilizzate
• il codice ha applicato l'architettura specificata
• ha scritto test utili (ma solo se è stato istruito implicito, ho dovuto imparare)
• Documentazione
• build-processo
• ... e altro ancora, probabilmente

Se sei uno sviluppatore esperto, sicuramente troverai sempre cose come loop che potresti fare con prestazioni migliori. Naturalmente è utile spiegare ad altri tale conoscenza ma questo non dovrebbe essere parte della sessione di revisione. Se ci sono problemi di prestazioni significativi, allora non perché lui (o lei) ha usato una variante meno efficiente di un tipo di lista.

Poiché la domanda iniziale era il motivo per cui alcune persone sembrano fare una recensione migliore in quanto altre persone risponderei che queste persone magari fanno un'anteprima prima dell'inizio della vera revisione, significa che probabilmente sono state preparate da loro in modo che sappiano esattamente cosa voglio rivedere.

[H]ow can I do a better job at performing a code review for someone else?

Fai molte domande

I know that to perform a code review you need to have knowledge of the how the existing code works...

In realtà no, non devi conoscere preventivamente il codice per essere un buon recensore.

Un paio di lavori fa, il mio datore di lavoro ha iniziato a richiedere che tutti i check-in del codice fossero firmati da un revisore. Stavo facendo per lo più il lavoro con la GUI in C, e uno dei migliori recensori per me era il mio amico Bill. Era abile in C, ma non aveva mai fatto molto lavoro con la GUI, ed entrando nelle recensioni non aveva idea di come avrebbe dovuto funzionare il mio codice.

Ma ha fatto molte domande a riguardo, e dovendo spiegare in modo da poter capire cosa ha fatto il mio codice e perché ha stimolato molte riflessioni da parte mia. Mi ha portato a trovare molti piccoli bizzarri con casi limite e anche a considerare altri approcci che avrei potuto adottare. Inoltre, anche se scrivevo C da 22 anni a quel punto e pensavo di essere abbastanza abile, ha rapidamente migliorato la qualità del mio codice.

Anche se non lavoro più lì, riesco ancora a riesaminare le differenze prima del check-in e mi chiedo: "Quali domande avrebbe Bill su questo?" E molto spesso, finisco per cambiare qualcosa come risultato.