Come gestiamo le PR Review nel nostro team

Come abbiamo strutturato il processo di Pull Request Review per migliorare qualità e collaborazione. Un approccio concreto che oggi funziona per noi.

Nello sviluppo di un’applicazione web arriva sempre il momento in cui una modifica deve andare in produzione: che sia una nuova funzionalità, una patch per correggere un bug o un intervento di manutenzione, si tratta sempre di cambiare il codice.
Quando si lavora in team, però, la vera sfida non è solo “scrivere codice che funziona”, ma scrivere codice chiaro, manutenibile e coerente con gli standard comuni.
E qui entra in gioco la Pull Request Review (PR Review), una pratica che, se fatta bene, migliora la qualità del prodotto e fa crescere il team.

Cos’è una PR Review (e perché è fondamentale)

La PR Review è il momento in cui lo sviluppatore presenta al resto del team:

• le modifiche effettuate;
• le motivazioni dietro le scelte tecniche;
• e raccoglie feedback in base agli standard di qualità condivisi;

Ha due obiettivi principali:

1. Migliorare la qualità del codice prima della pubblicazione (deploy);
2. Favorire la condivisione della conoscenza tra i membri del team;

Come abbiamo organizzato le nostre PR Review

Negli anni, abbiamo affinato un processo che ci permette di mantenere alta la qualità senza rallentare troppo lo sviluppo.

1️⃣ Slicing: meno file, revisioni più rapide

In passato, una singola PR poteva toccare 60 o più file. Risultato? Revisioni lente, pesanti e spesso rimandate.

Per risolvere, abbiamo introdotto il concetto di slicing: suddividere ogni funzionalità in sottoinsiemi rilasciabili anche separatamente.

Nel nostro team capita che il rilascio dell’intera funzionalità sia programmato per una data specifica. In questi casi, per non lasciare gli slice “parcheggiati” in attesa, li rilasciamo comunque sotto Feature Flag: restano nascosti all’interno dell’applicazione e li attiviamo tutti insieme con un click quando serve.
Questo approccio ci permette di adottare una logica di continuous delivery, con deploy frequenti in produzione.

È fondamentale coinvolgere anche Project Manager e Product Owner nella definizione del perimetro delle modifiche: avere limiti chiari aiuta a mantenere le PR snelle.
Grazie a questa pratica, il numero di file modificati si è ridotto notevolmente. Non abbiamo un limite rigido, ma in media riusciamo a stare sotto i 25/30 file: meno sono, meglio è.

Personalmente mi torna utile usare le PR in bozza (Draft) di GitHub, cosi da avere un’anteprima delle modifiche e, se trovo cambiamenti eccessivi o superflui, faccio un revert per riportare il file allo stato originale, minimizzando così il numero di modifiche.

2️⃣ Divisione per tipologia: Sync e Async

Non tutte le PR sono uguali. Noi le dividiamo in due categorie:

• Sync: richiedono un meeting con il team e includono una piccola demo visiva del risultato. Ideali per nuove funzionalità o modifiche importanti.
• Async: revisionabili in autonomia, senza meeting. Perfette per bug fix e piccoli refactoring.

3️⃣ Automazioni: Slack come centro notifiche

Abbiamo creato uno script che invia su Slack la lista delle PR da revisionare. Per le Sync, lo script segnala anche:

• il revisore designato (scelto a caso);
• il link al meeting;
  

Inoltre, abbiamo fissato due giornate a settimana dedicate alle Sync, per non sovraccaricare il team.

4️⃣ La revisione vera e propria

Durante una Sync:

1. Tutto il team partecipa;
2. Lo sviluppatore illustra le modifiche mentre il revisore scorre la PR;
3. Le correzioni vengono annotate come commenti;
4. Il merge è bloccato finché almeno due membri non approvano;

Questo assicura qualità e controllo incrociato, evitando scorciatoie pericolose.

Conclusione

Il processo funziona bene, ma cerchiamo sempre margini di miglioramento: nel web, nulla è immutabile.
È vero: la PR Review rallenta la messa in produzione e questo può sembrare un lusso in una startup dove la velocità è spesso prioritaria.
Ma quando il progetto diventa maturo, questa pratica diventa un investimento a lungo termine: migliora la qualità, riduce i bug, aumenta la condivisione interna.

Noi oggi non potremmo più farne a meno.