Molto si è detto e scritto circa quali metriche è opportuno considerare durante lo sviluppo di un progetto.
Poichè le metriche servono esclusivamente a incoraggiare un comportamento, trascrivo qui quelle che piacciono a me, seguendo le quali si riuscirà a diventare un ottimo programmatore.
Seguitemi:
> Minimizzare il numero di user stories lavorate in modalità Last In First Out
Quando l'ultima user story descritta è sempre la più importante vuol dire che non c'è un vero e proprio planning e si è perso qualsiasi concetto di pianificazione e priorità: il vostro progetto sta andando a ramengo.
> Profondità coverage
Sapere che l' 80 % del codice è testato è una buona cosa. Eppure sapere che dalla stessa riga di codice ci passano più test in generale può voler dire che sono stati scritti non solo dei test unitari, ma anche dei cluster test o degli integration (o acceptance) test.
Se due test di diversa natura passano dalla stessa riga di codice la profondità di coverage è 2, che è meglio di una profondità di 1.
> Massimizzare la varietà di dati di test (suggerita dal mio collega Marco Gulino)
Non siamo abituati a pensare alle boundary conditions. Un eventuale codice del tipo: if (i < i ="=" i =" MAX_INT" i =" -1" style="font-weight: bold;">> Monitorare il rapporto Errore di stima / Numero di framework usati
L'errore di stima cresce a seconda del numero di tecnologie attraversate. Per completare la vostra user story dovete toccare solo maven, java, spring ? Oppure anche hibernate, fitnesse, wicket, selenium etc..? Calcolate un fattore correttivo adeguato!
> Duplicazione divergente
Certo la duplicazione è un male: ogni modifica in un codice copiato va riportato paro paro da altre parti e tale processo è error-prone, ma alcuni eroi con un po' di lavorio con search&replace e espressioni regolari riescono senza dubbio a lavorare in questa modalità. Eppure se i pezzi di codice duplicato divergono si perde la capacità eccezionalmente umana di riconoscere ad occhio le differenze. Il tuo codice non solo è duplicato ma non è più nemmeno simmetrico!
> Il rapporto Numero di classi / Numero di metodi pubblici deve tendere a uno
Una classe, una responsabilità, un solo metodo pubblico. E' facile identificare di quante responsabilità è caricato un oggetto: il piu delle volte basta contare il numero di metodi privati
> Il tempo di esecuzione test non deve degenerare all'aumentare del numero di test
Per lo meno garantisci che rimanga costante al crescere del numero di test. 100 test ci mettono 100 secondi? Se 200 test ci mettono 200 secondi stai adottando una strategia non peggiorativa.
> Minimizzare il numero di user stories che tornano "in progress"
Non mi ricordo chi l'ha detta, ma è di certo sintomo che gli AT non sono efficaci, e rilavorare funzionalità considerate finite è frustrante e puà essere dannoso se chi sistema i bachi non coincide con chi ci ha lavorato.
Nessun commento:
Posta un commento