Storia di un bug

[fek]

Originariamente inviato da 71104

hai ragione, ho detto male: non mi riferivo al giudizio che do alla pratica del TDD, ma a come giudico il mio metodo cioè non fare TDD; ma siccome il mio metodo lo giudico buono e credo di dover utilizzare quello, l'altro lo considero da scartare ^^

No, tu ti riferisci ad una metodologia di scrittura del codice (TDD), che hai dimostrato di non conoscere e non aver mai imparato, quindi non puoi darci alcun giudizio.

ok, ci credo, ma in futuro è meglio che non prendi Microsoft come esempio, che è notoriamente di una lentezza esasperante

Microsoft e' uno degli sviluppatori di software piu' produttivi al mondo. E' giusto prenderli come esempio.
Un altra fra le migliori e piu' produttive aziende al mondo e' la ThoughtWorks (www.thoughtworks.com), nelle loro job description c'e' la richiesta esplicita di saper fare Refactoring, conoscere i Design Patter e saper scrivere Unit Testing; se non sai scrivere Unit Testing, non ti fanno neppure il colloquio

Dici che buttano soldi? E come loro sempre piu' aziende, e' un trend. Se vorrai fare il programmatore finita l'universita', dovrai imparare a scrivere Unit Test, altrimenti al massimo potrai aspirare al lavoretto nella piccola software house italiana.

aspetta un secondo, non andare predicando di non fare cose per le quali sei maestro
se non è questo un bel "giudizio affrettato", non lo è nessun'altro: non hai mai sperimentato lo "scrivere codice immediatamente senza errori", tutt'al più con qualcosa di assolutamente evidente che puoi cambiare immediatamente,

La stai andando un po' sul personale, evita
Ti ripeto che ho 15 anni di esperienza di cui 5 da professionista, le ho provate un po' tutte e non sono mai riuscito a scrivere codice senza errori perche' e' matematicamente impossibile. Lo sanno anche i sassi che il software esente da difetti non esiste.

ma stai giudicando questo metodo come impraticabile, impossibile. perché dici che lo è? è un giudizio empirico, nessuno ti ha detto e dimostrato che lo è, anche perché in teoria non lo è.

Proprio in teoria lo e', e' dimostrato matematicamente. Il numero di permutazioni degli input per un qualunque programma cresce esponenzialmente ed e' impossibile testare la correttezza della risposta per ogni possibile input. Quando non puoi provare la correttezza dell'output, l'output e' per definizione errato, quindi il programma contiene bug. La definizione vera e' piu' rigorosa.

cosa dovrebbe renderlo impossibile? il fatto che tu non sappia fin dal principio qual'è il codice corretto? questo è un problema; la soluzione è: sappilo. concettualmente nella tua testa ti farai un'idea del programma che deve essere sviluppato (o della parte che devi sviluppare); questa parte sarà divisa in più parti (metodologia top-down), e il problema verrà scomposto in problemi più semplici; fatti degli schemi su carta se necessario, ma penso che nella maggior parte dei casi non sia necessario (non credo che nel mondo del lavoro venga richiesto a una sola persona di sviluppare un progetto talmente vasto da non poterne avere un'idea completa a mente, da dover costringere a scrivere su carta); alla fine comunque dovresti arrivare a sapere esattamente cosa devi scrivere, cosa te lo impedisce? non sai come implementare alcune cose? e allora che programmatore sei? non sai con esattezza quali siano le specifiche? chiedi chiarimenti! non si può pretendere che lavori senza sapere quello che devi fare. detto questo: scrivi. (e qui si applica il discorso degli stereotipi).

Ingenuo

Scrivi un'applicazione che mi faccia il rendering di una scena importata da Maya, con un modello di illuminazione semplice di phong e supporti normal e specular map per ogni oggetto. Quanto ti serve, tre settimane? Ovviamente non deve avere nessun bug, perche' hai detto che tu sai scrivere software senza bug
Basta scriverlo top-down Farsi gli schemini su carta
Senza bug, ricorda, deve funzionare su ogni configurazione che trovo, in ogni condizione possibile e immaginabile, senza bug.
Vediamo se ci riesci. Io ti dico che non ci riuscirei, ma forse perche' io pretendo di lavorare senza sapere quello che faccio

Sai quanti bug l'EA prevede di trovare dalla fase di testing di BW2? 12.000. Te lo ripeto, 12.000. Piu' di 250 bug a testa. E' una previsione che fa in base a tutti gli altri progetti che l'EA ha sviluppato (sono centinaia). Second te all'EA nessuno sa programmare? Secondo te noi non sappiamo programmare senza scrivere bug? Perche' non vieni ad insegnarci a scrivere software senza bug

Il punto e' che finche' la tua esperienza si limita al software antispam, posso capire questi ragionamenti, ma quando ti auguro lavorerai professionalmente su software complesso con altre decine di persone, ti accorgerai quanto ingenua sia l'affermazione: "Ma basta scrivere senza bug e conoscere sempre la soluzione". Si', basta, peccato che sia impossibile

io non ci credo, innanzitutto perché non può essere provato se non su basi statistiche (e la statistica si sa, per definizione è un'opinione ); che io non ci creda è tanto lecito quanto lo è che VICIUS affermi la superiore portabilità del C rispetto a quella del Java.

La statistica non e' un'opinione, e' una branca della matematica ed ha risposte esatte.
E' indifferente che tu ci creda o no, questo incidera' solo sulla tua carriera in futuro. E' un fatto comprovato che scrivere test e' piu' produttivo, non lo discutero' oltre. Se non ne se convinto, te ne convincerai con l'esperienza, se non te ne convincerai, non farai mai il programmatore ad un certo livello. E' davvero cosi' semplice.

ora aldilà di tutto ore e ore di debugging non le ho mai fatte...

Perche' non hai mai lavorato su progetti complessi. Noi abbiamo fatto notti di debugging.

e non impari mai? mio buon amico, sbagliare è più che lecito, ma l'importante è sbagliare una volta sola; se per te non è così vuol dire una cosa sola: questo dannato TDD ti culla troppo

Si', io imparo. Ti ho gia' detto di non andare sul personale

va bene il lavoro, ma da quanto ho capito fai anche dei programmi x conto tuo, x hobby: durante questi lavori fatti x hobby cerca di diventare indipendente da questo TDD; seriamente: provaci! prova a scrivere un programma perfetto!

Gia' fatto, anni fai, quando tu probabilmente non avevi ancora iniziato a programmare. E' impossibile.

li ho appena battezzati "mini-test"; che hanno che non vanno? rallentano solo se falliscono; ma nella maggior parte dei casi non devono fallire!! possono fallire solo per le cavolate che vedi subito.

Vanno benissimo, sono solo manuali, se fossero automatici risparmieresti solo molto tempo.

vai più spedito perché quello che io faccio premendo F5 tu lo fai scrivendo altro codice e poi premendo F5?

Ma io testo sempre tutto il programma con un solo F5 in meno tempo di quello che tu impieghi a testare solo una piccola parte. Se l'ultimo cambiamento che ho fatto rome qualcosa in una porzione del programma molto differente da quella su cui sto lavorando o nel codice di qualcun altro, io me ne accorgo subito, tu no. Se pensi che questo sia impossibile e basta scrivere codice senza errori, vuol dire che non hai abbastanza esperienza su progetti complessi.

[^TiGeRShArK^]

Originariamente inviato da fek

vuol dire che non hai abbastanza esperienza su progetti complessi.

è proprio questo il punto secondo me.

[fek]

Originariamente inviato da ^TiGeRShArK^

è proprio questo il punto secondo me.

Ma sai che cosa mi fa sorridere?

Che mi dicono che e' possibile imparando con l'esperienza scrivere codice senza bug e senza leak, basta solo ricordarsi di distruggere tutto. E io oggi devo passarmi la giornata al debugger alla ricerca di... memory leak in D3D causati da un team di programmatori 3d che ha 70 anni di esperienza totale. Mark lavorava su Syndicate e Dave su Populous, se qualcuno se li ricorda.

Ma forse non abbiamo abbastanza esperienza per scrivere codice senza bug...

[^TiGeRShArK^]

eh si ke me li ricordo
populous era il primo simulatore di divinità (l'antenato di B&W + o - ) e syndicate era un macello in cui c'erano di mezzo sindacati, missioni segrete e nn mi ricordo ke altro.....
cmq nn li ho mai avuti io, ci giocavo ogni tnt da dei miei amici

x quanto riguarda l'esperienza x scrivere codice senza bug.... credo ke un paio di milioni di anni FORSE potrebbero bastare se l'uomo avesse una capacità di memoria illimitata

[cionci]

Originariamente inviato da fek

Mark lavorava su Syndicate e Dave su Populous, se qualcuno se li ricorda.

[ghiotto86]

fek mi meraviglio di te che non sai programmare evitando i bug.
e no e no

[cionci]

Originariamente inviato da fek

Mark lavorava su Syndicate e Dave su Populous, se qualcuno se li ricorda.

Tra l'altro sono entrambi della Bullfrog... Syndicate era di una difficoltà assurda...bel gioco

[fek]

Originariamente inviato da ghiotto86

fek mi meraviglio di te che non sai programmare evitando i bug.
e no e no

Almeno sono in buona compagnia

[ghiotto86]

e già
cmq molto interessante la spece di tutorial che hai fatto, non ero proprio a conoscenza di una metodologia del genere.
la teoria penso la farò ad ingegneria del software tra 2 anni (speriamo).

p.s. volevo chiederti: ma hai fatto ing informatica???

[fek]

Originariamente inviato da ghiotto86

e già
cmq molto interessante la spece di tutorial che hai fatto, non ero proprio a conoscenza di una metodologia del genere.

Sto scrivendo a tempo perso una serie di articoli sulle D3D sulla falsa riga di quei post. Quando ho qualcosa di presentabile magari ve la passo e mi fate una review a caccia degli errori?

p.s. volevo chiederti: ma hai fatto ing informatica???

Si', Ing. Informatica a Torino con specializzazione in Ing. del Software.

[ghiotto86]

Originariamente inviato da fek

Sto scrivendo a tempo perso una serie di articoli sulle D3D sulla falsa riga di quei post. Quando ho qualcosa di presentabile magari ve la passo e mi fate una review a caccia degli errori?

ma certo. anche se ci sono pareri molto più professionali dei miei

Si', Ing. Informatica a Torino con specializzazione in Ing. del Software.

ne ero sicuro.

[cionci]

Originariamente inviato da fek

Sto scrivendo a tempo perso una serie di articoli sulle D3D sulla falsa riga di quei post. Quando ho qualcosa di presentabile magari ve la passo e mi fate una review a caccia degli errori?

Ma li stai scrivendo per qualche sito ? Altrimenti nella sottosezione delle guide ci starebbero molto bene

[fek]

Originariamente inviato da cionci

Ma li stai scrivendo per qualche sito ? Altrimenti nella sottosezione delle guide ci starebbero molto bene

Beh, si'
Spero di presentarli al GDC dell'anno prossimo.

Pero' appena ho finito magari scrivo qualche guida per voi. Mi farebbe piacere. Ne parliamo.

[mjordan]

Fek, ti faccio una domanda provocatoria.
Alla fine della storia, avrai imparato anche "cosa vuol dire avere pazienza"?

"Fermo! Non sappiamo nuotare!"
"Sarai buono o cattivo? Una benedizione o una maledizione? Sarai quello che vorrai essere".

Io forse sono uno dei pochi che ha giocato a Black & White due giorni di fila senza dormire e sono andato in ospedale perche' mi e' venuta una flebite ad un piede perche' stando seduto troppe ore ho avuto problemi di circolazione cardiaca. Alla fine non avevo capito che Dio ero, pero' quello mio se n'e' andato tutto

[ri]

io non riesco a capire una cosa sola... se sto scrivendo software, nello specifico una determinata classe, scrivo i metodi che la compongono, però non mi limito a scrivere i soli metodi, ma scrivo anche la parte di codice che effettivamente li utilizza, scoprendo immediatamente se il progetto compila o meno.
Questo probabilmente accade perchè lavoro nella "piccola azienda italiana di software" e difficilmente si lavora in più di due persone sullo stesso progetto..

Comunque, queste unità di testing servono esclusivamente quando si sviluppa del codice altamente specializzato per un determinato compito e non si ha l'ambiente finale in cui verrà incluso, giusto?

[cionci]

Servono quando c'è una specifica vera e propria per ogni modulo... Cioè quando ci si è seduti prima a tavolino e si sono definite le specifiche e le interfacce di ogni modulo... Altrimenti come fai a scrivere il programma di test ????

[ri]

ovvero serve in un mondo diverso dalla "piccola azienducola italiana di software", dove tutto cambia ogni 10 minuti

dovevo fare il falegname..

[fek]

Originariamente inviato da cionci

Servono quando c'è una specifica vera e propria per ogni modulo... Cioè quando ci si è seduti prima a tavolino e si sono definite le specifiche e le interfacce di ogni modulo... Altrimenti come fai a scrivere il programma di test ????

Non necessariamente, anzi no. Quelli sono i customer test che hanno lo scopo di verificare le specifiche funzionali dell'applicazione.

Il cliente chiede: "Quando inserisco un nome dell'autore non corretto, l'articolo non va salvato, altrimenti viene salvato con la data di oggi".

E "qualcuno" traduce questo requisito in un test non necessariamente nel linguaggio usato per implementare l'applicazione; di solito si usa un qualche linguaggio di scripting ad alto livello.

A quel punto il programmatore riceve il customer test e inizia a implementare. Vediamo, dice che un articolo va salvato, quindi dovra' essere possibile salvare un articolo in un qualche database. Prima serve poter aprire un database. Ecco un test. Lo implemento. Poi serve salvare un articolo nel database. Ecco un altro test. Implemento anche questo. Poi serve salvarlo con la data odierna. Ecco un altro test e la sua implementazione. Adesso mi serve capire se un nome dell'autore e' valido o meno riguardo ad un qualche criterio, scrivo il test relativo. Ora mi serve non scrivere l'articolo se il nome e' scorretto. Test.

Tutti i test passano? Si'
Il customer test passa? Si'.
Ho finito. E anche il cliente e' soddisfatto perche' vede passare il suo test e sa che io ho implementato il suo requisito. Se cambia il requisito, cambia il test e quando lo faccio passare di nuovo ho finito.

Quando ricevo il customer test sono di fronte ad un problema con una soluzione potenzialmente sconosciuta e non posso sapere quali programmer test mi porteranno alla soluzione corretta, allora inizio a scrivere il piu' semplice che mi venga in mente e che getti luce sulla soluzione, che mi porti piu' vicino. Man mano che scrivo test me ne verranno in mente altri, perche' ho sempre piu' chiara la soluzione. Quando il customer test passa, ho finito, non un minuto prima non uno dopo.

[fek]

Originariamente inviato da mjordan

Fek, ti faccio una domanda provocatoria.
Alla fine della storia, avrai imparato anche "cosa vuol dire avere pazienza"?

Si'

[cionci]

Non parlo di sedersi al tavolino con il cliente, ma con il gruppo di programmatori... In pratica quando si ha davanti il progetto dell'applicazione...