Recentemente, nel corso di una retrospettiva, abbiamo individuato nella gestione delle cosiddette Merge Request (MR) [1] un punto debole all’interno del nostro team.
Ci siamo così posti cinque quesiti fondamentali su questo tema, e abbiamo individuato altrettante risposte che possono servire come spunto di riflessione per tutti i team.
Buona lettura.
1. Quando posso creare una Merge Request?
Ogni team dovrebbe stilare una propria Definition of Done [2], ossia un elenco di attività che devono essere portate a termine prima di poter considerare conclusa una User Story. La creazione di una MR è solo una di queste attività, ed è importante che siano chiari ad ogni sviluppatore tutti i requisiti che devono essere necessariamente soddisfatti prima di questo passo. Ovviamente questa lista non è fissa, anzi, è consigliabile adottare un approccio incrementale ed introdurre nel corso del tempo nuovi vincoli o rendere più stringenti quelli esistenti.
Nel nostro caso, ad esempio, abbiamo ritenuto opportuno aggiungere le fasi di deploy e test della nuova funzionalità su uno degli ambienti di sviluppo condivisi.
2. Come creo una Merge Request?
Ogni sviluppatore fa parte di un team e come tale deve facilitare il più possibile il lavoro dei propri colleghi. Se da un lato è sempre possibile (e in alcuni casi opportuno) confrontarsi direttamente con l’autore della MR, dall’altro è bene che chiunque sia in grado di analizzare autonomamente piccole modifiche.
A tal scopo abbiamo stabilito che ogni MR debba necessariamente includere:
- L’identificativo della User Story cui la MR fa riferimento, così da permettere al revisore di verificare i requisiti funzionali.
- Una breve descrizione, per chiarire ulteriormente alcuni aspetti o le scelte tecniche fatte.
3. A chi devo assegnare una Merge Request?
Ogni sviluppatore è istintivamente portato ad assegnare una MR ad una persona che conosce bene la funzionalità che è stata appena sviluppata, ci siamo però chiesti se questa fosse effettivamente la cosa più corretta da fare. La verità è che le MR sono anche un valido strumento per condividere la conoscenza all’interno di un team e quindi, spesso, può essere utile scegliere una persona diversa, con una conoscenza più limitata del lavoro che abbiamo svolto. I benefici di questo approccio sul medio e lungo periodo probabilmente superano di gran lunga le inefficienze che si possono riscontrare nell’immediato.
È altresì opportuno che una persona con poca esperienza (o che è appena entrata a far parte di un team) ricontrolli il lavoro di uno sviluppatore senior, in quanto la lettura del codice è sicuramente uno dei metodi più efficaci per migliorare.
In caso di modifiche particolarmente complesse, poi, è bene estendere la revisione del codice anche a più di una persona.
4. Quando devo controllare una Merge Request?
In questo caso abbiamo registrato due esigenze opposte:
- Chi crea una MR vorrebbe che fosse analizzata e chiusa in breve tempo, in modo da potersi poi concentrare su un’altra funzionalità.
- Chi deve occuparsi di ricontrollare il codice tende a rimandare per non interrompere il lavoro che sta svolgendo.
Come tutti ben sappiamo, infatti, i continui cambi di contesto riducono la produttività e possono generare un senso di frustrazione.
Abbiamo quindi scelto di fissare due momenti precisi all’interno della giornata in cui ogni sviluppatore ha il compito di verificare eventuali MR che gli sono state assegnate: al mattino, dopo il Daily Scrum [3], e subito dopo la pausa pranzo.
Questa soluzione presenta diversi vantaggi:
- E’ garantito che una MR verrà analizzata dopo al più mezza giornata di lavoro.
- I cambi di contesto sono ridotti al minimo, in quanto ogni sviluppatore si dedica a tale attività prima di riprendere il proprio lavoro.
- L’autore e il revisore della MR possono approfittare di questi slot di tempo prestabiliti e comuni a tutti per confrontarsi direttamente su quanto è stato fatto.
5. Come verifico una Merge Request?
All’interno del nostro progetto utilizziamo GitLab [4] come gestore di repository e, almeno inizialmente, ci è sembrato naturale sfruttarlo anche per la revisione del codice. Quando si crea una MR, infatti, il revisore ha a disposizione una pagina che riepiloga tutte le modifiche fatte, l’elenco dei commit ecc. Pur essendo uno strumento ben fatto, con il tempo sono emersi alcuni limiti che ci hanno spinto a cercare un’alternativa più in linea con le nostre esigenze.
Recentemente abbiamo pertanto iniziato ad utilizzare il plugin per IntelliJ Merge Request Integration EE [5], e questa scelta si è rivelata ottima sotto molti punti di vista.
Anzitutto, trattandosi di uno strumento integrato all’interno dell’IDE, ci permette di sfruttare funzionalità aggiuntive quali ad esempio una migliore visualizzazione side-by-side delle modifiche, l’analisi del codice, ecc.
In secondo luogo, GitLab si focalizza esclusivamente sulle modifiche fatte, mentre chi analizza una MR dovrebbe avere una visione più ampia, e non concentrarsi esclusivamente sui dettagli. Una nuova classe, ad esempio, potrebbe essere perfettamente valida se presa singolarmente, ma all’interno del progetto nel suo complesso potrebbe presentare una porzione di codice duplicato o più genericamente non essere in linea con la struttura condivisa dal team. Lavorare direttamente in un ambiente di sviluppo ci permette quindi di capire anche come le modifiche vanno ad inserirsi in un contesto più generale.