Come è stata organizzata la procedura di revisione del codice nel tuo team?

Abbiamo utilizzato lo sviluppo collaborativo tramite il sistema di controllo versione Git e piattaforme di gestione dei repository (ad esempio, Bitbucket o GitLab). Il processo di revisione del codice è stato organizzato come segue:

1. Creazione del branch: Lo sviluppatore crea un branch separato per una nuova funzionalità o correzione di bug (git checkout -b feature/my-new-feature).
2. Sviluppo e commit: Vengono apportate modifiche nel branch, che vengono registrate tramite commit (git add ., git commit -m "Implementazione iniziale della funzionalità").
3. Push al repository remoto: Il branch viene inviato al repository remoto (git push origin feature/my-new-feature).
4. Creazione di Pull/Merge Request: Lo sviluppatore crea una Pull Request (su Bitbucket) o Merge Request (su GitLab), indicando il branch di destinazione (ad esempio, develop o main). Nella descrizione si include un riassunto delle modifiche, link alle attività nel tracker (Jira, Trello, ecc.) e file allegati (screenshot, video, diagrammi).
5. Assegnazione dei revisori: Uno o due sviluppatori del team vengono assegnati per effettuare la revisione.
6. Processo di revisione: I revisori esaminano le modifiche nella Pull/Merge Request. Possono lasciare commenti, proporre miglioramenti, fare domande.

   // Esempio di commento durante la revisione
   function fetchData() {
     // Potrebbe essere necessario aggiungere gestione degli errori qui
     return fetch('/api/data');
   }
   

7. Modifiche dopo la revisione: Lo sviluppatore apporta le modifiche necessarie sulla base dei commenti dei revisori e fa nuovi commit.
8. Aggiornamento della Pull/Merge Request: Le modifiche vengono visualizzate automaticamente nella Pull/Merge Request dopo il push al repository remoto.
9. Revisione ripetuta: I revisori rivedono nuovamente le modifiche e danno l'approvazione.
10. Merge del branch: Dopo aver ottenuto l'approvazione, il branch viene fuso nel branch di destinazione (solitamente in modo automatizzato dalla piattaforma dopo il passaggio attraverso il pipeline CI/CD).

Utilizziamo anche pipeline CI/CD per eseguire automaticamente test unitari, analisi statica del codice (ESLint, Prettier) e build del progetto prima del merge, aiutando a individuare errori nelle prime fasi.

I criteri per il successo della revisione includevano:

• Conformità ai requisiti del compito.
• Rispetto dello stile di codice del team.
• Presenza di test unitari per la logica critica.
• Assenza di errori evidenti e "workaround".
• Chiarezza del codice per gli altri membri del team.