[XNA] Creare un videogame

[jappilas]

Originariamente inviato da MEMon

hahah hai ragione!
Comunque salvo casi particolari i commenti al mio codice non portano nessuna informazione in più.
Roba del tipo

tabella.inserisciUnaNuovaColonna(nomeColonna,valore)

Giusto per farti capire, un commento a cosa serve?
La commenterei così: questo metodo inserisce una nuova colonna nella tabella.

io la commenterei pressapoco (a titolo esemplificativo) così :

/* Complessità: algoritmica: O(n),  ciclomatica: 11 (attenzione - il metodo attualmente viola la coding guideline) 
*  WARNING: la condizione d' inserimento  a sinistra della prima colonna non è coperta dai test
*  TODO: scrivere test case esaustivi, rifattorizzare per ridurre i code path
*/ 
void Tabella::inserisciUnaNuovaColonna(nomeColonna,valore);

i commenti interni al metodo riguardanti quello che il metodo stesso fa, devono (dovrebbero) tendere a zero
commenti in testa o in certi casi, frammezzati, che riportano metriche SUL codice, o avvertenze operative, o di naming, o "perchè si è scritta quella cosa" a volte servono

[71104]

Originariamente inviato da PGI-Bis

Ci sono una paio di cose che mi trattengono dal partecipare a Diamonds. Giusto due pinzillacchere.

leggendo quelle che hai scritto posso dire che ne manca una (sempre una fesseria, ma mi piace essere pignolo... ): il progetto è fallito

Non uso IDE (ecplise, netbeans aut similia),

pessimo, pessimo... da quando uso Eclipse per il progetto di Programmazione di Rete la mia produttività si è centuplicata. il training iniziale per imparare ad usarlo è durato pochissimo quando lo feci a suo tempo per lavorare a Diamond Crush.

non approvo il TDD,

ci posso anche stare: tutto sommato non so quanto valga la pena di scrivere tutti quei test che raddoppiano il tempo di scrittura del codice e costituiscono un'arma a doppio taglio quando ti ritrovi test che non hai più la minima idea di cosa c***o testassero...

non uso [...] ant,

usarlo senza IDE credo sia un attimino una rottura

subversion, cvs,

non hai neanche idea di cosa sono... :|
i sistemi di concurrent versioning per me da quando li ho scoperti sono l'ottava meraviglia, i progetti a gruppi che faccio all'università li faccio sempre usando un repository.

non moccko,

conseguenza diretta del non approvare il TDD. ma approvandolo, mockare è necessario perché altrimenti (lo dico per esperienza diretta) vengono fuori dei test nauseanti e totalmente irrispettosi delle buone regole di black box testing. vuoi sapere la mia? sono quelli che hanno ucciso Diamonds. ci credi che è colpa loro? credici, te l'assicuro.

Per ogni linea di codice scrivo un romanzo di commenti e per ogni due un PDF a parte che spiega perchè ho usato la lettera 'a' anzichè 'b'.

in tal caso non ha senso disprezzare il TDD: in quel modo il tempo di scrittura del codice si CENTUPLICA mentre il TDD te lo raddoppia soltanto

A scrivere il codice basta che sia uno, per tutti. Poi ci vuole qualcuno che scriva la documentazione a latere. Tutti leggono, propongono, discutono ma nessuno parla di "codice" salvo il gorilla che digita.

questa è un'idea molto interessante... però devi ammettere che al crescere della complessità del software tende a non essere una soluzione applicabile... te la immagini una sola persona a scrivere un sistema operativo?
e aivoja a proporre e sfornare idee...

Ora, poichè Diamonds non è un progetto che mira a scrivere un videogioco ma ha come obiettivo un modello di sviluppo del software, il TDD, a me pare che il modo in cui io interverrei per portarlo a termine (tabula rasa di tutto salvo gli artworks e le idee) non sia proponibile. Anche perchè sta malissimo dire "il progetto, iniziato come TDD, è stato portato a termine dopo aver abbadonato refactoring, test e str... del genere" .

eppure temo che per portarlo realmente a termine il TDD andrebbe veramente eliminato: oppure dovresti contare che tutto il team magicamente impari a scrivere test decenti, rispettosi del black box testing, chiari, brevi, esaustivi, e mockati.

[71104]

Originariamente inviato da MEMon

Io ho un viziaccio, non commento mai nulla, ma quando vado a ripescare codice MIO vecchio mi ci trovo sempre subito.
C'è da dire che quando scrivo del codice lo scrivo in modo molto "logico" praticamente scrivo codice che si autocommenta da solo.

Però so che è un brutto vixzio, dovrei iniziare pure io a scrivere commenti...

io non la penso così, visto che faccio anche io come te... alla fine l'importante è ritrovarcisi dopo tanto.

[PGI-Bis]

A me l'idea di usare un altro pezzo del programma per documentare un metodo sa di bizarre. Un po' lo dico qui, un po' lo dico là. Mi parrebbe meglio tentare di esprimere il significato in un punto solo. E farlo usando una convenzione che certamente il lettore possiede, cioè quella della lingua umana scritta da lui parlata. Che è fatta di una marea di regole tra semantica, sintassi e, trattandosi di scritto, geometrie. Io non so se esista un linguaggio di programmazione che consenta di mimare queste regole. So per certo che Java non gli si avvicina neanche ad un kilometro. Smalltalk è un po' più vicino, più che altro per la sua capacità di intromettere i nomi dei parametri nel descrittore del metodo:

somma a con: b

valore := somma 1 con: 2

Vale a dire che un metodo Smalltalk offre l'opportunità di modellare l'invocazione su un pattern comune delle lingue scritte occidentali. Non penso sia un caso che Fowler sia un reduce dell'utopia Smalltalk.

Per quanto riguarda il test in sè è bacato in radice da un ineliminabile regressio ad infinitum: prima del test devi scrivere il test del test, che richiede il test del test del test e via dicendo. Senza questa serie infinita un test ti da le stesse garanzie di nessun test.

Non che sia un cosa tanto grave. Non è meno strambo di tante altre teorie sullo sviluppo. Anzi, è proprio questo suo non essere nè più ne meno strambo a rendere l'XP indifferente.

[PGI-Bis]

Originariamente inviato da 71104

questa è un'idea molto interessante... però devi ammettere che al crescere della complessità del software tende a non essere una soluzione applicabile... te la immagini una sola persona a scrivere un sistema operativo?
e aivoja a proporre e sfornare idee...

Tu guarda a volte il caso. Ma sai dove ho trovato l'ispirazione del "Soviet Driven Development" ? Dai, prova a buttarla lì! Libro e autore famosissimo, una volta litigò con tal Torvalds...

[cionci]

Originariamente inviato da PGI-Bis

Per quanto riguarda il test in sè è bacato in radice da un ineliminabile regressio ad infinitum: prima del test devi scrivere il test del test, che richiede il test del test del test e via dicendo. Senza questa serie infinita un test ti da le stesse garanzie di nessun test.

Se si scrive un test dal niente è chiaro che possa essere così, ma nel TDD il test non lo si scrive dal niente: si evolve con il codice. Un test deve fallire prima di poter essere base per l'evoluzione del codice che testa ! Se il test passa o è un test superfluo o è un test errato
E il fallimento del test deve provocare una minima variazione del codice per far passare il test. E' chiaro che se il test che fallisce è sbagliato devo inserire codice sbagliato per farlo passare. Quindi è il codice stesso che verifica la correttezza del test ed è il test che verifica la correttezza del codice. Si procede quindi su due binari paralleli fino ad arrivare alla versione finale del test e del codice.

[PGI-Bis]

Prima costruisci il test che fallisce. Perfetto. Il test è sbagliato: fallisce per un bug del test o del codice. Dove vanno a finire i binari?

[franksisca]

Originariamente inviato da PGI-Bis

Prima costruisci il test che fallisce. Perfetto. Il test è sbagliato: fallisce per un bug del test o del codice. Dove vanno a finire i binari?

crash

[cionci]

Originariamente inviato da PGI-Bis

Prima costruisci il test che fallisce. Perfetto. Il test è sbagliato: fallisce per un bug del test o del codice. Dove vanno a finire i binari?

Ragioniamo per induzione...la testbase e la codebase sono vuote. Scrivi il primo test: deve fallire, quindi non può fallire per un bug nel codice (perchè non c'è codice). Mettiamo che il test fallisca per un bug nel test.
Il TDD dice che bisogna procedere a piccoli passi, il codice che bisogna inserire è quindi sicuramente più semplice di quello necessario a scrivere il test. Di conseguenza scrivo il codice che penso sia adatto a rendere verde il test. Non mi riesce rendere il test verde, ma sono abbastanza (data la minima quantità di codice) sicuro del codice che ho scritto: ergo l'errore è nel test.
Cerco l'errore nel test, se l'errore non è banale elimino il codice, modifico il test e riscrivo il codice.
A questo punto la code base è consistente con la test base. Per definizione, perchè il codice fa quello che il test gli richiede.

Andiamo al secondo test. La code base è consistente con la test base di conseguenza se scrivo un test sono sicuro che un test fallisce per uno di questi due motivi: o ho scritto male il test o l'ho scritto bene e devo modificare di conseguenza il codice (non può fallire per un bug del codice perchè la test base è consistente con la code base).
Se ho scritto male il test: visto che il TDD impone piccoli passi, di conseguenza il codice che dovrò scrivere sarà molto semplice. Scrivo il codice che penso faccia passare il test, ma non funziona, quindi vado a pensare che l'errore sia nel test.

Andiamo al passo N. E così via.

IMHO l'unico modo per far diventare verde un test scritto male è inserire sia un bug nel test che un bug nel codice che esso testa

[Ufo13]

Originariamente inviato da PGI-Bis

Prima costruisci il test che fallisce. Perfetto. Il test è sbagliato: fallisce per un bug del test o del codice. Dove vanno a finire i binari?

Ricordati che un programmatore ha un cervello che deve bene o male funzionare decentemente per scrivere un software. Ovviamente devi sempre scrivere test semplici per poterti accorgere di un errore all'interno di essi.

A me è successo molte volte d iscrivere il test sbagliato e me ne sono sempre accorto, come mai?

Inoltre con il test almeno hai un feedback. Se scrivi codice sbagliato senza test è peggio non trovi?

Per quanto riguarda la cosa del soviet driven development (Ma chi lo ha detto, Tanenbaum?)... Mi dici dove sta il punto? Ma ci credi veramente? Non ho mai sentito una cavolata simile in vita mia, giuro.

Inoltre come fai a lavorare senza source control scusa??? Io lo uso anche per lavorare da solo fai un po' te

[PGI-Bis]

Be', non è necessario esacerbarsi. Per inciso, non è Tanembaum a chiamarlo "Soviet Driver Development" (ma cita l'idea senza approfondirla in Modern Operating System) è un'etichetta che ho usato io a mo' di scherno.

Premetto che se a uno il TDD piace io non mi permetterei mai di dirgli "non devi usarlo": non ho un'alternativa che sia meno incerta del TDD. Negli anni ne ho sperimentati parecchi. Una volta ho addirittura usato l'approccio "alla vulcaniana": tutta logica e certezze. Due bug mi son saltati fuori lo stesso. Nota: "alla vulcaniana" è un nomignolo e no, non ci credevo veramente.

Quello di cui non mi capacito sono le orde di genuflessi schierate di fronte ai nuovi profeti del nulla.

Nelle 412 pagine di "Refactoring" di Fowler non è detta una sola ragione per cui un Giovannino qualunque dovrebbe usare una qualsiasi delle tecniche descritte. E il libro chiude con Beck che ti prende anche per il culo: "Now you have the pieces of the puzzle". No, signori, "Now you have un bel pugn' de mosch'".

Trent'anni fa i libri di programmazione terminavano con un capitolo sul "Conceptual Framework", dove gli autori esponevano i fondamenti di ciò che avevano detto. BETA è ancora un campione in merito. Esiste una migliore dimostrazione di onestà intellettuale? "Hey, l'ho detto perchè x, y, z. Se x, y o z sono cavolate, allora sono cavolate anche le mie".

Sono convinzioni mie: non per questo dovete smettere di usare xP e TDD. Potendo chiederei solo che non sia spacciato per logico, semplice, evidente, quello che logico, semplice ed evidente non è.

[Ufo13]

Ho letto il libro di Tanenbaum e non ricordo di aver letto nulla del genere... Comunque son passati un po' di anni...

Riguardo Fowler... Guarda che loro ti scrivono delle cose, poi sta a te decidere il motivo per cui dovresti utilizzarle. Nessuno ti deve venire a dire il perchè, il perchè lo devi trovare tu. Quando vai dal ferramenta ci sono i martelli e non c'è scritto il perchè dovresti comprarli, il perchè lo decidi tu (esempio: non voglio piantare i chiodi a testate). E guarda bene che il paragone del ferramenta è pure azzeccato perchè qui si parla di "necessità" <=> "strumento"

Se tu non riesci a trovare un perchè sta bene a tutti, ma da qui a dire che programmare come si faceva 30 anni fa senza source control e scrivendo commenti è figo ce ne passa direi! L'esempio "30 anni fa" è proprio sbagliato concettualmente, le cose evolvono e così fa l'ingegneria del software.

Guarda io lavoro con gente che programma così ed è un incubo, non esiste proprio paragone con la semplicità e la pulizia con cui le cose venivano fatte in Diamond Crush e quelli con cui lavoro hanno molta più esperienza del team di DC.

[71104]

Originariamente inviato da PGI-Bis

Tu guarda a volte il caso. Ma sai dove ho trovato l'ispirazione del "Soviet Driven Development" ? Dai, prova a buttarla lì! Libro e autore famosissimo, una volta litigò con tal Torvalds...

se è Tanenbaum (si scrive così...? ) non è un esempio valido: non ce la vedo molto l'utenza media a usare Minix

parlando di sistema operativo prima avevo in mente qualcosa più come Linux munito di XGL, o peggio ancora Windows Vista

dici che ce la fa una persona sola...?

[71104]

Originariamente inviato da cionci

[...] IMHO l'unico modo per far diventare verde un test scritto male è inserire sia un bug nel test che un bug nel codice che esso testa

ragionamento impeccabile, ma anche in quel modo ti accorgi che qualcosa non va per il semplice motivo che nel caso di test e codice entrambi buggati hai scritto un programma che funziona (non buggato), solo che non funziona come vuoi tu e questo lo vedi semplicemente a runtime.

di conseguenza il TDD è orientativamente infallibile (dico orientativamente perché si basa sempre sull'assunzione che il programmatore sbaglia nello scrivere tanto codice ma non sbaglia nello scriverne poco).

però io dopo l'esperienza su DC penso che all'atto pratico non sia realmente vantaggioso: su DC lo usavamo e il codice è diventato un casino; ok, colpa di alcuni membri del team che non rispettavano le buone norme di black box testing. però io nel mio progetto di Programmazione di Rete (un programma di filesharing) ti posso assicurare che senza usare TDD sto avendo assieme al mio amico una velocità di sviluppo mostruosa che non abbiamo mai raggiunto neanche su DC, infatti secondo me a questo punto il nostro programma inizia ad essere persino più complesso di DC. e procede fluidamente senza rallentamenti e senza codice incasinato. e siamo in due, mentre su DC eravamo (almeno all'inizio) una dozzina. e com'è sta storia?

[Ufo13]

Originariamente inviato da 71104

ragionamento impeccabile, ma anche in quel modo ti accorgi che qualcosa non va per il semplice motivo che nel caso di test e codice entrambi buggati hai scritto un programma che funziona (non buggato), solo che non funziona come vuoi tu e questo lo vedi semplicemente a runtime.

di conseguenza il TDD è orientativamente infallibile (dico orientativamente perché si basa sempre sull'assunzione che il programmatore sbaglia nello scrivere tanto codice ma non sbaglia nello scriverne poco).

però io dopo l'esperienza su DC penso che all'atto pratico non sia realmente vantaggioso: su DC lo usavamo e il codice è diventato un casino; ok, colpa di alcuni membri del team che non rispettavano le buone norme di black box testing. però io nel mio progetto di Programmazione di Rete (un programma di filesharing) ti posso assicurare che senza usare TDD sto avendo assieme al mio amico una velocità di sviluppo mostruosa che non abbiamo mai raggiunto neanche su DC, infatti secondo me a questo punto il nostro programma inizia ad essere persino più complesso di DC. e procede fluidamente senza rallentamenti e senza codice incasinato. e siamo in due, mentre su DC eravamo (almeno all'inizio) una dozzina. e com'è sta storia?

Chiaramente un team di 2 persone è molto meglio gestibile di un team di 10 persone. Inoltre in DC non tutti avevano lo stesso livello di esperienza (quanta gente non aveva mai usato Java prima? E OpenGL?), inoltre in DC il codice non è diventato così uno schifo come dite... Eliminando le parti sviluppate da Marzo in poi si è ritornati ad avere qualcosa di decente

Comunque il problema non è nel TDD ma nella voglia del team. Tu stai facendo un progetto per l'università quindi hai la motivazione capisci? In DC appena le cose son diventate un pelo complesse la gente ha cominciato a non lavorare più, a non fare refactoring, a scrivere prima il codice e poi i test, a non mockare, e così via.

Comunque onestamente non mi sento ancora di dare un giudizio finale al TDD, DC è stato un esperimento, tale esperienza ha mostrato alcuni punti che potevano essere migliorati nel processo di sviluppo e in futuro qualcuno farà tesoro dell'esperienza acquisita. Tale esperienza insegna anche quando il TDD NON va utilizzato. Sto lavorando ad un progetto con due amici e so che il TDD mi sarebbe solo di ostacolo e quindi non lo uso (è tutta rob

Ma poi non ho capito 272613742 qualche mese fa facevi tutto il gasato del tdd e ora dici così?

[71104]

Originariamente inviato da Ufo13

Chiaramente un team di 2 persone è molto meglio gestibile di un team di 10 persone.

infatti è proprio questo il motivo percui trovo molto intelligente il "Soviet Driven Development" l'ingestibilità di un team è un problema che scompare nel momento in cui a scrivere è uno solo che facendo da se' fa per tre. però è anche vero che non è pensabile per software giganteschi: in quei casi secondo me il software dovrebbe essere prima suddiviso in più parti a cui assegnare un "gorilla" ciascuna. nel caso di un sistema operativo potrebbe ad esempio trattarsi di un gorilla per ciascun modulo eseguibile.

Comunque il problema non è nel TDD ma nella voglia del team. Tu stai facendo un progetto per l'università quindi hai la motivazione capisci? In DC appena le cose son diventate un pelo complesse la gente ha cominciato a non lavorare più, a non fare refactoring, a scrivere prima il codice e poi i test, a non mockare, e così via.

esatto, ma la voglia del team è scomparsa anche a causa della scomodità el TDD: per fare qualsiasi cosa dovevi prima testare, veder fallire i test, farli diventare verdi, e cercare di capire perché qualche altro stramaledetto incomprensibile test falliva. troppo scomodo, se il team avesse avuto il via libera sul codice (cioè la possibilità di modificarlo come meglio credeva senza essere schiavi dei test) sarebbe stato molto più facile fare modifiche, correggere bug, ecc.

non nego che dovevano comunque esserci delle guidelines di scrittura del codice: fek ci ha insegnato a scrivere codice in una maniera secondo me PERFETTA, tant'è vero che il mio progetto per l'esame è scritto interamente a quel modo (codice "autoesplicativo", complessità ciclomatiche bassissime, quasi tutte inferiori a 4, identificatori kilometrici, zero commenti, pochi TODO, un solo FIXME), ed è stato sviluppato senza TDD.

Ma poi non ho capito 272613742 qualche mese fa facevi tutto il gasato del tdd e ora dici così?

qualche mese fa il mio programma per l'università non l'avevo ancora iniziato
scherzi a parte, che "facessi il gasato del TDD" era vero ma non perché ne fossi diventato un fanatico che intendeva usarlo per il resto della sua vita. piuttosto perché volevo che il team lavorasse bene e che la smettessi di vedere schifezze di test che riportavano le seguenti caratteristiche:
* nome non esplicativo quasi identico a quello di tutti gli altri test del case
* 3 schermate di codice
* complessità ciclomatica superiore a 1!!!! questa nei test è una cosa che non ho mai potuto soffrire...

cioè cercavo semplicemente di spiegare agli altri la forma canonica di sviluppo che secondo me fek aveva voluto insegnarci (devo essere stato uno di quelli che l'hanno capita meglio visto che sono stato il primo a cui fek abbia dedicato un'intera serata per insegnarmela con un pair )

[71104]

Originariamente inviato da 71104

(devo essere stato uno di quelli che l'hanno capita meglio visto che sono stato il primo a cui fek abbia dedicato un'intera serata per insegnarmela con un pair )

oddio a pensarci bene non sono molto sicuro...
forse c'è stato VICIUS prima di me

però io alla fine ero l'unico maniaco che dopo qualche tempo s'è messo a sviluppare in TDD in forma pura

[franksisca]

a proposito, ma fek che fine ha fatto???


comunque, mi spieghi, brevemente, cosa intendi per complessità ciclomatica???

[PGI-Bis]

Ho ritrovato la storia del soviet development. E' citata nel Tanenbaum (Modern Operating System, 2nd ed., Ch 12, 12.5.2, p. 891) ma l'ho erroneamente attribuita all'Autore. E' di Harlan Mills e pare chiamarsi Chief Programmer Team. Risale agli anni '70 e non viene più usata da un bel po'.

[71104]

Originariamente inviato da franksisca

comunque, mi spieghi, brevemente, cosa intendi per complessità ciclomatica???

un indicatore che ti da una buona idea della reale complessità del codice. una maniera semplice di calcolarlo per un metodo Java è partire da 1 ed incrementare ad ogni if, for, do, while, try. l'else invece non si conta.

era nell'idea di fek che lo stato "canonico" che avrebbe dovuto raggiungere Diamonds sarebbe stato nessun metodo di complessità ciclomatica superiore a 4 (che già era tanto per lui: quando un metodo raggiungeva 4 toccava suddividerlo, cosa che ho fatto anche io nel mio progetto).