Il 12/12/2010 20:21, Renzo Bianchi ha scritto:
Il 12/12/2010 19.58, Carlo Strata ha scritto:
- vuoi dirmi che le regressioni sono solo logiche e non di codice?
Non ho capito cosa vuoi dire.
Io sì ;-)
1) Il primo concetto che mi fa venire in mente la parola "regressione",
sempre e comunque osservata dall'utente del programma, è che parte di
codice che qualcuno possa aver corretto venga per qualche motivo *persa*
e si ritorni in toto a quello che c'era prima.
Brutalmente!
Quindi si è tornati indietro essendo tornati indietro anche nel codice
(ritorno ad un vecchio codice, reso obsoleto almeno una volta in un
qualche dove, ramo o trunk). E questo nonostante i super evoluti sistemi
di versionamento (CVS, SubVersion, Hg (Mercurial), GIT, Bazaar, WebDAV,
...).
2) Diverso, e temo molto più raro, il caso in cui la regressione, sempre
e comunque osservata dall'utente del programma, e quindi sempre
funzionale, sia però dovuta al codice corretto (prima correzione), ma
nuovamente ritoccato (per rinnovati motivi) e dotato di differenti (!)
bug sul codice, ma aventi i medesimi effetti funzionali del codice
precedente la prima correzione (regressione, appunto).
Quindi si è tornati indietro pur essendo andati avanti nello sviluppo
del codice.
Il caso 2 è umano, estremamente umano; il caso 1 è diabolico e va
evitato e combattuto.
Quello che capisco dalla Vostra opinione è che dovremmo sempre essere
nel secondo caso: allora io chiedo facciamo un'indagine a campione
(rappresentativo) su una ventina di regressioni e vediamo quante stanno
nel caso 1 e quante stanno nel caso 2???
Se quelle del caso 1 sono abbastanza come reputo, vogliamo cominciare a
chiederci perché? E magari anche ad andare un momentino oltre???!!!
Sono riuscito a farmi capire questa volta?
- vuoi dirmi che se io vado a vedere la stessa linea di codice del
rilascio stabile precedente trovo solo quella differenza?
Se c'è una differenza vuol dire che qualcuno lo ha cambiato, non è che
il codice cambia da solo.
Ovviamente...
Io voglio solo dire che mettiamo che si riscrivono 100 righe perché si
vuole apportare un miglioramento a una funzione. Quello che provoca il
regression non sono tutte le 100 righe, ma è solo una piccola svista.
Una piccolo particolare che il programmatore non ha considerato, e che
magari salta fuori in un contesto poco prevedibile, quando il programma
richiama quella parte di codice.
Ecco vedi, tu stai affermando, senza aver il minimo dubbio in proposito
che le regressioni (direi che sono femminili :-) siano tutte e sole del
tipo 2, ma ci metteresti *a priori* la mano sul fuoco???
Le funzioni (nel senso di funzioni di codice, non di funzionalità
dell'applicativo) contengono codice riutilizzabile e richiamabile dalle
parti più svariate del programma, e è difficile prevedere tutto.
Sono d'accordo.
E' anche vero (e forse è questo che vuoi dire) che un regression si può
anche generare dal conflitto di due CWS sviluppati parallelamente e
senza considerare le interazioni reciproche, ma questo dovrebbe essere
minimizzo dai controlli automatici ai quali ogni CWS è sottoposto.
Scusa la mia ignoranza, ma ritenendo di non essere il solo, potresti
spiegare cos'è un CWS? È un tracking system come lo sono Trac, itracker,
Scarab, Gitorius, Maven e Bugzilla?
Perché, Renzo ed è qui che voglio battere non
so se si è ancora capito, non si riduce l'intervento solamente laddove
necessario?
Mah, io suppongo che si cerchi di modificare il minimo indispensabile
che permette di ottenere il risultato voluto. Non credo che qualcuno si
diverta a inserire codice inutile a caso...
Vuoi dirmi ancora che qualcosa nei processi in tal senso non
è migliorabile con grosso impatto e conseguenze positive nella stabilità
e conseguente qualità del codice prodotto?
I processi sono sempre migliorabili, però è il fattore umano a essere in
prima linea.
Concordo.
Buona serata,
Carlo
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
