Cultura del code review e buone pratiche per le PR

La revisione del codice non serve a fare da filtro: è il modo in cui i team imparano insieme, trasferiscono la responsabilità e mantengono alta la qualità. Una buona cultura della revisione fa crescere l'intero team; una cattiva cultura crea colli di bottiglia e risentimento.

1) La mantenga piccola (se possibile, sotto le 400 righe). 2) Scriva una descrizione chiara: perché, che cosa e come eseguire i test. 3) Colleghi il ticket. 4) Aggiunga screenshot o video per le modifiche all'interfaccia. 5) Riveda autonomamente il diff prima di richiedere la revisione.

Usi gli stessi prefissi convenzionali dei commit: feat: add user profile page, fix: handle 404 in fetch wrapper, refactor: extract Avatar component. Molti team generano i changelog a partire da questi prefissi.

La maggior parte dei team usa un template per le PR: lo installi in .github/pull_request_template.md.

Prima di richiedere la revisione, esamini il Suo diff riga per riga. Aggiunga commenti per spiegare le scelte non ovvie. Spesso individuerà i propri bug prima che debba farlo qualcun altro.

Una PR di 2000 righe raramente viene sottoposta a una revisione approfondita. La divida in: 1) refactoring (nessuna modifica al comportamento), 2) nuovo comportamento, 3) rifinitura dell'interfaccia. Ciascuna parte sarà più facile da revisionare e da annullare.

Formuli i commenti come domande, non come ordini: 'Che cosa ne pensa di estrarre questo in un hook?' è meglio di 'estragga questo'. Distingua ciò che va corretto obbligatoriamente da ciò che sarebbe solo preferibile. Usi i prefissi: nit:, question:, blocker:.

'Questo crea confusione' non dice nulla all'autore. 'Ho dovuto leggere questo codice tre volte per capire il ritorno anticipato: potremmo estrarre una guard clause?' gli offre invece un'indicazione concreta su cui agire.

Commenti positivamente le soluzioni ingegnose, i nomi appropriati e i test utili. In questo modo incoraggerà questi pattern e renderà più accettabile il resto del feedback. Le PR che ricevono solo critiche fanno percepire la revisione come un confronto ostile.

Prettier gestisce la formattazione. ESLint gestisce lo stile. Non sprechi cicli di revisione discutendo di tabulazioni e spazi. Se una regola di stile torna continuamente, la codifichi nel linter.

Anche i test sono codice. Si assicuri che il nuovo codice abbia dei test. Verifichi che i test esercitino davvero l'elemento corretto: molti test superano l'esecuzione anche quando il codice è errato, perché verificano l'elemento sbagliato.

Risponda a ogni commento, anche solo con un'emoji con il pollice in su. Contesti i suggerimenti con cui non è d'accordo: è Lei ad aver scritto il codice e potrebbe avere un contesto aggiuntivo. Contrassegni come risolti i thread risolti. Aggiorni la descrizione della PR se l'ambito cambia.

Esegua la revisione entro un giorno lavorativo. Le PR lasciate ferme perdono il contesto: l'autore è andato avanti e il branch deve essere riallineato. Le PR grandi che restano ferme per una settimana si trasformano sempre in merge infernali.

La funzione dei suggerimenti di GitHub permette all'autore di accettare una correzione con un solo clic. È molto più veloce che scrivere in prosa 'cambi questa riga in X'.

Approvi quando: il codice è corretto, i test superano l'esecuzione, comprende la modifica ed è sicuro eseguire il merge. Approvare significa condividere la responsabilità del risultato. Non approvi senza esaminare: se non ha letto il codice, lo dica.

Autore: PR piccole e ben descritte, con screenshot e test. Prima esegua la revisione autonoma. Revisore: feedback costruttivo, formulato come domande. Distingua i blocker dai nit. Valorizzi gli aspetti positivi. Ignori lo stile: lasci che se ne occupino gli strumenti. Esegua la revisione entro un giorno. Approvi solo quando comprende la modifica. I template per le PR rendono il processo uniforme. Le revisioni sono collaborazione, non un filtro.