Newsgroup: it.comp.programmare
Titolo: molti errori di regressione

Se in un progetto si verificano, con il susseguirsi delle versioni e 
degli adattamenti, molti errori di regressione cosa significa?
 
Io credo che sia necessario modificare sostanzialmente alcune parti del 
progetto e cambiare l'architettura del software, ma ovviamente questa è 
una opzione piuttosto costosa e mi serve di poter dimostrare quel che 
dico... intuitivamente io collego il gran numero di regressioni a questa 
necessità, nel senso che data la struttura attuale dell'applicazione i 
programmatori sono portati a ripetere sempre gli stessi errori.
 
Però se ci fosse qualche articolo o libro che supporta questa tesi mi 
sentirei molto meglio... una ricerca rapida non mi ha dato risultati in 
questo senso.

 
 
Che a fronte di un aggiornamento non si fanno correre i vecchi test.
Secondo la letteratura più diffusa, ogni bug o regressione dev'essere seguita dalla scrittura di un test apposito (che si chiama guardacaso test di non-regressione) e relativa correzione. Ovviamente ogni rilascio vanno fatti correre *tutti* i test (unit, non-regressione, etc.).
 
Ciao!

 programmatori sono portati a ripetere sempre gli stessi errori.
 
No, ti ha spiegato bene fmassei. Vuole dire che, semplicemente, non fate
abbastanza testing unitario. Ad ogni buon conto nello stato attuale fare
refactoring pesante (o addirittura cambiare architettura) e' un suicidio
puro e semplice. 
 
Se non avete i test per supportare lo sviluppo normale "evolutivo",
figurati una rivoluzione. Probabilmente finirebbe in un laco ti sancue.
 
Prima cosa dovete migliorare:
 
1. i test unitari in quanto tali
2. le regole: fino all'estremo di mettere suddetti test in hook nel vcs
di modo tale che la gente proprio non possa non passarli, ma meglio se
convincete in altro modo gli sviluppatori a farli. Ovviamente
"costringere" non funziona bene: la gente e' oltremodo creativa per
girare intorno alle norme che non comprende, molto meglio spiegare il
problema.
 
 
-- 
-riko
http://www.enrico-franchi.org/
 
http://rik0-techtemple.blogspot.com/
 

 abbastanza testing unitario.
 
No, i test di regressione li facciamo e gli errori li sistemiamo, solo 
che è seccante vedere saltare fuori sempre gli stessi vecchi errori ogni 
2x3. Poi si fixano appena i test dicono che ci sono, però mi dà da 
pensare. Perché i programmatori inciampano sempre sullo stesso sasso, 
anche se sanno che è lì?


Ci sono due possibilità:
1) I test li fate ma poco e male. Se non passano mai metteli a correre automaticamente dopo ogni compilazione. Specialmente se il software è grosso non è possibile che tutti (specialmente i nuovi arrivati) si ricordino o addirittura sappiano di bug di anni prima; i test sono uno strumento che serve apposta per questo.
2) Avete come programmatori degli incapaci: assumente qualcuno di più skillato pagandolo di più. Oppure sono bravi ma poco motivati: motivateli (magari pagandoli di più! :D).
 
Comunque vada, come già ti ha detto anche Enrico, un cambio di architettura (ma anche solo un refactoring) vanno fatti quando il software funziona *perfettamente* (così se qualcosa va storto lo puoi scoprire con i test!).
 
Se sei nella posizione di poter decidere, e il costo dell'operazione è accettabile, potresti anche decidere di fare una nuova versione del software partendo da zero, magari cambiando addirittura paradigma (tieni presente che man mano che si va avanti con gli anni il costo dello stesso progetto from-scratch diminuisce, e fornisce gratuitamente strumenti il progetto precedente non aveva), magari formando un gruppetto di sviluppatori dando loro così una buona motivazione a fare bene.
 
In ogni caso tutti questi discorsi sono fuffa finché non si conosce a il problema; un po' di input "standard" spero adesso tu li abbia! ;-)
Ciao!