Nick Youngson - http://nyphotographic.com/

Quando ogni cosa che cercate di modificare deve essere revisionata da qualcuno prima che possa essere accettata è abbastanza ovvio che la figura del revisore diventa cruciale, se non altro perché rischia di diventare il collo di bottiglia di tutto il processo. A tal pro casca a fagiolo la domanda di Mr T. che chiede:

Ciao Mauro, avrei una domanda su PR e qualità del codice con GitHub: attualmente in azienda uno dei miei compiti è fare review delle pull request. Questa operazione riesco a farla sempre subito quando la PR viene aperta, quindi non ci sono periodi di attesa prima che la persona cominci a lavorare su nuove cose. Anzi spesso la facciamo insieme così revisioniamo insieme le cose da migliorare. Quando però il numero di PR cresce, perché aperte da più persone entra in gioco l’attesa della code review di una PR. Mi interessa capire, se vi capita, come gestiste questa cosa (ovvero generalmente è una operazione che fate subito?). Oltre a questo, lo sviluppatore che deve continuare il proprio lavoro e a cui magari gli serve ciò che ha sviluppato nel precedente branch feature, da cosa farà partire il prossimo branch? Voi generalmente come fate?

La risposta è articolata, ma cominciamo dalle cose base:

  • Se uno dei ruoli che una persona ricopre è quello di fare review, allora probabilmente ha senso che le review stiano in alto nella sua lista di priorità. Io ad esempio dedico un paio d’ore al giorno alle review, la prima ora della mattina e la prima del pomeriggio di solito. La finalità è quella di sbloccare il lavoro agli altri;
  • Aggiungiamo che se le PR sono abbastanza piccole, o piccole il giusto, ci vuole veramente poco a fare review e quindi non possono essere di certo un problema;
  • Ovvio che se la review arriva inaspettata allora sta in basso nella lista delle priorità, ed è giusto così, chi apre la PR deve sapere che se chiede lavoro extra non pianificato/concordato avrà vita difficile;
  • Inoltre se tutti sono coinvolti in un modo o nell’altro nel fare review, tutti diventano familiari con molte parti della codebase e quindi possono sempre di più fare review. È un circolo virtuoso a cui val la pena dedicare tempo e risorse.

Capita di dover aspettare? Certo che si, apri una PR e la review viene fatta 12 ore dopo, per noi è normalissimo. Del resto siamo anche sparpagliati su 17 time zone. Fa parte del gioco, siamo grandi e vaccinati e sapendo che tutti siamo impegnati facciamo in modo di avere altro da fare mentre siamo in attesa della review. Inevitabilmente paghiamo lo scotto del context switch, ma abbiamo deciso che nel nostro caso efficacia e collaborazione vengono prima dell’efficienza.

La seconda parte della domanda è altrettanto interessante:

Oltre a questo, lo sviluppatore che deve continuare il proprio lavoro e a cui magari gli serve ciò che ha sviluppato nel precedente branch feature, da cosa farà partire il prossimo branch? Voi generalmente come fate?

Ora, qui potremmo essere di fronte ad un problema di design o di processo, e quello descritto essere un sintomo. Se la PR è ben fatta i tempi di attesa devono essere brevi altrimenti significa che abbiamo un problema di congestione che va oltre la questione review. Quello a cui mi potrei trovare di fronte è un problema di design/processo, supponiamo di avere una nuova feature XYZ:

  • abbiamo una branch feature/xyz
  • nella branch ci sono 3 commit che compongono XYZ:
    • funzionalità A
    • funzionalità B
    • funzionalità C
  • la Pull Request è in attesa di review

Il team nell’attesa vuole andare avanti e per andare avanti con feature 123 ha bisogno del codice “funzionalità A” committato nella branch di cui sopra. GitFlow nasce esattamente per risolvere situazioni come questa:

  • una branch funzionalità A viene aperta da develop
  • contiene un solo commit funzionalità A
  • la Pull Request viene revisionata
  • e mergiata su develop

A questo punto feature/xyz può iniziare e anche feature/123 può partire in parallelo, develop è il bandolo della matassa: develop è sempre rilasciabile come beta. develop + funzionalità A è rilasciabile? certo, essendo una beta è accettabile che funzionalità A, se visibile/fruibile sia poco utile. È funzionale a sbloccare altre parti. In uno scenario come questo quindi la necessità di avere review fluide aiuta a strutturare il progetto e il codice in funziona anche di quello, con tutti i vantaggi che ne conseguono.

Spero che Mr. T. sia soddisfatto ;-)

Credits: Review Image - Nick Youngson - http://nyphotographic.com/