Nel progetto su cui sto lavorando da quasi un anno abbiamo adottato la pratica di non chiudere la carta finchè qualcun altro del team non abbia apposto la sua firma per poter procedere.
La technical review è diventata quindi una pratica di team; inizialmente il mio pensiero era differente: ogni programmatore doveva assumersi la responsabilità della funzionalità implementata e garantire che era 'conclusa' dopo averla testata, dimostrata al cliente, e in generale aver compiuto tutti i passi necessari.
Mi sono dovuto ricredere.
E' semplicemente naturale per un programmatore essere guidato da ciò che si definisce l'happy path: il caso positivo, quando tutto va bene e fila liscio.
Uno dei passi di chi compie la techical review è quindi chiedersi se la funzionalità è robusta, e copre casi disparati differenti dall'happy path. Se tali passi non sono stati coperti si discute con il responsabile della funzionalità ed eventualmente si pianificano le attività da compiere successivamente.
Un altro compito del reviewer è, banalmente, assicurarsi che davvero funzioni. Non è scontato che una modifica dell'ultimo momento, un periodo di distrazione etc. faccia sì che la funzionalità non sia completamente finita.
Terzo punto è assicurarsi che tutto sia loggato correttamente, perchè a fronte di un qualsiasi problema non previsto si abbiano gli strumenti necessari per scoprire cosa è successo. Questo può voler dire ad titolo di esempio evitare di avere codice del tipo
try { .... } catch (Exception e)
quando la rosa delle eccezioni sollevabili dal codice invocato è più ristretta.
Quarto punto è garantire l'aderenza della funzionalità che si vuole consegnare rispetto al processo definito. Ad esempio se il team ha deciso che ogni funzionalità va documentata su un wiki, occorre assicurarsi sia stato fatto. Lo stesso dicasi per gli acceptance tests, o analoghi strumenti per verificare che la funzionalità sia corretta.
Nel nostro team abbiamo notato che ogni persona che ricopre il ruolo di reviewer pone maggiore focus su certi aspetti rispetto ad altri. Questo è del tutto naturale. Io, ad esempio, pongo poca attenzione al codice, a meno di grossolani errori accetto facilmente qualsiasi strategia implementativa. Il mio focus è molto orientato all'aderenza alle specifiche, al log e al funzionamento.
La technical review è una pratica consigliata sopratutto in team medio/grossi dove il rischio di dispersione della conoscenza o dagli standard che si è dato il team è molto grosso.
La technical review è diventata quindi una pratica di team; inizialmente il mio pensiero era differente: ogni programmatore doveva assumersi la responsabilità della funzionalità implementata e garantire che era 'conclusa' dopo averla testata, dimostrata al cliente, e in generale aver compiuto tutti i passi necessari.
Mi sono dovuto ricredere.
E' semplicemente naturale per un programmatore essere guidato da ciò che si definisce l'happy path: il caso positivo, quando tutto va bene e fila liscio.
Uno dei passi di chi compie la techical review è quindi chiedersi se la funzionalità è robusta, e copre casi disparati differenti dall'happy path. Se tali passi non sono stati coperti si discute con il responsabile della funzionalità ed eventualmente si pianificano le attività da compiere successivamente.
Un altro compito del reviewer è, banalmente, assicurarsi che davvero funzioni. Non è scontato che una modifica dell'ultimo momento, un periodo di distrazione etc. faccia sì che la funzionalità non sia completamente finita.
Terzo punto è assicurarsi che tutto sia loggato correttamente, perchè a fronte di un qualsiasi problema non previsto si abbiano gli strumenti necessari per scoprire cosa è successo. Questo può voler dire ad titolo di esempio evitare di avere codice del tipo
try { .... } catch (Exception e)
quando la rosa delle eccezioni sollevabili dal codice invocato è più ristretta.
Quarto punto è garantire l'aderenza della funzionalità che si vuole consegnare rispetto al processo definito. Ad esempio se il team ha deciso che ogni funzionalità va documentata su un wiki, occorre assicurarsi sia stato fatto. Lo stesso dicasi per gli acceptance tests, o analoghi strumenti per verificare che la funzionalità sia corretta.
Nel nostro team abbiamo notato che ogni persona che ricopre il ruolo di reviewer pone maggiore focus su certi aspetti rispetto ad altri. Questo è del tutto naturale. Io, ad esempio, pongo poca attenzione al codice, a meno di grossolani errori accetto facilmente qualsiasi strategia implementativa. Il mio focus è molto orientato all'aderenza alle specifiche, al log e al funzionamento.
La technical review è una pratica consigliata sopratutto in team medio/grossi dove il rischio di dispersione della conoscenza o dagli standard che si è dato il team è molto grosso.
Nessun commento:
Posta un commento