Asynchronous Non-solo Programming: code review

Nel post precedente abbiamo approfondito gli aspetti legati al Debito Tecnico e visti, brevemente, gli strumenti di analisi offerti da Visual Studio finalizzati al miglioramento della qualità del codice, omettendo volontariamente la funzionalità di Code Review che andremo qui ad esplorare.

Code Review consente ad un dev di chiedere, ad un altro membro del team, una revisione del proprio codice, andando ad estendere il concetto di Pair Programming o, estendendo lo scope, di Non-solo Programming.

Ma perché decidiamo di chiedere un audit del nostro codice? I motivi sono ovviamente diversi, e tra essi troviamo:

  • identificare codice scritto male o con potenziali (reali) bug;
  • condividere il know-how su quanto realizzato tra tutti i membri del Team;
  • condividere nuovo know-how semantico/sintattico;
  • ….

Nell’approccio Agile, XP in particolare, il Pair Programming è un sinonimo vero e proprio di lavoro a “4 mani”, prevedendo che 2 dev lavorino allo stesso calcolatore (a rotazione, master-slave, ecc..) al fine di ottenere quanto appena evidenziato. In realtà questo approccio “fisico” non sempre è apprezzato, in primis perché dipende molto dal rapporto interpersonale, soprattutto se la durata dell’attività si protrae per un periodo relativamente lungo. Inoltre, in progetti di medie/grandi dimensioni, è possibile che la review del codice sia demandata ad un gruppo di QA di supporto, che, chiaramente, ha un approccio totalmente differente (così come lo sono gli obiettivi) da quello dello sviluppo. Infine, il collega con cui vorremmo “condividere” il nostro codice potrebbe non essere disponibile nel momento in cui lo scriviamo.

In questi casi, ed altri, abbiamo bisogno di uno strumento che consenta di creare un Asynchronous Non-solo Programming, come la funzionalità di Code Review presente in Visual Studio (dalla versione 2012) grazie al supporto di TFS (sempre dalla versione 2012)/VSO con il relativo sistema di Work Item tracking e i due specifici Work Item: Code review request e Code review response.

Ma vediamo operativamente come utilizzare Code Review. Una volta completato il codice e ravvisata la necessità di una revisione, da Team Explorer di Visual Studio, selezioniamo “My Work” e da qui “Request Review”.

code review 1 code review 2

Start Code Review

code review 3

New Code Review

La finestra “New Code Review” (figura precedente) si presenta con quattro campi da compilare:

  • Name of one or more code reviewer, ovvero il Nome del Reviewer scelto da una drop list popolata con i nomi dei membri del team;
  • Code Review subject, l’Oggetto della richiesta di review;
  • Area Path, l’Area di riferimento;
  • Code Review Description, una breve descrizione della richiesta [opzionale].

più uno pre-compilato “Related Work Items” con i relativi Work Items di riferimento per il codice in essere, laddove ve ne siano.

Completato l’inserimento dei dati, non ci resta altro da fare che premere “Submit Request” e potremo verificare che la richiesta sia stata correttamente consegnata/assegnata verificandone la presenza nell’area “Code Reviews” sempre in “My Work”.

code review 4

Code Review Evidence

Ora la palla passa al nostro revisore che vedrà la richiesta nella propria “My Work”, potendone esplorare i dettagli. Inoltre, se ha configurato il relativo alert in TFS/VSO, sarà informato anche per email della richiesta stessa.

code review 5

Code Review viewed by Reviewer

Il revisore ha a disposizione una scheda (Code Review) con tutti i dettagli della richiesta e, nella parte inferiore, vengono evidenziati tutti i file modificati all’atto della richiesta. Selezionando i file è possibile sfruttare implicitamente gli strumenti di code compare per verificare le modifiche e aggiungere eventuali commenti.

code review 6

Code Compare and Comment

Una volta completata la revisione, il revisore chiude il task e il richiedente potrà vedere tutti i commenti/suggerimenti riportati.

code review 7

Code Review suggested info

Come abbiamo accennato, Code Review richiede il supporto diretto di TFS/VSO ed è quindi normale aspettarsi di poter consultare i Work Items annessi anche dalla relativa applicazione web.

code review 8

Code Review Response

E’ interessante evidenziare che, come best practice, è utile mettere in “shelve” il codice per il quale si richiede la review e, solo dopo la ricezione di quest’ultima ed aver apportato eventuali modifiche suggerite, procedere con il check-in.

Per fare ciò basta selezionare il tasto “Suspend” in “My Work”, mentre per riprendere basta seleziona “Switch”.

code review 9 code review 10

Suspend & Switch

agileiot logo  ac2 logodac dac dacdac dac psmii psmii safe cal1 less certazure fundamentals
mvp reconnect

Free Joomla templates by Ltheme