Git 18
🔀 Git & GitHub · Modulo 3 · Lezione 18
Code Review 👀
Revisioni costruttive · Commenti inline · Suggerimenti di codice · Approvazione · La cultura del feedback
👀 La code review è la competenza che separa chi scrive codice da chi scrive codice professionale. Non è “trovare errori” — è un processo collaborativo in cui impari dal codice degli altri, condividi conoscenza e migliori la qualità del progetto. In questa lezione impari sia a dare review utili sia a ricevere feedback con maturità. È una competenza che userai per tutta la carriera.
🎯 Obiettivi della lezione
- Capire perché la code review è importante (non solo per trovare bug)
- Saper dare una review costruttiva su una Pull Request
- Usare commenti inline, suggerimenti di codice e thread di discussione
- Conoscere i 3 tipi di review: Comment, Approve, Request changes
- Saper ricevere feedback senza prenderla sul personale
- Conoscere le best practice del feedback tra pari
📖 1. Teoria
1.1 — Perché fare code review
La code review non è un esame — è un processo di miglioramento reciproco. Anche il programmatore più esperto del mondo ha i propri punti ciechi: cose che non nota, abitudini non ottimali, casi limite che non considera. Un secondo paio di occhi cattura ciò che il primo non vede.
1.2 — Come fare una review su GitHub
📌 “Start a review” vs “Add single comment”: quando clicchi il + e scrivi un commento, hai due opzioni. “Add single comment” pubblica il commento immediatamente — l’autore riceve una notifica per ogni singolo commento. “Start a review” accumula i commenti e li pubblica tutti insieme alla fine — l’autore riceve un’unica notifica con tutti i feedback. La seconda opzione è molto più educata e professionale.
1.3 — I 3 tipi di review
1.4 — Strumenti del reviewer su GitHub
| Strumento | Come si usa | Quando |
|---|---|---|
| Commento su una riga | Clicca il + accanto al numero di riga → scrivi il commento | Per feedback su un punto specifico del codice |
| Commento su più righe | Clicca il + e trascina per selezionare un range di righe | Per commentare un blocco intero (funzione, blocco if, ecc.) |
| Suggerimento di codice ⭐ | Nel commento, clicca l’icona ± o scrivi un blocco ```suggestion |
Quando vuoi proporre una modifica specifica — l’autore può applicarla con un click |
| “Viewed” checkbox | Spunta “Viewed” accanto a ogni file nella tab Files changed | Per tenere traccia di quali file hai già revisionato |
Il suggerimento di codice: la funzione più potente
Quando vuoi proporre una modifica specifica, non scrivere “cambia la riga X in Y” — usa il blocco suggestion. L’autore può applicare la modifica con un click, senza tornare nel terminale.
qui, perché il valore non viene
mai riassegnato:
“`suggestion
const total = price * quantity;
“`
const total = price * quantity;
1.5 — Come dare feedback costruttivo
Il modo in cui scrivi un commento è tanto importante quanto il contenuto. Un commento aggressivo o sprezzante demoralizza e crea conflitti. Un commento costruttivo insegna e motiva.
| ❌ Commento distruttivo | ✅ Commento costruttivo |
|---|---|
| “Questo codice è orribile.” | “Questa parte potrebbe essere semplificata — che ne dici di estrarre questa logica in una funzione?” |
| “Perché hai fatto così? Non ha senso.” | “Sono curioso della scelta di usare un for qui — un forEach o un map sarebbe più leggibile?” |
| “Sbagliato.” | “Attenzione: qui c’è un caso non gestito — se l’array è vuoto, la funzione restituisce undefined. Meglio aggiungere un check.” |
| “Dovresti saperlo.” | “Un suggerimento: in JavaScript, === è preferibile a == perché confronta anche il tipo. Ecco un link che spiega la differenza: …” |
| (nessun commento positivo) | “Mi piace come hai strutturato questa funzione — è molto leggibile!” |
[nit] per dettagli minori (“nit: spazio in più alla riga 15”) e [blocking] per problemi che impediscono il merge.1.6 — I prefissi convenzionali per i commenti
| Prefisso | Significato | Esempio |
|---|---|---|
| [blocking] | Problema serio — va risolto prima del merge | [blocking] Qui manca la gestione dell’errore. Se l’API non risponde, l’app crasha. |
| [suggestion] | Suggerimento di miglioramento — non bloccante | [suggestion] Potresti usare template literals invece della concatenazione. |
| [question] | Domanda per capire la scelta — non una critica | [question] Perché hai scelto setTimeout invece di setInterval qui? |
| [nit] | Dettaglio cosmetico / minore — ignorabile | [nit] Spazio in più alla riga 42. |
| [praise] | Apprezzamento — qualcosa fatto bene | [praise] Ottima idea separare la validazione in una funzione a parte! |
1.7 — Cosa cercare durante una review
Un reviewer non deve leggere ogni riga alla ricerca della perfezione. Ecco una checklist pratica di cosa controllare, in ordine di priorità:
1.8 — Come ricevere una review
Ricevere feedback sul proprio codice può essere difficile — è naturale sentirsi sulla difensiva. Ma la review riguarda il codice, non te. Ecco come gestirla con maturità.
“Non ho tempo per queste modifiche.”
“Il mio codice va bene così.”
Ignorare i commenti e fare merge comunque.
“Buon punto — ho scelto così perché X, ma il tuo approccio è migliore.”
“Non conoscevo questa sintassi, grazie!”
Rispondere a ogni commento, anche solo con “Fatto!”
💻 2. Esempi guidati
Esempio A — Una review completa su una PR scolastica
type="email" — senza, il browser non fa validazione nativa e su mobile non mostra la tastiera ottimizzata. Aggiungiamolo:”<input name=”email” type=”email” required>
var(--color-primary) per coerenza?”Esempio B — L’autore risponde e corregge
🏋️ 3. Esercizi
🟢 Esercizio 1 — Revisiona te stesso (Facile)
b) Vai alla tab “Files changed”.
c) Lascia almeno 3 commenti inline sul tuo stesso codice: un [praise] su qualcosa che hai fatto bene, un [suggestion] per un miglioramento, e un [nit] per un dettaglio minore.
d) Usa “Start a review” per raggruppare i commenti. Scrivi un commento generale e seleziona “Comment”.
e) Come ti sembra il tuo codice dopo averlo riletto con occhi da reviewer?
🔵 Esercizio 2 — Suggerimento di codice (Medio)
var (da cambiare in const o let) e un’operazione che potrebbe essere semplificata.b) Pusha e apri una PR.
c) Nella review, usa il blocco
```suggestion per proporre le modifiche. Crea almeno 2 suggerimenti di codice.d) Cambia ruolo: come autore, clicca “Commit suggestion” su ciascun suggerimento.
e) Verifica che i commit siano apparsi nella PR. Fai merge.
🟠 Esercizio 3 — Review incrociata con un compagno (Medio)
a) Ciascuno di voi crea un branch nel proprio repository con una piccola modifica (o file nuovo) e apre una PR.
b) Aggiungete l’altro come collaboratore del repository (Settings → Collaborators → Add people).
c) Ciascuno revisiona la PR dell’altro usando i prefissi [blocking], [suggestion], [nit], [praise].
d) Ciascuno risponde ai commenti ricevuti, corregge se necessario, e pusha.
e) Dopo la seconda review, approvate e fate merge. Discutete: cosa avete imparato dalla review dell’altro?
🟣 Esercizio 4 — Scrivi la guida di code review del tuo team (Difficile)
REVIEW_GUIDELINES.md nel tuo repository con le regole di code review del tuo team. Deve includere:a) Scopo della review: perché facciamo code review (2-3 frasi).
b) Checklist del reviewer: cosa controllare (con checkbox Markdown).
c) Prefissi dei commenti: tabella con [blocking], [suggestion], [nit], [praise].
d) Regole di comunicazione: come dare feedback costruttivo (almeno 3 punti).
e) Regole per l’autore: come ricevere e rispondere ai feedback (almeno 3 punti).
f) Tempi: entro quanto la review deve essere completata (es. “entro 24 ore dalla richiesta”).
g) Committa, pusha e condividi il link con il tuo team.
❓ 4. Quiz di verifica
1. Perché “Start a review” è meglio di “Add single comment”?
Mostra risposta
“Add single comment” pubblica ogni commento immediatamente — l’autore riceve una notifica per ciascuno, potenzialmente decine di email. “Start a review” raggruppa tutti i commenti e li pubblica insieme alla fine, quando clicchi “Submit review”. L’autore riceve un’unica notifica con tutti i feedback. Inoltre, solo con “Start a review” puoi scegliere il tipo di review (Approve, Comment, Request changes). È più professionale, meno invasivo e dà all’autore un quadro completo del feedback in una volta sola.
2. Qual è la differenza tra “Approve” e “Comment” come tipo di review?
Mostra risposta
“Approve” significa “il codice va bene, puoi fare merge” — è un via libera esplicito. “Comment” significa “ho delle osservazioni ma non esprimo un giudizio sul merge” — il commento non blocca né approva. “Request changes” è il terzo tipo: “servono modifiche prima del merge” — è un blocco esplicito. In pratica: usa “Approve” se sei soddisfatto, “Request changes” se ci sono problemi da correggere, e “Comment” per osservazioni generali senza prendere posizione.
3. Cosa significa il prefisso [nit] in un commento di review?
Mostra risposta
Viene da “nitpick” (cercare il pelo nell’uovo). Indica un dettaglio minore e cosmetico che non è bloccante — l’autore può correggere o ignorare. Esempi: uno spazio in più, una variabile che potrebbe avere un nome leggermente migliore, un commento mancante su una riga ovvia. I prefissi come [nit], [suggestion], [blocking] e [praise] aiutano l’autore a capire la gravità del commento senza doverla dedurre dal tono. Un commento con [nit] dice “è un dettaglio, non è obbligatorio correggerlo”.
4. Come funziona il blocco ```suggestion nei commenti di review?
Mostra risposta
Permette al reviewer di proporre una modifica specifica al codice direttamente nel commento. GitHub mostra la riga originale (barrata in rosso) e la versione proposta (in verde) con un pulsante “Commit suggestion”. L’autore può applicare la modifica con un singolo click — GitHub crea automaticamente un commit con quella modifica. È molto più efficiente che scrivere “cambia X in Y” e aspettare che l’autore lo faccia manualmente. Si possono anche raggruppare più suggerimenti in un singolo commit (“Batch suggestions”).
5. Un compagno ha commentato “Questo codice è orribile” sulla tua PR. Come reagisci?
Mostra risposta
Mantieni la calma e rispondi in modo professionale: “Puoi spiegarmi cosa miglioreresti? Sono aperto a suggerimenti specifici.” Il commento è distruttivo perché non offre nessun feedback utile — non dice cosa non va né come migliorare. Chiedendo dettagli specifici, trasformi una critica vuota in un’opportunità di dialogo costruttivo. Se il commento è ripetutamente aggressivo, puoi coinvolgere il prof o il team leader. La code review deve essere sempre rispettosa — un buon feedback critica il codice, non la persona.
6. Cosa dovresti controllare per prima cosa durante una code review?
Mostra risposta
Le cose critiche: bug e errori logici (il codice fa quello che dovrebbe?), problemi di sicurezza (dati sensibili esposti? input non sanificato?). Poi le cose importanti: leggibilità e architettura. Solo alla fine i dettagli minori come stile e formattazione. L’errore più comune è concentrarsi sui dettagli cosmetici (“spazio in più alla riga 42”) ignorando un bug logico. Un bravo reviewer ha una gerarchia: prima la correttezza, poi la leggibilità, infine lo stile.
📚 Riepilogo della lezione
- La code review trova bug, condivide conoscenza, mantiene coerenza
- Usa “Start a review” per raggruppare i commenti (non “Add single comment”)
- 3 tipi: Approve (via libera) · Comment (osservazioni) · Request changes (blocco)
- Il blocco
```suggestionpropone modifiche applicabili con un click - Prefissi: [blocking] [suggestion] [question] [nit] [praise]
- 5 regole feedback: codice non persona · spiega il perché · domande non imperativi · segnala il buono · distingui obbligatorio/opzionale
- Ricevere review: non è personale · rispondi a tutto · spiega se non sei d’accordo · impara da ogni commento
- Checklist review: bug e sicurezza → leggibilità e architettura → stile e dettagli
🎉 Congratulazioni! Hai completato il Modulo 3 — GitHub: le basi. Sai creare un account, autenticarti, fare push e pull, scrivere README professionali, gestire issue, aprire Pull Request e fare code review. Hai tutto ciò che serve per collaborare su GitHub. Dal prossimo modulo si sale di livello: fork, branch protection, GitHub Projects e molto altro.
Prossima lezione →
Lezione 19 — Fork e open source
Come contribuire ai progetti degli altri. Fork, branch, PR upstream.
Il workflow dell’open source contributor.
Corso Git & GitHub · Per studenti e insegnanti · Lezione 18 di 45