Re: [sug-it] Abridged summary of sug-it@googlegroups.com - 40 Messages in 2 Topics

[Vittorio Scibetta]

Scusate,

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> ha scritto:

  Today's Topic Summary

Group: http://groups.google.com/group/sug-it/topics

• [POLL] Chi fa il corso di functional programming di coursera? [39 Updates]
• Offerta di lavoro: Scala Developer at MoneyFarm [1 Update]

 [POLL] Chi fa il corso di functional programming di coursera?

Raoul Buzziol <rao...@gmail.com> Sep 24 03:39PM +0200  

Ciao,
 
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

Emiliano Anichini <emiliano...@gmail.com> Sep 24 06:49AM -0700  

Salve.
 
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

Raoul Buzziol <rao...@gmail.com> Sep 24 04:11PM +0200  

Il 24 settembre 2012 15:49, Emiliano Anichini
> di risultati....
 
> Comunque il fatto che non ci sia un debug serio sullo scalaide, sega le
> gambe...
 
Però ha i suoi lati positivi. ...more

TheViki <vittorio...@gmail.com> Sep 24 07:13AM -0700  

Io sto seguendo il corso.
 
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

Ivano Pagano <ivano....@gmail.com> Sep 24 07:54AM -0700  

Ciao a tutti,
Ivano da Roma
 
Il terzo esercizio mi ha fatto penare parecchio, pensavo che mi mancassero
le necessarie conoscenze algoritmiche (non ho studiato informatica...) e ...more

Emiliano Anichini <emiliano...@gmail.com> Sep 24 07:55AM -0700  

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

Ivano Pagano <ivano....@gmail.com> Sep 24 07:56AM -0700  

Scusate ma non riesco a capire, come avete fatto a scrivere una soluzione
senza capire come funziona?
 
Ivano
 
On Monday, September 24, 2012 4:13:20 PM UTC+2, TheViki wrote:
...more

Emiliano Anichini <emiliano...@gmail.com> Sep 24 08:45AM -0700  

Beh, un modo puo' essere tradurre la grammatica di un programma gia' fatto
da java a scala :P
Poi ci sono i modi meno puliti...
 
 
On Monday, September 24, 2012 4:56:02 PM UTC+2, Ivano Pagano ...more

Lorenzo Bolzani <l.bo...@gmail.com> Sep 24 06:53PM +0200  

Il giorno 24 settembre 2012 16:56, Ivano Pagano <ivano....@gmail.com> ha
scritto:
 
> Scusate ma non riesco a capire, come avete fatto a scrivere una soluzione
> senza capire come funziona?
...more

Mario Fusco <mario...@gmail.com> Sep 24 06:58PM +0200  

Anche io sono a Milano e disponibile per un incontro.
Per ora non ho avuto grossi problemi con i 3 esercizietti proposti.
 
Per quelli di Milano, ho in programma di fare al JUG un mini-corso su ...more

Ivano Pagano <ivano....@gmail.com> Sep 24 10:00AM -0700  

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

Ivano Pagano <ivano....@gmail.com> Sep 24 10:02AM -0700  

Ok, grazie per il chiarimento, comincio a capire.
 
On Monday, September 24, 2012 6:53:18 PM UTC+2, lorenzo wrote:
...more

Ivano Pagano <ivano....@gmail.com> Sep 24 10:04AM -0700  

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.
 
Comunque teneteci aggiornati ...more

Mario Fusco <mario...@gmail.com> Sep 24 07:07PM +0200  

Sì comincio a capre anche io e quello che ho capito non mi piace affatto.
 
Quindi per voi TDD vuol dire scrivere il test e poi permutare
randomicamente gli statements della vostra soluzione di ...more

Mario Fusco <mario...@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

Lorenzo Bolzani <l.bo...@gmail.com> Sep 24 07:49PM +0200  

Il giorno 24 settembre 2012 19:07, Mario Fusco <mario...@gmail.com> ha
scritto:
 
> randomicamente gli statements della vostra soluzione di partenza finche il
> test non passa? Senza poi nemmeno ...more

Mario Fusco <mario...@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

Lorenzo Bolzani <l.bo...@gmail.com> Sep 24 09:21PM +0200  

Il giorno 24 settembre 2012 19:59, Mario Fusco <mario...@gmail.com> ha
scritto:
 
> codice senza avere la totale consapevolezza del perchè lo si sta facendo ma
> solo nella speranza di veder ...more

Mario Fusco <mario...@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.
 
2012/9/24 Lorenzo Bolzani ...more

Lorenzo Bolzani <l.bo...@gmail.com> Sep 24 11:24PM +0200  

Il giorno 24 settembre 2012 22:12, Mario Fusco <mario...@gmail.com> ha
scritto:
 
> Preferirei non continuare questa discussione, ma ti consiglio di rileggere
> quello che hai scritto: fa ...more

Emiliano Anichini <emiliano...@gmail.com> Sep 25 12:58AM -0700  

Si, vero, alcune volte lo faccio anche io ma quando sono in uno stato
preciso: DISPERAZIONE
Alcune volte non capisci proprio perche' non funziona e allora, non avendo
piu' banane, metti chiamate ...more

Emiliano Anichini <emiliano...@gmail.com> Sep 25 12:59AM -0700  

Si, vero, alcune volte lo faccio anche io ma quando sono in uno stato
preciso: DISPERAZIONE
Alcune volte non capisci proprio perche' non funziona e allora, non avendo
piu' banane, metti chiamate ...more

Lorenzo Bolzani <l.bo...@gmail.com> Sep 25 11:15AM +0200  

Il giorno 25 settembre 2012 09:58, Emiliano Anichini <
> (che ogni volta che devi riaffrontare comporta molta fatica), se cosi' non
> e', beh, o sei fortunato o hai la parte del cervello che lavora ...more

Mario Fusco <mario...@gmail.com> Sep 25 11:17AM +0200  

>> al tesoro.
 
> Come preferisci.
 
> Ciao
 
Premetto che non voglio fare gare, ma se è possibile dimostrarti che
fermarsi un attimo a ragionare invece di provare roba a caso aiuta molto di ...more

Mario Fusco <mario...@gmail.com> Sep 25 11:25AM +0200  

> raggiunta attraverso un procedimento "presunto razionale" piuttosto che
> tramite uno "pseudo casuale". Dovrebbero essere trattate entrambe con la
> stessa cautela.
 
Continuo a non essere ...more

Raoul Buzziol <rao...@gmail.com> Sep 25 12:27PM +0200  

> dubbio che le mie soluzioni sono corrette proprio perchè prima di iniziare a
> scrievere codice ho pensato a come volevo risolvere il problema e quindi ho
> la piena comprensione del perchè ...more

Mario Fusco <mario...@gmail.com> Sep 25 12:39PM +0200  

> dell'ultimo esercizio) non escono si entra in modalità DISPERAZIONE e
> inizio a fare anche io come Emiliano... e generalmente vengo castigato
> perché non vado da nessuna parte.
...more

Emiliano Anichini <emiliano...@gmail.com> Sep 25 04:07AM -0700  


> Continuo a non essere d'accordo, almeno per problemi che richiedono 3
> righe di codice come quelli proposti negli esercizi (se li hai risolti con
> più di 3 righe c'è qualcosa che non va) ...more

Mario Fusco <mario...@gmail.com> Sep 25 01:23PM +0200  

> ...Hem. Io forse direi che "se li hai risolti con piu di tre righe di
> codice il corso che stiamo facendo fa al caso tuo", suona meglio solo a me?
> Giusto per non demoralizzarmi :(
...more

Emiliano Anichini <emiliano...@gmail.com> Sep 25 05:05AM -0700  

On Tuesday, September 25, 2012 1:23:50 PM UTC+2, Mario Fusco wrote:
 
> Ho paura che non sia così. Nel caso di quei 3 problemini penso davvero che
> se li hai risolti con più di 3 righe ciascuno ...more

Lorenzo Bolzani <l.bo...@gmail.com> Sep 25 02:39PM +0200  

Il giorno 25 settembre 2012 11:17, Mario Fusco <mario...@gmail.com> ha
scritto:
 
 
> Premetto che non voglio fare gare, ma se è possibile dimostrarti che
> fermarsi un attimo a ragionare ...more

Mario Fusco <mario...@gmail.com> Sep 25 02:41PM +0200  

> programmatore mediocre (quale io sono) cerca di seguire un corso su un
> linguaggio nuovo cercando di capire un nuovo paradigma, beh, non fa male a
> nessuno (se non a se stesso :P )
...more

Dale Wijnand <dale.w...@gmail.com> Sep 25 02:44PM +0200  

Attenzione, la scadenza "definitiva" (hard due date), e' stata spostata a
martedi' 2 ottobre.
 
Dale
 
2012/9/25 Lorenzo Bolzani <l.bo...@gmail.com>
 
...more

Mario Fusco <mario...@gmail.com> Sep 25 02:46PM +0200  


> Penso che la questione sia diventata un po' piu' grande di quello che e'.
> Tra tre giorni, alla scadenza definitiva, posto il codice e possiamo
> vederlo qui.
 
Hai ragione, mi sa che la ...more

mfirry <zentr...@yahoo.co.uk> Sep 25 05:47AM -0700  

(mi permetto di rispondere in maniera più letterale all'oggetto della mail)
 
Sì, anche io sto seguendo il corso. la prima settimana ho faticato non poco
soprattutto per gli esercizi 2 e 3. ...more

Dale Wijnand <dale.w...@gmail.com> Sep 25 02:48PM +0200  

Confermo, ma per me con l'esercizio. Ho risolto piu' in testa in un ora e
mezza di palestra che _non_ sono riuscito a capire in 4 ore sulla scrivania
davanti a REPL e IDE..
 
2012/9/25 Mario Fusco ...more

Emiliano Anichini <emiliano...@gmail.com> Sep 25 05:52AM -0700  

>> nessuno (se non a se stesso :P )
 
> Non ho mai detto di voler evangelizzare qualcosa (ne sono nella posizione
> per farlo).
 
Ah, allora ho male interpretato la frase: "Per quanto mi riguarda ...more

Mario Fusco <mario...@gmail.com> Sep 25 02:54PM +0200  

> Confermo, ma per me con l'esercizio. Ho risolto piu' in testa in un ora e
> mezza di palestra che _non_ sono riuscito a capire in 4 ore sulla scrivania
> davanti a REPL e IDE..
...more

Mario Fusco <mario...@gmail.com> Sep 25 03:01PM +0200  

> Ah, allora ho male interpretato la frase: "Per quanto mi riguarda è il mio
> (ulteriore) tentativo di far conoscere e diffondere un po' Scala fra gli
> Javisti." del tuo primo post.
...more

 Offerta di lavoro: Scala Developer at MoneyFarm

Slacabos <slac...@gmail.com> Sep 25 04:32AM -0700  

Ciao a tutti,
A MoneyFarm stiamo cercando uno scala developer.
Qui trovate tutti i dettagli della
posizione http://job.moneyfarm.com/job/detail/10734-scala-developer
 
Aspettiamo i vostri CV ;)
...more

You received this message because you are subscribed to the Google Group sug-it.
You can post via email.
To unsubscribe from this group, send an empty message.
For more options, visit this group.

--
You received this message because you are subscribed to the Google Groups "sug-it" group.
To post to this group, send email to sug...@googlegroups.com.
To unsubscribe from this group, send email to sug-it+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sug-it?hl=en.

[Mario Fusco]

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.

Mario

2012/9/25 Vittorio Scibetta <vittorio...@gmail.com>

[Emiliano Anichini]

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  ;)

[Lorenzo Bolzani]

Il giorno 25 settembre 2012 18:05, Mario Fusco <mario...@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). 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.

[Mario Fusco]

> 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.

[Emiliano Anichini]

> 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?

[Lorenzo Bolzani]

Il giorno 26 settembre 2012 10:27, Emiliano Anichini <emiliano...@gmail.com> ha scritto:

Voi come gestite la cosa? Siete sempre dentro i tempi per cui riuscite a fare TDD e refactory sempre, oppure no?

Visto che non c'e' molto traffico qualche off-topic secondo me non e' un problema, ma forse qui il discorso rischia di divergere parecchio.

Ciao

Lorenzo

[Emiliano Anichini]

Scusate se sono off-topic ma non ho capito bene quale sia il topic del thread :P

ciao

[Lorenzo Bolzani]

Il giorno 26 settembre 2012 11:45, Emiliano Anichini <emiliano...@gmail.com> ha scritto:

Scusate se sono off-topic ma non ho capito bene quale sia il topic del thread :P

Il thread ha un po' divagato, ma il suo topic rimane il corso scala su Coursera  e il topic della lista rimane scala.


Ciao

Lorenzo

[TheViki]

"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.

Saluti.

Vittorio

[Mario Fusco]

> 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à):

http://www.amazon.it/cigno-nero-limprobabile-governa-nostra/dp/8856501198/ref=sr_1_2?ie=UTF8&qid=1348666006&sr=8-2
 

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è.

[Mario Fusco]

"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.

A me ricorda questo: http://en.wikipedia.org/wiki/Infinite_monkey_theorem
 

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 :)

Buon Scala a tutti,
Mario

[Emiliano Anichini]

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  ;)

[Mario Fusco]

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.

[Dale Wijnand]

2012/9/26 Emiliano Anichini <emiliano...@gmail.com>

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.. :)

Dale