riflessioni personali: organizzazione e metodi di lavoro

[VICIUS]

Originariamente inviato da 71104

si, praticamente VICIUS
comunque a parte tutto nonostante l'esperienza di Diamonds io non riesco proprio ad apprezzare il valore del TDD: secondo me questi test hanno un costo di manutenzione troppo alto perché ad ogni refactoring i test ovviamente falliscono, e spesso non è il codice che non va, sono proprio i test (vanno mantenuti anch'essi).[...]

Se facendo un piccolo refactoring falliscono troppi test vuol dire che c'è qualcosa che non va. Un campanello d' allarme che ti dice che forse devi guardare meglio quello che stai facendo.

ciao

[cionci]

Originariamente inviato da VICIUS

Se facendo un piccolo refactoring falliscono troppi test vuol dire che c'è qualcosa che non va. Un campanello d' allarme che ti dice che forse devi guardare meglio quello che stai facendo.

Probabilmente intende refactoring pesanti, come togliere aggiungere funzionalità ad un metodo o una classe...

[VICIUS]

Originariamente inviato da cionci

Probabilmente intende refactoring pesanti, come togliere aggiungere funzionalità ad un metodo o una classe...

I refactoring pesanti non dovrebbero mai capitare. TDD è una metodologia agile e consiglia di fare piccoli passi, procedere lentamente senza mai fermarsi invece di grossi salti nel buio. Certo a volte capitano ma sono sicuramente mosche bianche. In ogni caso è proprio quando capitano questi rari casi che i test vengono piu utili.

Se a progetto finito il committente ti chiede di cambiare l'unita di misura in tutto il progetto, oltre a lanciare qualche madonna e a pensare a quanti euro in piu chiedere, come reagisci? Con i test puoi fare le tue modifiche e lanciarli per vedere tutte le aree che sono affette. Senza non ti resta che accendere un cero al santo patrono dei debugger e sperare che non ci siano strani side-effects.

ciao

[VICIUS]

Originariamente inviato da 71104

se il punto forte di una qualsiasi metodologia è agire poco producendo molto, i test causano esattamente il contrario: fanno agire precisamente il doppio del necessario (se non di più).
i test sono l'unico punto della metodologia di fek sui quali non concordo.

Preferisco la meta del codice e la quasi certezza di non avere bug che il doppio ed il perenne rischio di dover usare gdb da console.

ciao

[Angus]

Originariamente inviato da VICIUS

*snip*
ed il perenne rischio di dover usare gdb da console.
*snip*

Quello, seppur ridotto dalla qualità e quantità dei test (e anche qui ci sarebbe parecchio da discutere), rimane comunque perenne.

In medio stat Vicius.

[cionci]

Angus: quel "tanto da discutere" lo possiamo anche fare qui... E' stato aperto appositamente questo thread Dai che sono curioso...esprimi tutti i tuoi dubbi su ogni punto...

[Angus]

Come accennavi qualche post fa, i test vanno innanzitutto scritti *bene*.
Invito chi fosse interessato a leggere CCA, che descrive le problematiche che riguardano la misura della qualità dei test e se gli stessi sono sufficienti a garantire un basso richio di bug. Per esempio esistono tool che cercano di scovare le parti di codice non coperte da test.
Il TDD secondo me è molto utile dal punto di vista funzionale, mentre un buon linguaggio e un buon compilatore possono ovviare a tanti strafalcioni di programmazione. Un esempio della discussione infinita si trova qui.
Imho una strategia vincente in assoluto non c'è, ma va scelta quella giusta caso per caso, o meglio ancora vanno utilizzate tutte in modiche quantità ;-)

ps: pensavo che il thread riguardasse principalmente l'organizzazione di un gruppo di lavoro, mea culpa.

[cionci]

Originariamente inviato da Angus

ps: pensavo che il thread riguardasse principalmente l'organizzazione di un gruppo di lavoro, mea culpa.

Sì...inizialmente...ma diciamo che in parte le metodologie di sviluppo come la TDD coprono anche questo...

Riguardo ai tool per scoprire il codice non coperto da test... Se non sbaglio VICIUS sta usando un software di questo tipo...

[71104]

Originariamente inviato da VICIUS

Se a progetto finito il committente ti chiede di cambiare l'unita di misura in tutto il progetto, oltre a lanciare qualche madonna e a pensare a quanti euro in piu chiedere, come reagisci? Con i test puoi fare le tue modifiche e lanciarli per vedere tutte le aree che sono affette. Senza non ti resta che accendere un cero al santo patrono dei debugger e sperare che non ci siano strani side-effects.

ad ogni modo: con i test devi modificare una marea di codice (i test appunto) e un'altra marea di codice (il programma vero e proprio); in entrambi potresti commettere degli errori.
senza i test le due maree di codice da modificare diventano una marea sola.
imho.

[71104]

Originariamente inviato da VICIUS

Preferisco la meta del codice e la quasi certezza di non avere bug che il doppio ed il perenne rischio di dover usare gdb da console.

mi sa che hai scambiato "metà" e "doppio"

[cionci]

Originariamente inviato da 71104

senza i test le due maree di codice da modificare diventano una marea sola.

Piena di errori...e con la possibilità di metterci più del doppio a risolverli, se non se ne introducono di nuovi correggendoli...

[VICIUS]

Originariamente inviato da 71104

ad ogni modo: con i test devi modificare una marea di codice (i test appunto) e un'altra marea di codice (il programma vero e proprio); in entrambi potresti commettere degli errori.
senza i test le due maree di codice da modificare diventano una marea sola.
imho.

Certo anche i test sono codice quindi rischiano di essere difettosi. Dovrai ammettere che è infinitamente piu facile trovare un bug in un test come questo.

public void testFibonacciDiZero() 
{
    assertEquals(0, fibonacci(0));
}

Che in una ipotetica funzione ricorsiva che viene testata. Non che serva la ricorsione per far passare questo test.

ciao

[VICIUS]

Originariamente inviato da 71104

mi sa che hai scambiato "metà" e "doppio"

Supponi di essere in grado di scrivere in media mille linee di codice al giorno.
Suponi ora che le linee di codice usate dai test siano circa il 50%.
Le linee di codice utili per il progetto sono quindi la meta.
Procedendo senza scrivere i test sarebbero, invece, mille linee utili. 100%. Quindi il doppio.

ciao

[Angus]

Verba volant...
Vorrei sperare che il thread non si riduca ad uno sterile 'io ce l'ho più grosso del tuo'.
In cosa una metodologia è migliore di un'altra? A parità di software prodotto direi che è il tempo impiegato. Ma come si misura il tempo impiegato? In giorni/uomo? Non credo che sia una misura affidabile. Più i progetti sono grandi più le metodologie di sviluppo si inseriscono in un contesto di gestione delle risorse molto più ampio.
Come scala il TDD (per esempio) all'aumentare delle persone e al diminuire del tempo (quello vero) a disposizione?
I discorsi fatti negli ultimi post sembrano invece affrontare il problema dal punto di vista probabilistico o statistico:
C'è una fazione che afferma che il codice totale scritto mediante TDD è sì più lungo (ma di quanto?) del codice scritto senza TDD, ma contiene statisticamente meno errori perchè 'autoreferenziato' e quindi (?) di migliore qualità. L'altra fazione afferma che invece probabilisticamente il doppio del codice contiene semplicemente il doppio degli errori o anche più.
Non mi sembra un approccio corretto.
Bisogna dare atto al TDD che porta dei vantaggi in fase di refactoring per controllare che quello che funzionava prima delle modifiche continui a funzionare. Per funzionare intendo proprio l'aspetto funzionale del codice, non la sua correttezza sintattica/semantica che può essere controllata da un buon compilatore o strumento analogo. Non lo vedo invece come alternativa alle fasi di progettazione, che anche se solo su carta rimane indispensabili in progetti di medie/grandi dimensioni e aiuterebbe la stesura di test mirati ed efficienti, che non richiedano a loro volta continui refactoring.
Credo che finora il TDD abbia faticato ad emergere semplicemente perchè i framework attuali non sono stati accompagnati da tool all'altezza. Col tempo mi aspetto che il TDD diventi una cosa talmente naturale e automatizzata da fare che non ci renderemo neanche più conto di usarlo.
Ora sto decisamente vaneggiando, mi fermo qui.

[cionci]

Angus: le tue considerazioni sono tutte giuste...senza ombra di dubbio... Sulla questione "misure", per ora mi sto basando su quello che vedo con Diamonds, e di conseguenza non ho ancora studiato niente su TDD e XP, quindi per ora ho le conoscenze di un corso base di ingegneria del software (in cui non si facevano TDD e XP)...

[Angus]

Originariamente inviato da cionci

Angus: le tue considerazioni sono tutte giuste...senza ombra di dubbio... Sulla questione "misure", per ora mi sto basando su quello che vedo con Diamonds, e di conseguenza non ho ancora studiato niente su TDD e XP, quindi per ora ho le conoscenze di un corso base di ingegneria del software (in cui non si facevano TDD e XP)...

Dove lavoro facciamo largo uso di XP, ma solo perchè finora siamo stati quattro gatti a programmare seriamente. Nell'immediato futuro dovrò affrontare la crescita dei progetti ed aspetti che tempo fa non avevo minimamente preso in considerazione, come la manutenibilità del software da parte di persone che non ne hanno mai scritta una sola riga. Anche io mi baso solo su studi universitari e per la gran parte su quello che leggo in rete. Ho provato alcuni framework per il TDD ma non potevo permettermi il loro costo iniziale (in termini di tempo). Dovresti però aver incontrato di sfuggita, durante il corso di ingegneria del sw, almeno la teoria del Code Coverage. O ti hanno rimpinzato di UML e basta? A tal proposito:

Ma dove li mettiamo i Design Patterns? Voi diamanti ne fate uso? E chi è il vostro pusher?

[VICIUS]

Originariamente inviato da Angus

Ma dove li mettiamo i Design Patterns? Voi diamanti ne fate uso? E chi è il vostro pusher?

Si c'è qualcosa ma è nascosto nei menadri del codice. Il pusher per ora è un vacanza dovrebbe tornare questa sera

ciao

[VICIUS]

Originariamente inviato da Angus

In cosa una metodologia è migliore di un'altra? A parità di software prodotto direi che è il tempo impiegato. Ma come si misura il tempo impiegato? In giorni/uomo? Non credo che sia una misura affidabile.

Di certo con una sola misura non si puo capire molto. Ce ne sono decine. Ci si deve mettere li e decidere quali sono quelle che si ritengono piu importanti da usare per fare un confronto.

Originariamente inviato da Angus

Più i progetti sono grandi più le metodologie di sviluppo si inseriscono in un contesto di gestione delle risorse molto più ampio.
Come scala il TDD (per esempio) all'aumentare delle persone e al diminuire del tempo (quello vero) a disposizione?

A questo non so rispondere. Non ho mai lavorato in un grande team che facesse uso di TDD o altre tecniche XP. Ma devo ammettere che mi piacerebbe.

Originariamente inviato da Angus

I discorsi fatti negli ultimi post sembrano invece affrontare il problema dal punto di vista probabilistico o statistico:

Ci sono altri modi? Un processo è qualcosa di troppo astratto influenzato da troppi fattori per essere misurato da una formula matematica.

ciao

[cionci]

Originariamente inviato da Angus

O ti hanno rimpinzato di UML e basta? A tal proposito:

Ma dove li mettiamo i Design Patterns? Voi diamanti ne fate uso? E chi è il vostro pusher?

Niente Code Coverage, se ricordo bene...UML (gran parte del corso), le metodologie di sviluppo classiche e i Design Patterns...ma era mezza annnualità...

[^TiGeRShArK^]

Originariamente inviato da Angus

come la manutenibilità del software da parte di persone che non ne hanno mai scritta una sola riga.

boh...
io su questo posso solo portare la mia personale esperienza....
durante la storia precedente (quella andata a buon fine N.d.A.) ho fatto un paio di task...
il codice ovviamente l'avevo già visto prima, ma quando sono andato a riprenderlo era completamente cambiato dall'ultima volta.... praticamente rimanevano invariati solo i nomi di "alcune" classi e il funzionamento generale del software...
ebbene.. mi è venuto molto semplice andare a studiare quel codice e vedere dove andava fatto il mio intervento per sviluppare i task...
inoltre, grazie all'uso dei test, mi sono subito accorto ke era stata fatta una confusione sulle coordinate utilizzate.... infatti credo ke la maggior parte di noi siano abituati a pensare con l'origine posta in alto a sinistra... in Open GL invece l'origine è posta in basso a sinistra...
dopo aver modificato il software per aggiungere il mio task ho subito visto che il test che falliva era quello opposto (falliva lo spostamento verso il basso anzikè quello verso l'alto).
In questo modo sono riuscito a tracciare abbastanza in fretta il bug e a porvi soluzione... non oso immaginare se fossimo stati senza test quanto tempo sarebbe occorso prima di tracciare TUTTE le occorrenze del bug e porvi rimedio......
Morale della favola... almeno per quanto ho visto io il codice ottenuto è facilmente leggibile anche da ki non ha mai messo mani al codice e soprattutto la fase di debug è codiuvata dai test, aiuto ke spesso può risultare provvidenziale (e lo so bene dato ke al lavoro stiamo procedendo senza test... e con parti di codice scritte praticamente in aramaico da qualcuno......Credo ke se avessimo applicato questa metodologia anke lì tutto sarebbe stato + facile)
my two centu liri!


dimenticavo... se alla toughtworks spingono molto su questa metodologia di sviluppo credo ke sia una delle migliori ad oggi esistente (se non la migliore )