Come migliorare la revisione del codice?

Innanzitutto credo fermamente nel processo di revisione del codice e voglio sempre che qualcun altro riveda il mio codice. La mia domanda è davvero incentrata su come posso fare un lavoro migliore nell'esecuzione di una revisione del codice per qualcun altro?

So che per eseguire una revisione del codice è necessario avere una conoscenza di come funziona il codice esistente e una conoscenza di cosa sia lo standard locale, entrambi i quali ritengo di conoscere molto bene. Mi sento comunque come se non avessi mai fatto una recensione abbastanza buona del codice per altre persone. Inoltre so che alcune persone sembrano fare un codice di revisione del lavoro migliore di altre, quindi mi chiedo per quelli che sono ottimi revisori del codice quali sono le tecniche che usi?

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

Di solito 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 ad esso.

chiediti cosa rende gli altri un buon recensore per te?

inoltre, mentre attraversi il codice;

• fermati a tutto ciò che non capisci ora scrivi che è necessario un commento
• identificare se è conforme agli standard di codifica: spazi, parentesi, camelCase..etc
• controlla che includa tutte le funzionalità
• fare semplici test della logica per vedere se supera le condizioni al contorno ecc.

Ho solo l'obiettivo

• spiegando perché è necessaria una modifica suggerita. Assicurandomi di capire il motivo non solo della correzione
• concordare sulla formattazione del codice - in modo che il codice di tutti sembri uguale / familiare
• condividere un elenco di tratti di codice che si desidera mantenere. Mettilo su una wiki in modo che tutti non debbano commettere ogni errore una volta. Aggiornalo frequentemente.

A parte questo, "sapere cosa cercare" arriva solo con esperienza, pratica e lettura.

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

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

Ovviamente questo metodo non garantisce che tutti i nuovi codici vengano rivisti, specialmente in periodi di stress in cui nessuno dei membri del team ha il tempo libero di seguire ogni modifica del codice. Inoltre, non tutti gli sviluppatori sono responsabili di garantire che ogni sviluppatore svolga bene il proprio lavoro, da solo non è possibile garantire che venga riesaminato. Ma, almeno nei nostri team, c'è sempre un responsabile tecnico responsabile della qualità tecnica.

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

• ogni sviluppatore ha la possibilità di rivedere tutto il codice e l'argomento secondo la sua opinione
• nessuno ha il diritto di abusare del codice altrui
• non solo un 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 del completamento della funzione

Quello che ho imparato è che se sei qualcuno che rivede ogni riga di codice e pensa che devi controllare cose come la qualità del codice in termini di formattazione del codice o efficienza del codice, allora sei te stesso molto inefficiente perché fai cose per le quali le macchine possono fare tu. Il tuo obiettivo dovrebbe essere quello di utilizzare un sistema di integrazione continua che controlla la qualità del build e del codice di ciascun contributo del codice. Se questo sistema genera report e li invia ai collaboratori, tutto è perfetto.

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

• ci sono problemi rilevanti per la sicurezza
• si intendono API utilizzate
• il codice ha applicato l'architettura specificata?
• ha scritto test utili (ma solo se è stato istruito implicitamente, ho dovuto imparare)
• Documentazione
• l'accumulo di processo
• ... e alcuni altri, probabilmente

Se sei uno sviluppatore esperto troverai sicuramente cose come i loop che potresti fare con prestazioni migliori. Naturalmente è utile spiegare ad altri tale conoscenza, ma ciò non dovrebbe far parte della sessione di revisione. Se ci sono problemi di prestazioni significative, non perché ha usato una variante meno efficiente di un tipo di elenco.

Poiché la domanda iniziale era perché alcune persone sembrano fare una recensione migliore come altre, risponderei che queste persone potrebbero fare un'anteprima prima dell'inizio della recensione reale, significa che probabilmente si sono preparati da soli in modo che sappiano esattamente cosa vogliono rivedere .

[H] come posso fare un lavoro migliore nell'esecuzione di una revisione del codice per qualcun altro?

Poni loro molte domande

So che per eseguire una revisione del codice è necessario conoscere il funzionamento del codice esistente ...

In realtà, no, non devi conoscere il codice in anticipo per essere un buon revisore.

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 principalmente lavorando alla GUI in C, e uno dei migliori revisori per me era il mio amico Bill. Era abile in C, ma non aveva mai fatto molto lavoro con la GUI e nelle recensioni non aveva idea di come avrebbe dovuto funzionare il mio codice.

Ma ha fatto molte domande al riguardo, e dovendo spiegare in modo da poter capire cosa facesse il mio codice e perché abbia stimolato molto a pensare da parte mia. Mi ha portato a trovare molti piccoli e strani bug con casi limite e anche a prendere in considerazione altri approcci che avrei potuto adottare. Inoltre, sebbene a quel punto scrivessi C da 22 anni e pensassi di essere abbastanza abile, ha rapidamente migliorato la qualità del mio codice.

Anche se non lavoro più lì, rivedo comunque le differenze prima del check-in e mi chiedo: "Quali domande avrebbe Bill su questo?" E abbastanza spesso, finisco per cambiare qualcosa di conseguenza.