Refactoring e testing: stabilire le priorita'

[Emmanuele Sordini]

Ciao a tutti,
io ho un progetto, composto da una gerarchia abbastanza ramificata di
package, su cui devo fare del refactoring e aumentare la copertura con
test JUnit.

Il mio problema, ora, e' stabilire delle priorita', cioe' su quali
parti del codice sorgente sia necessario intervenire per primo.
Ovviamente ci sono delle parti di codice che uno considera piu'
importanti, oppure che magari richiedono urgente attenzione perche'
hanno copertura molto bassa: sulla base di questi criteri, abbastanza
soggettivi, si puo' sempre stabilire un ordine di priorita'.

Stavolta, vorrei decidere le priorita' sulla base di criteri piu'
quantitativi, cioe' assegnare un punteggio, un "voto" a ciascuna parte
del progetto.

Io qualche idea ce l'avrei, ma volevo farvi una domanda: qualcuno di
voi ha mai affrontato il problema in questi termini?

Grazie in anticipo
Emmanuele

[Fabrizio Giudici]

E' il modo buono e giusto di affrontare il problema. Tecnicamente, devi valutare gli aspetti di rischio legati al refactoring. Possono essere molteplici: p.es. una certa parte di progetto può andare soggetta ad un refactoring relativamente semplice (p.es. perché non è fatta troppo male), ma essere così strategica all'interno del progetto che ogni piccola regressione fa scattare un casino (sia tecnico che politico, altro aspetto di rischio). Al contrario, può esserci una parte di codice totalmente incasinato, che però è usata raramente e per funzioni non essenziali, per cui il rischio è minore. Fatti i due casi limite, ovviamente nel mondo reale ti trovi una "combinazione pesata" di rischi. Ce ne sono molti di più di quanto non abbia detto in queste due righe (non mi pare il tuo caso, ma p.es. uno rifattorizza per usare un nuovo prodotto - da es. Hibernate - ed ha una serie di rischi tecnologici, di skill, etc.. associati). La prima cosa da fare, quindi, è trovare e associare quello che chiami punteggio di rischio (generalmente basta: basso, medio ed elevato, generalmente è inutile andare a grana più fine) sulle aree funzionali del progetto (p.es. gli use case).

Quindi, in soldoni, si parte dagli use case (o user stories), e se non sono documentate, questo può essere il momento di farlo :-)

Va da sé che questo lavoro deve essere condiviso da tutto il team, per evitare prospettive soggettive ed errate.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it

[Emmanuele Sordini]

2009/10/26 Fabrizio Giudici <fabrizio...@tidalwave.it>:

>
> E' il modo buono e giusto di affrontare il problema. Tecnicamente, devi

> valutare gli aspetti di rischio legati al refactoring. .
> [...CUT...]

> Ce ne sono molti di più di
> quanto non abbia detto in queste due righe (non mi pare il tuo caso, ma
> p.es. uno rifattorizza per usare un nuovo prodotto - da es. Hibernate - ed
> ha una serie di rischi tecnologici, di skill, etc.. associati). La prima
> cosa da fare, quindi, è trovare e associare quello che chiami punteggio di
> rischio (generalmente basta: basso, medio ed elevato, generalmente è inutile
> andare a grana più fine) sulle aree funzionali del progetto

In questo caso l'obiettivo e' piu' orientato verso l'aumento della %
di copertura dei test, e per questo motivo l'individuazione di "rami
secchi" e' indispensabile per evitare che nel computo ricada anche del
codice che non si usa piu'. Lo stesso codice (intendo dire, classi
intere) per ora viene solo "deprecato", con l'obiettivo, entro un
tempo non troppo lungo (diciamo alcuni mesi), di levarlo dal "trunk"
principale del sorgente (tanto ne resta comunque traccia nel
repository dei sorgenti). Quindi, per ora, non si tratta di
refactoring che vanno a toccare troppo a fondo il codice.

Per quanto riguarda l'attribuzione di priorita', ho trovato un modo di
calcolarla, a livello di package, partendo dai seguenti dati:

1) Importanza del package nel progetto (espresso come un voto da 1 a 5)
2) Livello attuale di copertura del package, ed in particolare
differenza rispetto ad un target stabilito (es. 80%)
3) Peso rivestito dal quel package nel totale del codice (proprio come
% di LOCs rispetto al totale)

Una media pesata di queste tre grandezze mi permette di assegnare un
unico voto che le racchiuda tutte e tre. Qui Excel puo' essere di
grande aiuto... :-)

> Quindi, in soldoni, si parte dagli use case (o user stories), e se non sono
> documentate, questo può essere il momento di farlo :-)

Stiamo cominciando a farlo, anche perche' qualcuno ce le sta
chiedendo, ma ho l'impressione che il loro utilizzo sia in questo
momento troppo prematuro. Quando certa documentazione la fai a
posteriori, rischia di diventare solo buona per pulirsi le parti basse
:-)

> Va da sé che questo lavoro deve essere condiviso da tutto il team, per
> evitare prospettive soggettive ed errate.

Questo e' ovvio. Comunque, come ho detto gia' prima, non si tratta per
ora di modiche devastanti, ma solo fare un po' di ordine.

Emmanuele