Revisioni efficaci del codice

Le revisioni del codice sono una parte essenziale di qualsiasi team di sviluppo software, ti aiuta a ridurre le possibilità di avere codice difettoso.

Io stesso eseguo revisioni del codice da più di 6 anni e in quel periodo ho esaminato più di 600 richieste pull. Ora sto scrivendo questo post per condividere le mie conoscenze, con la speranza che possa aiutare sia il revisore che il revisore.

Prima di addentrarci nella tana del coniglio su cosa e cosa non fare durante le revisioni del codice, voglio sottolineare l'importanza delle revisioni del codice.

Le persone di solito pensano alle revisioni del codice come a un compito umile che aumenta solo il tempo tra "Dev Done" e "Ready for QA". L'affermazione di cui sopra è "vera" quando le revisioni del Codice vengono effettuate " non con le giuste intenzioni ".

Ecco alcuni scenari che si aggregano alla revisione del codice in corso ma che non aiutano nessuno:

1. Il revisore esegue la revisione del codice solo per il gusto di farlo. Sta approvando le richieste senza guardarle o semplicemente scorrendole una volta.
   Questo tipo di revisori viene presto etichettato come revisori facili e viene quindi preso di mira per ottenere il codice più velocemente.
2. Il revisore esegue la revisione del codice senza comprendere i requisiti dell'attività
3. Il revisore aggiunge commenti senza l'effettivo ragionamento alla base del motivo per cui è necessaria la modifica
4. Il revisore controlla solo la sintassi e non la logica effettiva.
   Se un recensore pensa che il recensore ne sappia più di lui, è inevitabile che ciò accada.
5. Il revisore non sta cercando di capire il ragionamento alla base di un commento. Quindi o sta solo seguendo ciecamente i commenti o li ignora

Perché dovrei rivedere il codice di qualcun altro?
Si potrebbe pensare che non ci siano vantaggi nel rivedere il codice di un'altra persona in quanto potrebbero credere che non stanno imparando nulla di nuovo. Anzi-

1. I revisori ottengono una comprensione delle attività in corso all'interno del team.
2. Imparano a conoscere i servizi che esistono all'interno del sistema. Che migliora la riusabilità
3. Imparano nuova sintassi o modi di codificare e fare cose

Tuttavia, elencherei ancora alcune cose che le persone di solito mancano quando eseguono le revisioni del codice.

Linee guida generali

1. Particolare attenzione dovrebbe essere prestata alla "leggibilità del codice" e alla "riusabilità del codice".
   I nomi delle variabili e delle funzioni sono descrittivi e significativi. Nomi come i, anon dovrebbero essere usati.
2. Il codice non dovrebbe essere ridondante (strumenti di qualità del codice come "sonarlint" sono molto utili in questi casi)
3. I casi di unit test sono un must per le funzioni di utilità
4. Il lavoro di ciascuna funzione dovrebbe essere chiaramente definito e dovrebbe seguire il principio della responsabilità unica
5. Controlla i livelli di registro. Il contenuto del registro dovrebbe avere informazioni fruibili
   Qualcosa come — "errore ricevuto dalla cache" non ha alcuna informazione fruibile
6. Dovremmo disporre di metriche in atto ovunque richiesto
7. Controlla se il processo (registrazione, chiamate esterne, database, cache) deve essere sincronizzato o asincrono
8. Le persone di solito non prestano molta attenzione ai casi di test unitari. Occorre pensare se tutti gli scenari sono coperti o meno
9. Per una funzionalità cruciale che potrebbe influire sul percorso dell'utente, si dovrebbe sempre disporre di un fallback per tornare al flusso precedente
10. Il revisore dovrebbe cercare di suddividere le modifiche in più componenti più piccoli e creare richieste pull per esse in modo indipendente e il prima possibile. Questo non solo concede al revisore più tempo, ma assicura anche che i problemi (se presenti) o gli scenari limite vengano rilevati in anticipo
11. Non fidarti di nessuno. Poni domande su tutto. A volte, se ci fidiamo dell'autore, non scaviamo a fondo nel suo codice.
12. Il revisore deve rileggere la sua richiesta pull almeno una volta prima di condividerla per la revisione. Ciò garantisce che le cose di base come: codice commentato, TODO in sospeso, modifiche agli spazi bianchi, ecc. vengano corrette anche prima di condividere il PR
13. Controlla i rami di origine e di destinazione, se sono corretti o meno.

1. Se la chiamata esterna è altamente accoppiata o meno (altamente accoppiata significa: un errore nella chiamata esterna causerà un errore in questo flusso)
2. Timeout e meccanismi di ripetizione
3. Requisiti di campionamento e limitazione della velocità
4. Metriche per le chiamate esterne (latenza, percentuale di successo)

1. Controlla il TTL predefinito e la logica di aggiornamento della cache
2. Dovremmo anche stimare il numero di nuove voci e la percentuale di riscontri nella cache quando si aggiunge una cache
3. Cosa succede in caso di errore dalla cache
4. In caso di un nuovo cluster di cache, se esiste connettività dal server all'istanza della cache
5. Metriche per la percentuale di riscontri nella cache
6. Una stima del numero di chiavi della cache, la dimensione media del valore e assicurarsi che Infra abbia una capacità sufficiente.

1. Verificare se nel DB è presente un indice corretto per la nuova query
2. In caso di un nuovo database, indipendentemente dal fatto che la connettività esista o meno
3. Policy di purging delle tabelle, per evitare tabelle di grandi dimensioni nel tempo, in caso di inserimenti di dati
4. Metriche per le nuove query

1. Rimuovi le modifiche agli spazi bianchi dalla richiesta pull
   Come? Puoi fare riferimento a questo
2. Se non sono a conoscenza del requisito, di solito controllo l'attività o mi sincronizzo con lo sviluppatore una volta per comprendere il requisito
3. Apri Pull Request su GitHub/BitBucket e Local Code Editor contemporaneamente.
   Avere il codice localmente ha molteplici vantaggi:
   - Puoi utilizzare strumenti di scansione del codice statico per trovare alcuni dei problemi più comuni
   - La navigazione nel codice è molto più semplice
   - Se necessario, puoi eseguire il codice per vedere come si comporta
4. Inizia dal punto in cui il flusso aziendale è influenzato e poi passa attraverso il codice da lì. Ogni volta che mi sposto su un file diverso, controlla se quel file è cambiato o meno nella richiesta Pull su Github.
5. In caso di problemi, aggiungi quel commento in GitHub menzionando cosa deve essere cambiato e perché? Insieme ad alcuni materiali di riferimento
6. Nel caso in cui tu abbia finito di rivedere un file, contrassegnalo come visualizzato, in modo da ottenere anche chiarezza sull'avanzamento della revisione e inoltre, puoi evitare il file durante la seconda revisione del codice (se non ci sono modifiche )
7. Se i cambiamenti nella differenza sono piccoli, li rivedo in una volta sola. Altrimenti, divido la recensione in piccole fasi. Ciò garantisce che la qualità della recensione non ne risenta. Generalmente ciò che accade è che, se la differenza è grande, dopo un certo punto, iniziamo ad accettare le modifiche senza pensarci troppo

Spero che ci sia stata almeno una cosa che hai imparato da questo. Se sì, vota e menziona anche i punti che potrei aver perso. Li aggiungerò anche al post.

Saluti e Buona Revisione!