Agile Life

novembre 2014 - Post

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

Ridurre il Debito Tecnico un’Intenzionale con gli strumenti di Quality Management di Visual Studio

Abbiamo parlato più volte di Technical Debt all’interno dei nostri post, evidenziando come, se non gestito correttamente, possa portare in extremis alla necessità di riscrivere completamente un sistema software (Critical Mass of Software System: quando la qualità del software significa manutenibilità). Nel post “ALM, un approccio pratico alla gestione del Debito Tecnico” abbiamo anche visto come utilizzare una Clean Technical Debt Iteration (CTDi) tracciata in VSO/TFS per gestire e ridurre il debito tecnico accumulato.

E’ giunto ora il momento di vedere come essere proattivi, mettendo in campo quanto possibile per evitare la creazione del debito tecnico e ridurre gli interessi da pagare. Prima di vedere gli strumenti disponibili è utile soffermarci sulla terminologia, proponendo la tassonomia riportata nella figura seguente. 

technical debt taxonomy

Technical Debt Taxonomy

Esiste una verità difficilmente confutabile: per quanto vogliamo evitarlo, il nostro progetto avrà sempre un debito tecnico! Chiaramente, in questo caso, siamo nel campo dell’Unintentional Debt (Type 1), che è dettagliabile in due specifiche tipologie:

  • 1.A Naive Debt: questo debito deriva da cattive pratiche di sviluppo ed è quello su cui è possibile intervenire con maggior successo. Si pensi, ad esempio, ad un Team che non fa testing: un buon seminario su xUnit e l’utilizzo (eventuale e con parsimonia) del Gated check-in darà risultati lodevoli;
  • 1.B Unavoidable Debt: si tratta di debito ereditato su cui è difficile intervenire. Un esempio per tutti: una libreria sviluppata esternamente e utilizzabile solo as-is.

Dualmente all’Unintentional Debt è possibile identificare un “debito voluto” che indicheremo come Intentional Debt. Si tratta di una scelta dettata spesso da esigenze inderogabili e quasi sempre non tecniche, ad esempio: il Time-to-Market. Le afferenti tipologie di debito sono:

  • 2.A Short-term Debt, a sua volta diviso in:
    • 2.A.1 Identifiable significant shortcuts, ovvero il debito specificamente creato/accettato per raggiungere obiettivi strategici tramite tattiche di medio/breve termine. Si pensi alla necessità di procedere in parallelo sullo sviluppo e all’utilizzo temporaneo di fake library per realizzare una versione di supporto temporanea per il modulo che si sta realizzando, in attesa che quello definitivo sia ultimato;
    • 2.A.2 Identifiable tiny shortcuts, questo debito è assolutamente da evitare perché, nonostante sia creato per raggiungere uno specifico obiettivo di Program Level, ha degli altissimi costi di interesse, essendo sparso a macchia di leopardo. Esempi specifici sono: codice scritto frettolosamente, scarsa strutturazione del modello di dominio, ecc...
  • 2.B Long- term Debt, questo debito è legato ad obiettivi strategici di lungo/medio termine, supportati da una specifica visione. Rientra in questo ambito, ad esempio, la scelta voluta di creare una soluzione per uno specifico ambiente di erogazione anche se la relativa nuova versione è in fase di rilascio e potrebbe non essere correttamente supportata.

Nella tassonomia che abbiamo presentato, è presente anche il Non-Debt che non va interpretato come l’assenza di debito tecnico, piuttosto è da intendersi come classificazione di specifiche attività che avvengo durante il ciclo di delivery. Prendiamo la decisione di posticipare lo sviluppo di una Feature alla successiva release: questo non crea un “debito tecnico”, sia nel caso in cui la scelta è frutto di una discussione con il key-stakeholder, sia che lo sia unilateralmente (in tale scenario il prodotto manca di una funzionalità nel suo insieme ma non è stato aggiunto o creato debito tecnico afferente).

Proseguiamo rispondendo ora alla domanda fondamentale: quando e come pagare gli interessi associati al debito tecnico?

Qui il dualismo con il “debito finanziario” è decisamente più sfumato, perché non sempre è necessario pagare il debito tecnico: se si è in presenza di un software che sta per raggiungere la fine del suo naturale ciclo di adozione, non ha alcun senso investire su di esso e, quindi, pagare il debito tecnico accumulato.

Se, invece, ciò è necessario, è possibile adottare diverse tecniche: da quella citata all’inizio dell’articolo, e spiegata nel post specifico, piuttosto che il pagamento alla successiva iterazione con l’inserimento nell’Iteration Backlog dei Work Item relativi. Ogni azienda ed ogni Team hanno un approccio specifico, esattamente come ogni azienda gestisce in modo proprio il debito finanziario.

Come evidenziato, l’ambito 1.A è quello in cui è possibile intervenire in maniera più efficace. In particolare, Visual Studio 2013 mette a disposizione tutta una serie di strumenti pensati proprio per aumentare la qualità della propria soluzione:

  • Code Analysis, consente di verificare l’aderenza del codice alle regole e best practice selezionate;
  • Code Metrics, consente di analizzare il codice alla ricerca delle aree di maggior complessità e di difficile manutenzione;
  • Code Clone Analysis, consente di ricercare il codice clonato/simile, anche parziale, indipendentemente da alcuni aspetti caratterizzati (es: nome variabile). Molto utile per in caso di utilizzo intensivo di copia e incolla… ogni commento è superfluo, ovviamente!
  • CodeLens, introdotto con Visual Studio 2013, consente di visualizzare direttamente sul codice corrente informazioni relative (es: test superati, riferimenti diretti da/a, ecc…). Più che una funzionalità di analisi è da ritenersi una facility che aiuta a concentrarsi sul lavoro in corso ed evita errori dovuti a switch di finestre/ambienti;
  • xUnit Text, Visual Studio 2013 ha introdotto un nuovo sistema di gestione degli Unit Test che consente di selezionare il framework di testing più adatto alle proprie esigenze (tramite Adapter) ed utilizzarlo in modo nativo.

Ovviamente a queste funzionalità, utilizzabili direttamente da Visual Studio (2013), si aggiungono tutte quelle tipiche di un processo evoluto di ALM legate a VSO/TFS.

code analysis

Code Analysis

code metrics

Code Metrics

code clone analysis

Code Clone Analysis

codelens

CodeLens

Rimuovere Work Items dal Product Backlog e… da VSO

Dopo aver evidenziato più volte la necessità di gestire opportunamente il Product Backlog ed evitare di stimare troppi Work Itemper non sprecare risorse preziosi (waste), siamo pronti ad “accogliere il cambiamento” e rimuovere i Work Item che, con l’aumento di know-how sul progetto e la relativa evoluzione, si dimostrano inutili o non necessari.

Se tale operazione è relativamente banale con l’utilizzo di strumenti “fisici”, come post-it e flip-board, lo stesso non si può dire con VisualStudioOnline (o TFS), che non contempla una funzione diretta da Web Interface per la rimozione di uno o più Work Item. In linea di massima questo è un bene, perché l’operazione di eliminazione è definitiva ma, soprattutto, perché porta alla perdita di importanti informazioni per il Team: numero di Work Item errati, domini su cui intervenire per colmare lacune, ecc…

Andiamo a vedere una possibile strategia per tracciare queste informazioni e al contempo “liberare” il Backlog dai Work Item inutili, attraverso una soluzione estremamente semplice, soprattutto se applicata all’atto della creazione del Team Project.

Apriamo la sezione di amministrazione di VSO, spostiamoci nelle “Aree” e creiamo una struttura simile alla seguente:

remove work item 1

Area Settings

ValidateWorkItem sarà l’Area di riferimento per tutti i Work Item che intendiamo realmente realizzare, mentre _ReadyToDeletequella per i Work Item da scartare.

A questo punto, spostandoci nella sezione di gestione dei Team, creiamo un nuovo Team (nel caso in esempio: Working Team) associato al Team Project, facendo attenzione a non far creare un’Area di Default.

remove work item 2

New Team

Selezioniamo il nuovo Team e spostiamoci nuovamente nella sezione specifica delle Aree, andando ad associarlo all’area “ValidateWorkItem”.

remove work item 3

Associamo l'Administrator Team alla Root Area

Fatto questo, il nuovo Team avrà a disposizione una home page specifica omonima ma, soprattutto, un Product Backlog “epurato” dai Work Item che saranno associati all’Area _ReadyToDelete, visibili comunque al Team di Default.

remove work item 4

Work Item setted on _ReadyToDelete Area

Il nuovo Team creato può essere considerato come il Team di riferimento per le attività di sviluppo, mentre quello di Default andrà considerato come Team di Amministrazione a cui saranno visibili tutti i Work Item e, di conseguenza, associato alla Root Area (“SUAP” nell’esempio).

Nel caso si voglia procedere con la soluzione più drastica, ovvero la completa cancellazione dei Work Item “inutili”, la succitata organizzazione è comunque d’aiuto perché circoscrivere l’Area di appartenenza (e di intervento) dei Work Item stessi.

github logoPer cancellare i Work Item possiamo utilizzare le API di VSO/TFS, sulla falsa riga del semplice programma dimostrativo scritto in C# e liberamente disponibile su GitHub: https://github.com/felicepescatore/TFSWorkItemDeleteSample.git

Le dll Microsoft.TeamFoundation.Client e Microsoft.TeamFoundation.WorkItemTracking.Client, necessarie al suo funzionamento, sono presenti nel vostro sistema al seguente path: C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v2.0.

Attenzione: il programma cancella DEFINITIVAMENTE i Work Item, per cui va utilizzato con la massima attenzione.

Prima di potervi connettere da codice alla vostra istanza VSO, è necessario che abilitiate l’opzione “Alternate Credential & Password” direttamente da vostro profilo/Microsoft Account (lo trovate in alto a destra una volta loggati in VSO).

profile alternate credential

Alternative Auth Credential

In alternativa alla soluzione proposta, sempre per cancellare i Work Item è possibile ricorrere anche alla riga di comando:

witadmin destroywi /collection:CollectionURL /id:id [/noprompt]

 

[FELICEPESCATORE.IT]

Posted: 11 nov 2014 16:07 da felice.pescatore | con no comments
Inserito sotto: , ,