non voglio affatto entrare nel conflitto fanatici-pro e fanatici-contro il
TDD (o qualunque argomento vi si possa sostiture).
Ammetto (sto battendo tre volte il pugno sul petto, candenzando con
altrettanti mea culpa) che, conoscendo personalmente alcune persone del
gruppo, mi sono permesso un lieve e divertita (con la fallace speranza che
fosse anche divertente) provocazione sul TDD.
Lorenzo, seppure inascoltato, ha descritto perfettamente quello che può
(non deve) essere un percorso creativo/matematico possibile nella souzione
di un problema.
L'idea di muoversi avanti indietro tra l'input e l'output di un problema
dato, il cercare di affrontarlo da diversi punti di vista (mi metto ai
morsetti, mi metto in un punto preciso, lo faccio fallire volutamente, mi
metto ai valori limite), ridurlo a condizioni ottimali (provo ad
affrontarlo prima in modo iterativo, provo il caso degenere), ricondursi a
pattern già noti (la maledetta esperienza tanto vantata, ma poi così poco
tenuta da conto) sono tutti elementi che fanno parte del processo di
problem solving.
Se dopo avere fatto tutta sta roba, ho tutti i miei test in barra
verde...quali altri problemi dovrei pormi? Perchè dovrei mettermi a
debuggare il codice passo passo per vedere cosa succede? Lo so già, perché
lo costruito io perché funzionasse così, e ci sono i test che ho scrito che
definiscono come deve funzionare. E questo per me risponde definitivamente
all'innocente provocazione.
Ma ne riapre un'altra: poteva attecchire tale provocazione senza un terreno
fertile di presunzione e supponenza?
Lo dico davvero senza offesa per nessuno. È una domanda aperta che invito
tutti a tenere presente, ogni volta che viene voglia di demolire la
preparazione, intelligenza, impegno, costanza, capacità, serietà, durezza,
purezza e qualsivoglia proprietà consideriate indispensabili per essere il
Vero Programmatore, di una persona che non si conosce e solo per una mezza
cosa che nemmeno si è capita.
Con affetto.
Vittorio
Il giorno 25 settembre 2012 16:12, <sug-it@googlegroups.com> ha scritto:
> - [POLL] Chi fa il corso di functional programming di coursera?<#139fdc5cf7f604a7_group_thread_0>[39 Updates]
> - Offerta di lavoro: Scala Developer at MoneyFarm<#139fdc5cf7f604a7_group_thread_1>[1 Update]
> anche io sto tribolando col 3° esercizio. Se riuscirò a finirlo
> probabilmente anche io non saprò perché funziona. :-)
> A volte con l'approccio TDD in CountChangeSuite finisco per ...more<http://groups.google.com/group/sug-it/msg/3c7004d7de3dcbcb>
> Il primo e il secondo li ho fatti in un paio d'ore ciascuno, ma il
> terzo mi
> fa penare. Su internet ho trovato cose sulla memoization ma sto
> battendo
> un'altra strada.
> Con il primo test ...more<http://groups.google.com/group/sug-it/msg/d5ad7cb2ec6b9f2d>
> Ho fatto i primi due esercizi ieri sera. Non ho ancora affrontato il
> terzo.
> In realtà anch' io tendo ad operare in TDD, quindi ho i test in barra
> verde...ma non ...more<http://groups.google.com/group/sug-it/msg/c2fc6b9c2705bb4b>
> A me del corso in realta' non interessa molto (voglio dire il
> punteggio e
> il documento di fine corso), la cosa che veramente mi interessa e'
> *sapere
> perche' funziona*; anzi a dire il vero avrei il ...more<http://groups.google.com/group/sug-it/msg/8c9bcf92587c3da6>
> Io sto facendo il corso prevalentemente per fare pratica con Scala e
> soprattutto per ottenere una maggiore familiarita' e dimestichezza con
> il
> modo di pensare e strutturare i programmi in modo ...more<http://groups.google.com/group/sug-it/msg/c62c39bd98f673a4>
> Ma gli incontri del JUG sono sempre infrasettimanali?
> Come gia' ci eravamo detti mi farebbe piacere venire qualche volta, ma
> durante la settimana e' piu' complicato.
> Mario Fusco <mario.fu...@gmail.com> Sep 24 07:09PM +0200
> > programmazione imperativa, quindi faccio fatica a pensare come
> comporre un
> > programma intero secondo i principi "funzionali", come ad esempio sei
> > costretto a fare in haskell.
> ...more <http://groups.google.com/group/sug-it/msg/3ff8985e56a29a1>
> Lorenzo Bolzani <l.bolz...@gmail.com> Sep 24 07:49PM +0200
> Il giorno 24 settembre 2012 19:07, Mario Fusco <mario.fu...@gmail.com>
> ha
> scritto:
> Mario Fusco <mario.fu...@gmail.com> Sep 24 07:59PM +0200
> > aspettavo, quindi non e' sempre una brutta strategia quella di
> "esplorare"
> > per andare/restare in barra verde e poi capire perche'. A patto
> ovviamente
> > di capirlo e di avere una suite di test ...more<http://groups.google.com/group/sug-it/msg/e5291ed1afe2a544>
> Lorenzo Bolzani <l.bolz...@gmail.com> Sep 24 09:21PM +0200
> Il giorno 24 settembre 2012 19:59, Mario Fusco <mario.fu...@gmail.com>
> ha
> scritto:
> Mario Fusco <mario.fu...@gmail.com> Sep 24 10:12PM +0200
> Preferirei non continuare questa discussione, ma ti consiglio di
> rileggere
> quello che hai scritto: fa sembrare la programmazione una specie di
> caccia
> al tesoro.
Questa discussione inizia ad essere un po' surreale per quanto mi riguarda,
ma vado avanti anche per seguire il consiglio di Emiliano quando dice che:
"nessuna questione e' troppo grande per non essere discussa".
Giusto per dare un po' di contesto alla cosa riporto fedelmente 2 frasette
scritte da Lorenzo in una mail precedente:
" Ho lanciato i test i passavano tutti tranne quello della lista non
sortata. A quel punto in qualche modo ho intuito che mancasse un'altra
ricorsione ma aggiungendola dove mi sembrava sensato non ha funzionato.
Allora l'ho aggiunta "a caso" nell'unico altro posto possibile e...tada':
barra verde.
Ho poi perso una buona mezz'ora tentando di seguire mentalmente tutto il
flusso ma non ci sono riuscito e per me dovrebbe trovare un numero
superiore di combinazioni. Pero' non sono riuscito ne' a trovare
alternative per me piu' chiare ne' a romperlo. Quindi sono andato a dormire
e la mattina dopo ho "committato". "
Punto primo: come ho già scritto precedentemente il fatto che la lista in
questione sia ordinata o meno è totalmente irrilevante ai fini della
corretta risoluzione del problema. Se non si è capito questo si è già fuori
strada.
Punto secondo (e più importante): siccome non ho visto la soluzione di
Lorenzo non posso dire se sia giusta o sbagliata (per "giusta" intendo sia
formalmente corretta che concisa ed elegante se possibile, altrimenti
inutile impegnarsi a usare Scala e tanto vale sviluppare in Fortran), ma
non è questo il punto. Il punto è che ammesso e non concesso che funzioni,
per sua stessa ammissione, non sa nemmeno lui perchè!
Ora, voi che siete guru del TDD, secondo voi il fatto di aver fatto
comparire quella maledetta barra verde è condizione necessaria e
SUFFICIENTE per considerare un determinato compito concluso con successo?
Se è così chi ce lo fa fare di scrivere il codice? Suggerisco di scrivere
solo i test e poi far girare un bell'algoritmo genetico che generi milioni
di programmi a caso finchè non ce n'è uno che faccia passare tutti i test.
Che ne dite?
Io sono pro-TDD, ma se la vostra definizione di TDD somiglia a quella che
ho scritto sopra allora sono decisamente contro.
> non voglio affatto entrare nel conflitto fanatici-pro e fanatici-contro il
> TDD (o qualunque argomento vi si possa sostiture).
> Ammetto (sto battendo tre volte il pugno sul petto, candenzando con
> altrettanti mea culpa) che, conoscendo personalmente alcune persone del
> gruppo, mi sono permesso un lieve e divertita (con la fallace speranza che
> fosse anche divertente) provocazione sul TDD.
> Lorenzo, seppure inascoltato, ha descritto perfettamente quello che può
> (non deve) essere un percorso creativo/matematico possibile nella souzione
> di un problema.
> L'idea di muoversi avanti indietro tra l'input e l'output di un problema
> dato, il cercare di affrontarlo da diversi punti di vista (mi metto ai
> morsetti, mi metto in un punto preciso, lo faccio fallire volutamente, mi
> metto ai valori limite), ridurlo a condizioni ottimali (provo ad
> affrontarlo prima in modo iterativo, provo il caso degenere), ricondursi a
> pattern già noti (la maledetta esperienza tanto vantata, ma poi così poco
> tenuta da conto) sono tutti elementi che fanno parte del processo di
> problem solving.
> Se dopo avere fatto tutta sta roba, ho tutti i miei test in barra
> verde...quali altri problemi dovrei pormi? Perchè dovrei mettermi a
> debuggare il codice passo passo per vedere cosa succede? Lo so già, perché
> lo costruito io perché funzionasse così, e ci sono i test che ho scrito che
> definiscono come deve funzionare. E questo per me risponde definitivamente
> all'innocente provocazione.
> Ma ne riapre un'altra: poteva attecchire tale provocazione senza un
> terreno fertile di presunzione e supponenza?
> Lo dico davvero senza offesa per nessuno. È una domanda aperta che invito
> tutti a tenere presente, ogni volta che viene voglia di demolire la
> preparazione, intelligenza, impegno, costanza, capacità, serietà, durezza,
> purezza e qualsivoglia proprietà consideriate indispensabili per essere il
> Vero Programmatore, di una persona che non si conosce e solo per una mezza
> cosa che nemmeno si è capita.
> Con affetto.
> Vittorio
> Il giorno 25 settembre 2012 16:12, <sug-it@googlegroups.com> ha scritto:
>> - [POLL] Chi fa il corso di functional programming di coursera?<#139fe0c0d8d4101c_139fdc5cf7f604a7_group_thread_0>[39 Updates]
>> - Offerta di lavoro: Scala Developer at MoneyFarm<#139fe0c0d8d4101c_139fdc5cf7f604a7_group_thread_1>[1 Update]
>> anche io sto tribolando col 3° esercizio. Se riuscirò a finirlo
>> probabilmente anche io non saprò perché funziona. :-)
>> A volte con l'approccio TDD in CountChangeSuite finisco per ...more<http://groups.google.com/group/sug-it/msg/3c7004d7de3dcbcb>
>> Il primo e il secondo li ho fatti in un paio d'ore ciascuno, ma il
>> terzo mi
>> fa penare. Su internet ho trovato cose sulla memoization ma sto
>> battendo
>> un'altra strada.
>> Con il primo test ...more<http://groups.google.com/group/sug-it/msg/d5ad7cb2ec6b9f2d>
>> Ho fatto i primi due esercizi ieri sera. Non ho ancora affrontato il
>> terzo.
>> In realtà anch' io tendo ad operare in TDD, quindi ho i test in barra
>> verde...ma non ...more<http://groups.google.com/group/sug-it/msg/c2fc6b9c2705bb4b>
>> A me del corso in realta' non interessa molto (voglio dire il
>> punteggio e
>> il documento di fine corso), la cosa che veramente mi interessa e'
>> *sapere
>> perche' funziona*; anzi a dire il vero avrei il ...more<http://groups.google.com/group/sug-it/msg/8c9bcf92587c3da6>
>> Io sto facendo il corso prevalentemente per fare pratica con Scala e
>> soprattutto per ottenere una maggiore familiarita' e dimestichezza
>> con il
>> modo di pensare e strutturare i programmi in modo ...more<http://groups.google.com/group/sug-it/msg/c62c39bd98f673a4>
>> Ma gli incontri del JUG sono sempre infrasettimanali?
>> Come gia' ci eravamo detti mi farebbe piacere venire qualche volta,
>> ma
>> durante la settimana e' piu' complicato.
Io sono d'accordo sul fatto di "rompere le palle" quando vengono scritte frasi del tipo "funziona ma non so perché". Anche se dette in modo provocatorio e/o scherzoso, far passare l'idea che "basta che funzioni" per me è moralmente sbagliato, e diciamolo, siamo veramente *pieni* di programmatori che tutti i giorni perseguono questa filosofia, con il bel risultato di progetti che non sono manutenibili.
PER ME un codice scritto male anche con il 100% di copertura di test, rimane un codice scritto male e il mio obiettivo è scriverlo bene.
Ciò detto questa è l'idea di un programmatore mediocre che tenta di seguire i percorsi di persone più brave sull'argomento e rispettando un insieme di regole di Clean Coding, quindi non ho autorità perché la mia opinione raccolga consensi.
L'importante e' il rispetto delle idee altrui; a qualcuno interessa la "barra verde" e A ME interessa il codice scritto bene, forse io sono più inconcludente e gli altri arrivano al risultato ma sono i risultati cercati che sono diversi, e il mio non è "fare bene il compitino" ;) Non sono arrivato alle 3 righe di cui parla Mario e vabbe' ci arriverò, l'importante è che sono arrivato a un codice di cui "non mi vergogno troppo" e confido nel fatto che il tempo speso a NON scrivere in java usando scala (sforzo, per me, discreto), mi tornerà utile.
ciao
P.S. La presunzione e la supponenza (se davvero ci sono, ma credo sia più errata comunicazione) io le ignoro ;)
Il giorno 25 settembre 2012 18:05, Mario Fusco <mario.fu...@gmail.com> ha
scritto:
> Questa discussione inizia ad essere un po' surreale per quanto mi
> riguarda, ma vado avanti anche per seguire il consiglio di Emiliano quando
> dice che: "nessuna questione e' troppo grande per non essere discussa".
I consigli sono ben accetti ma non significa che li si debba per forza
seguire ;)
Tornando a noi. Cercavo di non proseguire la discussione perche' non e' mia
la tesi dello "scrivo codice a caso e lo modifico a caso finche' non vado
in barra verde" quindi non mi interessa difenderla o discuterla piu' di
tanto.
Ho proposto la tesi secondo cui modificare il codice "a caso", in modo
esplorativo, non fosse necessariamente una cosa negativa (es.
jester<http://jester.sourceforge.net/>).
Inoltre, secondo me piu' interessante, che il confine tra "a caso" e "non a
caso" sia molto sfumato, cosi' come quello tra aver compreso il proprio
codice ed avere la convinzione di averlo compreso.
Ribadito questo, rispondo alla tua domanda parafrasandola: secondo te il
fatto di essere convinti di aver compreso completamente del codice e'
condizione necessaria e SUFFICIENTE perche' quel codice sia corretto?
Ciao
Lorenzo
PS
TDD e generazione/evoluzione di codice e' una cosa su cui stanno giocando
da un po', al momento non ho trovato i riferimenti. I risultati, qualche
anno fa, erano decisamente poco applicabili per l'uso pratico.
> Ho proposto la tesi secondo cui modificare il codice "a caso", in modo
esplorativo, non fosse necessariamente una cosa negativa (es. jester).
Inoltre, secondo me piu' interessante, che il confine tra "a caso" e "non a
caso" sia molto sfumato, cosi' come quello tra aver compreso il proprio
codice ed avere la convinzione di averlo compreso.
Non c'è niente di sfumato. O lo hai capito al 100% o non l'hai capito.
> Ribadito questo, rispondo alla tua domanda parafrasandola: secondo te il
fatto di essere convinti di aver compreso completamente del codice e'
condizione necessaria e SUFFICIENTE perche' quel codice sia corretto?
Per 3 righe di codice fetenti ( perché di questo stiamo parlando ) sì. Per
casi più complessi non esiste una condizione sufficiente, ma avere la piena
comprensione di come funziona il tuo codice è sempre una condizione
necessaria.
> TDD e generazione/evoluzione di codice e' una cosa su cui stanno giocando
da un po', al momento non ho trovato i riferimenti. I risultati, qualche
anno fa, erano decisamente poco applicabili per l'uso pratico.
Spero di essere andato in pensione prima che diventino applicabili.
> > TDD e generazione/evoluzione di codice e' una cosa su cui stanno > giocando da un po', al momento non ho trovato i riferimenti. I risultati, > qualche anno fa, erano decisamente poco applicabili per l'uso pratico.
> Spero di essere andato in pensione prima che diventino applicabili.
Scusa Mario, che vuoi dire? Perche' non capisco se e' ironica o meno (nel senso che non riconosci il TDD di Lorenzo come il TDD come lo intendi tu)
Io ho poca esperienza con TDD perche' in effetti conciliarla con la * produzione* di codice mi risulta ancora difficile. So che dovrei cominciare con i test e poi sviluppare codice, ma nello stesso tempo mi si chiede di essere produttivo e ancora non sono in un ambiente in cui fare i test equivalga a essere produttivi e per la mia mentalita' preferisco fare refactory se ho un po' di tempo in piu' (anche se tendo a scrivere pulito da subito, cosa che mi e' stata rimproverata). Comunque e' una questione su cui sto lavorando. Seppure persone come Robert C. Martin dicano di *rifiutarsi* di fare cose che si sanno sbagliate (tipo non fare i test prima del codice o trovare il tempo per fare refactory) non sono ancora a un livello contrattuale per cui la cosa possa essere per me realizzabile. Voi come gestite la cosa? Siete sempre dentro i tempi per cui riuscite a fare TDD e refactory sempre, oppure no?
"Suggerisco di scrivere solo i test e poi far girare un bell'algoritmo genetico che generi milioni di programmi a caso finchè non ce n'è uno che faccia passare tutti i test. Che ne dite?"
Dico che questo è un campo d'indagine niente male, e potrebbe dare interessanti futuribili prospettive. Non è, purtroppo o per fortuna, il modo in cui possiamo lavorare oggi.
Per tutto il resto Mario credo che tu stia facendo tutto da solo: ipotesi, tesi e confutazione.
Sono pronto a scommetterci qualunque cosa che non esiste una solo persona all'interno del gruppo che abbia una sola delle possibili permutazioni delle seguenti tue dichiarate assunzioni:
- essere un Guru
- essere un Guru del TDD
- pensare che il TDD sia un'attività decerebrata e meccanica
- pensare di decidere di investire il proprio tempo a gratis per seguire un corso con l'idea di non voler imparare nulla di nuovo
Ora, essendo questo un corso di Scala, mi rifocalizzarei sull'argomento. Ma visto che Odersky ci propone di risolvere i quesiti in TDD, continuerò a seguire l'indirizzo del corso.
Quando deciderò di seguire un corso di Mario Fusco (così come ho già seguito con entusiasmo e interesse in passato sue conference), mi adeguerò rigorosamente, se ne sarò in grado, agli standard del corso.
On Tuesday, September 25, 2012 6:05:28 PM UTC+2, Mario Fusco wrote:
> Questa discussione inizia ad essere un po' surreale per quanto mi > riguarda, ma vado avanti anche per seguire il consiglio di Emiliano quando > dice che: "nessuna questione e' troppo grande per non essere discussa".
> Giusto per dare un po' di contesto alla cosa riporto fedelmente 2 frasette > scritte da Lorenzo in una mail precedente:
> " Ho lanciato i test i passavano tutti tranne quello della lista non > sortata. A quel punto in qualche modo ho intuito che mancasse un'altra > ricorsione ma aggiungendola dove mi sembrava sensato non ha funzionato. > Allora l'ho aggiunta "a caso" nell'unico altro posto possibile e...tada': > barra verde.
> Ho poi perso una buona mezz'ora tentando di seguire mentalmente tutto il > flusso ma non ci sono riuscito e per me dovrebbe trovare un numero > superiore di combinazioni. Pero' non sono riuscito ne' a trovare > alternative per me piu' chiare ne' a romperlo. Quindi sono andato a dormire > e la mattina dopo ho "committato". "
> Punto primo: come ho già scritto precedentemente il fatto che la lista in > questione sia ordinata o meno è totalmente irrilevante ai fini della > corretta risoluzione del problema. Se non si è capito questo si è già fuori > strada.
> Punto secondo (e più importante): siccome non ho visto la soluzione di > Lorenzo non posso dire se sia giusta o sbagliata (per "giusta" intendo sia > formalmente corretta che concisa ed elegante se possibile, altrimenti > inutile impegnarsi a usare Scala e tanto vale sviluppare in Fortran), ma > non è questo il punto. Il punto è che ammesso e non concesso che funzioni, > per sua stessa ammissione, non sa nemmeno lui perchè!
> Ora, voi che siete guru del TDD, secondo voi il fatto di aver fatto > comparire quella maledetta barra verde è condizione necessaria e > SUFFICIENTE per considerare un determinato compito concluso con successo? > Se è così chi ce lo fa fare di scrivere il codice? Suggerisco di scrivere > solo i test e poi far girare un bell'algoritmo genetico che generi milioni > di programmi a caso finchè non ce n'è uno che faccia passare tutti i test. > Che ne dite?
> Io sono pro-TDD, ma se la vostra definizione di TDD somiglia a quella che > ho scritto sopra allora sono decisamente contro.
>> non voglio affatto entrare nel conflitto fanatici-pro e fanatici-contro >> il TDD (o qualunque argomento vi si possa sostiture).
>> Ammetto (sto battendo tre volte il pugno sul petto, candenzando con >> altrettanti mea culpa) che, conoscendo personalmente alcune persone del >> gruppo, mi sono permesso un lieve e divertita (con la fallace speranza che >> fosse anche divertente) provocazione sul TDD.
>> Lorenzo, seppure inascoltato, ha descritto perfettamente quello che può >> (non deve) essere un percorso creativo/matematico possibile nella souzione >> di un problema.
>> L'idea di muoversi avanti indietro tra l'input e l'output di un problema >> dato, il cercare di affrontarlo da diversi punti di vista (mi metto ai >> morsetti, mi metto in un punto preciso, lo faccio fallire volutamente, mi >> metto ai valori limite), ridurlo a condizioni ottimali (provo ad >> affrontarlo prima in modo iterativo, provo il caso degenere), ricondursi a >> pattern già noti (la maledetta esperienza tanto vantata, ma poi così poco >> tenuta da conto) sono tutti elementi che fanno parte del processo di >> problem solving.
>> Se dopo avere fatto tutta sta roba, ho tutti i miei test in barra >> verde...quali altri problemi dovrei pormi? Perchè dovrei mettermi a >> debuggare il codice passo passo per vedere cosa succede? Lo so già, perché >> lo costruito io perché funzionasse così, e ci sono i test che ho scrito che >> definiscono come deve funzionare. E questo per me risponde definitivamente >> all'innocente provocazione.
>> Ma ne riapre un'altra: poteva attecchire tale provocazione senza un >> terreno fertile di presunzione e supponenza?
>> Lo dico davvero senza offesa per nessuno. È una domanda aperta che invito >> tutti a tenere presente, ogni volta che viene voglia di demolire la >> preparazione, intelligenza, impegno, costanza, capacità, serietà, durezza, >> purezza e qualsivoglia proprietà consideriate indispensabili per essere il >> Vero Programmatore, di una persona che non si conosce e solo per una mezza >> cosa che nemmeno si è capita.
>> Con affetto.
>> Vittorio
>> Il giorno 25 settembre 2012 16:12, <sug...@googlegroups.com <javascript:>
>> > ha scritto:
>>> - [POLL] Chi fa il corso di functional programming di coursera?<#CAPYjU_n8xmWcLZRC3fmJyxSYbEcT2hscTXDEJ-fD2ODzRzB...@mail.gmail.com_139fe0c0d8d4101c_139fdc5cf7f604a7_group_thread_0>[39 Updates] >>> - Offerta di lavoro: Scala Developer at MoneyFarm<#CAPYjU_n8xmWcLZRC3fmJyxSYbEcT2hscTXDEJ-fD2ODzRzB...@mail.gmail.com_139fe0c0d8d4101c_139fdc5cf7f604a7_group_thread_1>[1 Update]
>>> anche io sto tribolando col 3° esercizio. Se riuscirò a finirlo
>>> probabilmente anche io non saprò perché funziona. :-)
>>> A volte con l'approccio TDD in CountChangeSuite finisco per ...more<http://groups.google.com/group/sug-it/msg/3c7004d7de3dcbcb>
>>> Il primo e il secondo li ho fatti in un paio d'ore ciascuno, ma il >>> terzo mi >>> fa penare. Su internet ho trovato cose sulla memoization ma sto >>> battendo >>> un'altra strada.
>>> Con il primo test ...more<http://groups.google.com/group/sug-it/msg/d5ad7cb2ec6b9f2d>
>>> Ho fatto i primi due esercizi ieri sera. Non ho ancora affrontato il >>> terzo. >>> In realtà anch' io tendo ad operare in TDD, quindi ho i test in >>> barra >>> verde...ma non ...more<http://groups.google.com/group/sug-it/msg/c2fc6b9c2705bb4b>
>>> A me del corso in realta' non interessa molto (voglio dire il >>> punteggio e >>> il documento di fine corso), la cosa che veramente mi interessa e' >>> *sapere >>> perche' funziona*; anzi a dire il vero avrei il ...more<http://groups.google.com/group/sug-it/msg/8c9bcf92587c3da6>
> > TDD e generazione/evoluzione di codice e' una cosa su cui stanno
>> giocando da un po', al momento non ho trovato i riferimenti. I risultati,
>> qualche anno fa, erano decisamente poco applicabili per l'uso pratico.
>> Spero di essere andato in pensione prima che diventino applicabili.
> Scusa Mario, che vuoi dire? Perche' non capisco se e' ironica o meno (nel
> senso che non riconosci il TDD di Lorenzo come il TDD come lo intendi tu)
Il TDD come l'intendo io è scrivo i test prima di implementare una nuova
feature perchè:
1. mi aiuta a definire meglio cosa sto per iniziare a fare
2. mi costringe a ragionare su quali potrebbero essere i possibili corner
cases
3. (se applicabile) mi fa usare la nuova API che ho definito prima ancora
che sia implementata consentendomi di capire se è comoda da usare o no. Ad
esempio se un costruttore ha troppi parametri e mi rendo conto che anche io
non ne ricordo la sequenza esatta posso decidere di mitigare il problema
con una factory; se mi capita spesso di invocare più metodi in sequenza su
uno stesso oggetto posso trovare comodo aggiungere una fluent interface, e
così via. Insomma assaggio il cibo che sto cucinando prima di servirlo in
tavola ai miei commensali (gli utilizzatori finali dell'API)
4. mi consente di validare ciò che ho fatto
5. mi offre una rete di sicurezza in più nel caso voglia rifattorizzarlo in
un secondo tempo
Riguardo al punto 4. (che è il punto nodale delle mail precedenti) il fatto
che tutti test siamo positivi non mi esime dalla necessità di avere la
piena comprensione di come funziona il codice che ho appena scritto. Questo
perchè far apparire la barra verde è condizione necessaria ma non
sufficiente affinchè il codice sia corretto. Chi la pensa diversamente
confonde l'assenza di prova di una tesi (assenza di un test fallito) con la
presenza della prova della tesi opposta (codice corretto). A chi non è
chiara la differenza fra le due cose consiglio di leggersi il "Cigno Nero"
(un libro di economia in realtà):
> "Suggerisco di scrivere solo i test e poi far girare un bell'algoritmo
> genetico che generi milioni di programmi a caso finchè non ce n'è uno che
> faccia passare tutti i test. Che ne dite?"
> Dico che questo è un campo d'indagine niente male, e potrebbe dare
> interessanti futuribili prospettive. Non è, purtroppo o per fortuna, il
> modo in cui possiamo lavorare oggi.
> Per tutto il resto Mario credo che tu stia facendo tutto da solo: ipotesi,
> tesi e confutazione.
L'ipotesi e la tesi, almeno quelle che ho capito io, sono:
"Siccome ho il test in barra verde vuol dire che sta funzionando (e non mi
preoccupo più di tanto di capire perchè)".
Se ho capito bene non mi stancherò mai di provare a confutare quanto sopra.
Se ho sbagliato a capire vuol dire che ho alzato un polverone inutile e me
ne scuso.
Peraltro capire (profondamente) quello che si sta facendo è in questo caso
ancora più importante proprio perchè stiamo seguendo un corso su un
argomento nuovo per tutti noi.
Concordo con il fatto che ho (abbiamo) divagato un po' troppo rispetto
all'argomento del thread (il corso) e della lista (Scala), ma credo sia
stata una discussione interessante, quindi perchè non farla?
Ora però, visto che la seconda settimana è già online, conviene tornare al
corso :)
> Voi come gestite la cosa? Siete sempre dentro i tempi per cui riuscite a >> fare TDD e refactory sempre, oppure no?
> Il tempo dedicato al TDD non è mai tempo perso. I punti che ho scritto > sopra dovrebbero spiegare perchè.
Io so perfettamente che non e' tempo perso, ho chiesto se pero' riuscite ad applicarlo al lavoro di tutti i giorni. Come so perfettamente che bisognerebbe fare il refactory continuamente e a scadenze fisse, come so perfettamente che bisognerebbe avere iterazioni settimanali (massimo ogni due settimane) sui progetti che si seguono, come so perfettamente che sarebbe necessario lavorare in pair-programming... la mia domanda pero' e' precisa e ora la estendo:
- riuscite a fare tdd nel lavoro di tutti i giorni?
- riuscite a fare refactory nel lavoro di tutti i giorni?
- riuscite a fare iterazioni ogni settimana?
E soprattutto se non ci riuscite, vi interesserebbe o preferite un approccio senza tdd, iterazioni e refactory?
Faccio un esempio sono a 3 giorni da un rilascio: applico il tdd per ogni regression/feature?
P.S. Per favore leggere attentamente quanto ho scritto prima di rispondere ;)
> Io so perfettamente che non e' tempo perso, ho chiesto se pero' riuscite
> ad applicarlo al lavoro di tutti i giorni. Come so perfettamente che
> bisognerebbe fare il refactory continuamente e a scadenze fisse, come so
> perfettamente che bisognerebbe avere iterazioni settimanali (massimo ogni
> due settimane) sui progetti che si seguono, come so perfettamente che
> sarebbe necessario lavorare in pair-programming... la mia domanda pero' e'
> precisa e ora la estendo:
> - riuscite a fare tdd nel lavoro di tutti i giorni?
> - riuscite a fare refactory nel lavoro di tutti i giorni?
> - riuscite a fare iterazioni ogni settimana?
> E soprattutto se non ci riuscite, vi interesserebbe o preferite un
> approccio senza tdd, iterazioni e refactory?
> Faccio un esempio sono a 3 giorni da un rilascio: applico il tdd per ogni
> regression/feature?
Faccio un po' di fatica a risponderti perchè per quello che mi sembra di
capire le condizioni al contorno della mia situazione lavorativa sono (per
fortuna) diverse dalle tue.
Per me la frase "sono a 3 giorni dal rilascio e ..." è già di per se
assurda. In tutti i lavori che ho fatto, e specialmente ora che lavoro su
un software open source, il rilascio non è fra 3 giorni semplicemente
perchè c'è qualcuno, in genere totalmente avulso dalla parte tecnica, che
ha deciso così. Il rilascio si fa quando io e le altre persone che lavorano
nel mio stesso team siamo d'accordo di essere nelle condizioni di
rilasciare. Punto.
Viste queste premesse le risposte alle tue domande vengono di conseguenza
ma ho paura che non si adattino al tuo caso.
Spero ci sia qualcun'altro partecipante a questa mailing list che possa
esserti di aiuto un po' più di me.
> Io so perfettamente che non e' tempo perso, ho chiesto se pero' riuscite
> ad applicarlo al lavoro di tutti i giorni. Come so perfettamente che
> bisognerebbe fare il refactory continuamente e a scadenze fisse, come so
> perfettamente che bisognerebbe avere iterazioni settimanali (massimo ogni
> due settimane) sui progetti che si seguono, come so perfettamente che
> sarebbe necessario lavorare in pair-programming... la mia domanda pero' e'
> precisa e ora la estendo:
> - riuscite a fare tdd nel lavoro di tutti i giorni?
> - riuscite a fare refactory nel lavoro di tutti i giorni?
> - riuscite a fare iterazioni ogni settimana?
> E soprattutto se non ci riuscite, vi interesserebbe o preferite un
> approccio senza tdd, iterazioni e refactory?
In primis ti chiedo gentilmente di chiamarlo "refactor" o al massimo
"refactoring" senno', come direbbe Mario, "mi sento male" (vedi: tratti ^^).
Io assolutamente faccio refactoring tutti i giorni, in base allo stato
dell'architettura e al cambiamento che ho bisogno di fare. A dire la
verita' e' un po' un problema perche', essendo anche madrelingua inglese,
se trovo codice con un (a mio parere) pessimo nome mi distrae troppo e non
riesco a capire il codice finche non lo "sistemo"..
Per quanto riguarda il TDD, sui progetti piu' recenti, no, pero' in passato
si, l'ho usato, pero' assolutamente non il TDD puro. In realta' io non sono
tanto pro-TDD, quanto pro test automatizzati e ripetibili. Credo che la
filosofia prima-test-poi-implementazione storce l'architettura, magari
anche in modo piu' snella (es. meno classi), pero' non modo in cui la
disegnerei e modellerei io.
Per quanto riguarda le iterazioni.. dipende da tanti fattori, alcuni
progetti ho fatto rilasci ogni settimana, altri un unico rilascio dopo
mesi.. :)
