La revisione del codice è uno dei momenti più preziosi nel lavoro di un team di sviluppo, e anche uno dei più fraintesi. Fatta male diventa un rito burocratico, in cui si approva senza leggere, oppure una gara a chi trova più difetti nel lavoro altrui. Fatta bene, invece, diffonde la conoscenza del codice, intercetta errori prima che arrivino agli utenti e alza gradualmente il livello di tutti.
A cosa serve davvero
Molti pensano che la code review serva soprattutto a trovare bug. In parte è vero, ma i benefici più importanti sono altri:
- condivisione della conoscenza: almeno due persone conoscono ogni parte del sistema;
- coerenza: il codice segue convenzioni comuni e resta comprensibile;
- progettazione: un secondo sguardo individua soluzioni più semplici o problemi di struttura;
- apprendimento reciproco: chi rivede impara dal codice altrui tanto quanto chi viene rivisto.
Tenere presente questi obiettivi cambia il tono della revisione: non si cerca un colpevole, si migliora insieme un prodotto.
Piccolo è meglio
Il fattore che più influenza la qualità di una revisione è la dimensione della modifica. Davanti a cinquanta righe un revisore legge con attenzione ogni dettaglio; davanti a duemila righe scorre, si stanca e approva. Chi scrive il codice ha quindi una responsabilità precisa: preparare modifiche piccole e coerenti.
Alcune pratiche aiutano:
- separare il refactoring dalle modifiche di comportamento, in due richieste distinte;
- dividere una funzione grande in passi integrabili uno alla volta;
- scrivere una descrizione chiara: cosa cambia, perché, come è stato verificato;
- rileggere il proprio diff prima di chiedere la revisione, eliminando codice di debug e modifiche accidentali.
Cosa controllare, in ordine di importanza
Non tutti i commenti hanno lo stesso valore. Un ordine utile:
| Priorità | Domanda | Esempio |
|---|---|---|
| 1 | Fa ciò che deve fare? | Il calcolo gestisce un carrello vuoto? |
| 2 | È sicuro? | L'input dell'utente viene validato prima dell'uso? |
| 3 | È progettato in modo sensato? | Questa logica appartiene davvero a questo modulo? |
| 4 | È testato? | I test coprono i casi limite e gli errori? |
| 5 | È leggibile? | I nomi spiegano l'intenzione? |
| 6 | Rispetta lo stile? | Indentazione, convenzioni di formattazione |
L'ultima voce merita una considerazione a parte: lo stile va delegato alle macchine. Formattatori automatici e linter eseguiti nella pipeline eliminano intere categorie di commenti ripetitivi e lasciano ai revisori umani le questioni che richiedono giudizio.
Come scrivere commenti costruttivi
Il modo in cui un commento è scritto conta quanto il suo contenuto. Alcune regole pratiche:
- Commenta il codice, non la persona. «Questa funzione fa tre cose diverse» invece di «Hai scritto una funzione confusa».
- Spiega il perché. «Meglio usare una transazione qui: se il secondo inserimento fallisce, il primo resta orfano» è utile; «Usa una transazione» lo è meno.
- Distingui il bloccante dal facoltativo. Molti team usano prefissi come «nit:» per i dettagli minori, così l'autore sa cosa deve cambiare e cosa può valutare.
- Fai domande quando non sei sicuro. «Cosa succede se la lista è vuota?» invita a ragionare e a volte rivela che il caso è già gestito.
- Riconosci le cose fatte bene. Una soluzione elegante merita di essere notata: rinforza le buone pratiche.
Il ruolo dell'autore
Ricevere una revisione richiede altrettanta maturità. Un commento sul codice non è un giudizio sul proprio valore. Se un revisore ha frainteso qualcosa, probabilmente lo fraintenderà anche il prossimo lettore: è un segnale che serve un nome migliore o un commento. Quando non si è d'accordo, si argomenta con fatti ed esempi; se la discussione si allunga, una breve chiamata risolve spesso più di dieci messaggi.
Tempi e abitudini del team
Una revisione che arriva dopo tre giorni blocca il lavoro e incoraggia richieste sempre più grandi. Molti team si danno un obiettivo semplice: prima risposta entro la stessa giornata lavorativa. Altre abitudini utili:
- ruotare i revisori, per evitare che la conoscenza si concentri su una sola persona;
- usare una checklist breve per gli aspetti che si dimenticano spesso, come migrazioni del database o variabili di configurazione;
- non approvare ciò che non si è capito: chiedere spiegazioni è parte del lavoro.
Cosa la review non può fare
La revisione umana non sostituisce i test automatici, l'analisi statica o i controlli di sicurezza. Un revisore attento può notare una vulnerabilità evidente, ma non può verificare a mente tutti i percorsi di esecuzione. La code review funziona meglio come ultimo livello di un sistema che ha già filtrato gli errori meccanici.
In sintesi
- La code review serve soprattutto a condividere conoscenza e migliorare il progetto, non solo a trovare bug.
- Modifiche piccole e ben descritte producono revisioni migliori.
- Controlla prima correttezza, sicurezza e progettazione; lascia lo stile agli strumenti automatici.
- Commenta il codice e non la persona, spiega il perché e distingui ciò che è bloccante.
- Rispondi in tempi brevi: le revisioni lente generano richieste sempre più grandi.
