Storia di un bug

[fek]

E comunque ridendo e scherzando anche ieri ho fatto il check in di un bug fix che ha causato un crash grosso come una casa; ed oggi volevano uccidermi.

Il prossimo che nelle news mi dice che tanto i bug fix non possono far danni a nessuno e fare testing non serve, me lo mangio vivo...

... oppure e' colpa mia e devo imparare a stare piu' attento. Fate quello che vi dico non quello che faccio

[theClimber]

Originariamente inviato da fek

Mi piace questo punto. Perche' non usare la liberta' e la flessibilita' solo dove serve? Si unisce il buono dei due mondi: C/C++ dove serve la flessibilita', Java/C#/Python/Ruby dove la flessibilita' non ti serve, ma vuoi produttivita' e tranquillita'.

Sto entrando nell'ottica che non e' strettamente necessario usare un solo linguaggio per tutto il progetto, ma lo strumento giusto al momento giusto. Poi serve la colla per unire i vari linguaggi.

Concordo. Dai un occhio al pattern http://c2.com/cgi/wiki?AlternateHardAndSoftLayers ci sono alcuni spunti interessanti. I concetti di base alla fine si riducono a questo:

- go ahead and write most of your code in the highest level language you can find.
- when you must, use a profiler and find the slow parts of your program.
- Take those parts, and write them in a lower-level language. (E personalmente aggiungerei : se e solo se non trovi un algoritmo + efficiente !)

Comunque io sarei piu' drastico nel separare i mondi: C/C++/Java/C# da una parte [Ovvio che se poi si parla di device driver o componenti particolarmente critiche, la scelta poi finisce sul C] e Python/Ruby/Smalltalk/Prolog/XSLT/XQuery dall'altra, in quanto i primi sono comunque linguaggi piu' "tradizionali", mentre negli altri ci sono feature utili per fare operazioni specializzate, che nei giusti casi amplificano enormemente la produttività.

Personalmente in molte applicazioni che usano XML apprezzo l'uso di XSLT per costruirlo/modificarlo (http://c2.com/cgi/wiki?XsltAsSoftLayer) rispetto all'uso delle API DOM/SAX in java.

Ciao

[71104]

Originariamente inviato da cionci

Basta...mettiamoci un bel . e continuicamo a trattare l'argomento...che era interessante...

si però sinceramente il linguaggio usato da Daniele mi sembrava *cristallino*... e ve lo dice uno che di uscite strane ne ha...

cmq vorrei dire la mia: per evitare i problemi che ha avuto fek, MFC aiuta tantissimo: è una favola! qualsiasi memory leak viene segnalato al debugger (OutputDebugString, wrappata in AfxTrace, macro TRACE e compagnia bella), e tanto per cominciare mi sembra già un'ottima cosa, perché io ritengo che un programma che ha una buona gestione della memoria e che non fa nessun leak (nessuno!) è semplicemente un programma robusto!

poi MFC mette anche a disposizione altri strumenti di debug: le macro ASSERT, VERIFY, e ASSERT_VALID sono assolutamente ottime!! in particolare ASSERT_VALID è un wrapper per la funzione virtuale AssertValid (se ben ricordo) che qualsiasi classe derivata da CObject dovrebbe avere: viene implementata dal programmatore che crea la classe derivata da CObject, e serve semplicemente ad asserire quando viene chiamata e trova qualcosa che non va. naturalmente tutto l'overhead dovuto a questi strumenti viene completamente eliminato in modalità Release!

ricordo di aver fatto un piccolo esperimento una volta: ho creato un'applicazione MFC SDI scema scema utilizzando l'appwizard del visual studio (semplicemente un'applicazione vuota scegliendo le impostazioni predefinite del wizard); risultato: se ben ricordo erano 2 mega in modalità Debug e 300 kappa in Release.

siccome i simboli per il debug non occupavano quasi nulla (dovrebbero essere poco più grossi dei sorgenti stessi: si tratta essenzialmente di mappare le istruzioni assembly con le righe di codice C++, più qualche altra cosa per il debug multithreaded), tutto l'overhead era per controlli di debug e asserzioni; a occhio mi pare che MFC sia qualcosa di cui ci si può fidare... quando programmo ad alto livello lo uso sempre.

MFC lo ritengo una delle poche cose che hanno contemporaneamente queste due caratteristiche:
- made in Redmond
- di ottima qualità
e questo imho perché sono opensource (Microsoft sarebbe bene che imparasse da questo: IE avrebbe meno problemi). fatto sta che i bug di MFC si contano sulle punte delle dita.

[cionci]

Però MFC come framework è anche molto limitato...molto di più di wxWidgets e QT...

Se ti piacciono le MFC usa le wxWidgets...secondo me ti ci troveresti bene

[DanieleC88]

Originariamente inviato da cionci

Se ti piacciono le MFC usa le wxWidgets...secondo me ti ci troveresti bene

Infatti, io di solito uso C, non C++, ma avevo letto qualcosa scritta con Qt e wxWidgets e sembra molto chiara. Forse le proverò anche io, un giorno o l'altro.

Rispondo anche a ri: be', come vedi, già in tre hanno detto che non mi sono espresso male, in italiano. Forse dovresti farlo tu un ripasso di italiano. E ora basta, argomento chiuso. Torniamo a parlare di bug.

A proposito di bug (rispondete solo se vi sembra che questo non sposti troppo l'argomento di discussione): quale debugger usate, voi? Io uso gdb, soprattutto attraverso tool grafici, visto che sono un po' negato.

[fek]

Originariamente inviato da DanieleC88

A proposito di bug (rispondete solo se vi sembra che questo non sposti troppo l'argomento di discussione): quale debugger usate, voi? Io uso gdb, soprattutto attraverso tool grafici, visto che sono un po' negato.

Il debugger non dovrebbe mai essere usato se non in casi estremi
Sto cercando di curare la mia sindrome da abuso del debugger.

[RaouL_BennetH]

Originariamente inviato da fek

Sto entrando nell'ottica che non e' strettamente necessario usare un solo linguaggio per tutto il progetto, ma lo strumento giusto al momento giusto. Poi serve la colla per unire i vari linguaggi.

Evviva!! scusate, ma questa cosa mi conforta anche se in me ha avuto un processo inconscio.

Starete facendo queste faccine adesso, ci scommetto ma vi assicuro che non sono impazzito, almeno, non ancora

Mi spiego:

Quando mi son trovato "costretto" a risolvere un problemino nell'azienduccia di mio padre in merito al rilievo delle presenze, ho agito così:

La parte che deve leggere i codici delle schede attraverso il lettore di badge, l'ho scritta in C. Ora, i dati di ingresso e di uscita, li ho interpretati come dati elementari ed ho fatto in modo che vengano memorizzati su file di testo (data la semplicità del dato da acquisire: codice scheda(numerico) ora di ingresso e ora di uscita.

Fatto questo, avevo un altro passaggio da effettuare, ovvero quello del prelievo di questi file dalla macchinetta per portarli sul pc. Bene, anche qui mi è stato comodo usare il C per la semplicità delle informazioni da trattare.

Per quanto concerne invece l'utilizzo da parte dell'utente (mio padre) in C non sarei riuscito a fare assolutamente nulla, e gli ho fatto l'interfaccia utilizzando visual basic e trattando i dati che arrivano dai file di testo memorizzandoli su un database mysql in modo che:

L'utente (mio padre) ha semplicemente dei bottoni sui quali cliccare per sapere :

Il dipendente X a che ora è entrato nel cantiere, quando è uscito e la durata di questo "intervallo" viene memorizzata in un'apposita tabella.

Ed altre cosine ma che non credo siano interessanti da trattare....

Ero fino a poco fa giù di morale (ma fino ad un certo punto, dato che di programmazione mi occupo da pochissimo e sempre a livello amatoriale) perchè pensavo che un "vero" programmatore, non avrebbe mai preso in considerazione usare diversi tool per realizzare un'applicazione, e le parole di fek in un certo senso mi hanno confortato

[fek]

Originariamente inviato da RaouL_BennetH

Ero fino a poco fa giù di morale (ma fino ad un certo punto, dato che di programmazione mi occupo da pochissimo e sempre a livello amatoriale) perchè pensavo che un "vero" programmatore, non avrebbe mai preso in considerazione usare diversi tool per realizzare un'applicazione, e le parole di fek in un certo senso mi hanno confortato

E poi vai ripetendo su tutti i forum che non sei bravo

[71104]

Originariamente inviato da fek

Il debugger non dovrebbe mai essere usato se non in casi estremi
Sto cercando di curare la mia sindrome da abuso del debugger.

perché???
il debugger si usa quando serve; se serve spesso lo si usa spesso

cmq indovinate che uso io...

[fek]

Originariamente inviato da 71104

perché???
il debugger si usa quando serve; se serve spesso lo si usa spesso

cmq indovinate che uso io...

... http://www.testdriven.com/modules/news/ ... e dici addio al Debugger

Test driven development (TDD) is emerging as one of the most successful developer productivity enhancing techniques to be recently discovered. The three-step: write test, write code, refactor – is a dance many of us are enjoying. This site is dedicated to promoting techniques, tools, and general good will in the test-driven community.

[ri]

Originariamente inviato da DanieleC88

à in tre hanno detto che non mi sono espresso male, in italiano. Forse dovresti farlo tu un ripasso di italiano. E ora basta, argomento chiuso. Torniamo a parlare di bug.

Al calare delle nuove tenebre, il nero signore dei mostri tornerà a colpire... Cattivik non perdona!

uaz! uaz!

[RaouL_BennetH]

Originariamente inviato da fek

E poi vai ripetendo su tutti i forum che non sei bravo

Non solo lo ripeto, ma lo confermo.

Ma devo spiegarmi bene:

Quando penso a come affrontare un determinato problema, sono convinto di avere in testa tutto chiaro, come debba funzionare la cosa e come debba essere risolto il problema.

Le cose che mi mancano, fondamentalmente sono:

1) Cultura informatica
2) Una qualsiasi forma di didattica o di studi effettuati in campo informatico
3) La mania di voler dare uno "sguardo" su qualsiasi cosa, senza poi avere la testardaggine di approfondire
4) se li elenco tutti consumo la memoria disponibile ai server del forum.
5) il peggiore di tutti: al momento non posso permettermi di abbandonare il mio lavoro, per quanto schifoso sia, per sognare di potermi iscrivere ad un'università o seguire qualche corso più specifico che non sia una spasmodica ricerca su google e i numerosi post di aiuto che faccio in questa sezione.

Poi, leggendo anche i post vostri, quando entrate nel merito di certe discussioni, mi sembra di leggere letteratura extraterrestre con la convinzione che nonriuscirò mai a comprendere determinate cose.

Cmq, al momento va bene così

RaouL.

[DanieleC88]

Originariamente inviato da ri

Al calare delle nuove tenebre, il nero signore dei mostri tornerà a colpire... Cattivik non perdona!

uaz! uaz!

Mi pare che fek te l'abbia già suggerito, comunque, te lo ripeto:

[VICIUS]

Originariamente inviato da fek

... http://www.testdriven.com/modules/news/ ... e dici addio al Debugger

Quoto. Ho finito di leggere il libro di Beck qualche settimana fa ed ti apre veramente gli occhi

ciao

[71104]

Originariamente inviato da VICIUS

Quoto. Ho finito di leggere il libro di Beck qualche settimana fa ed ti apre veramente gli occhi

ciao

io sono da un'altra parte: quei metodi di lavoro funzionano relativamente, e a quale prezzo? noi all'uni abbiamo appena finito di lavorare al progetto del corso di Laboratorio di Programmazione, e abbiamo sempre fatto unit testing (penso che si chiami anche così): il progetto era diviso in 4 "moduli" e per ciascuno bisognava creare oltre al codice principale anche il codice dei test. per la cronaca il progetto era un filtro antispam.
vi do la mia opinione: non solo alla fine il tempo di scrittura del codice è esattamente raddoppiato, ma i test (almeno per quanto mi riguarda) sono risultati al 90% inutili e per il rimanente 10% erano cose che avrei scoperto facendo il debug. conclusione: lasciate perdere quelle cavolate, semplicemente abituatevi a non fare nessun errore fin dalla prima volta: basta che imparate dai vostri errori quando ne trovate.
sono sicuro che queste frasi disgusteranno mjordan, ma non m'interessa: ve lo do come consiglio, fateci quello che volete

PS: e usate il debugger! e soprattutto usatene uno buono

PPS: un esempio di come io ho imparato dai miei errori: come già detto le MFC al termine dell'esecuzione del programma comunicano al debugger un dump completo di tutta la memoria non deallocata (non solo oggetti, anche comuni blocchi dell'heap), grazie agli hook che il framework installa per gli operatori new e delete. osservare quei dump ha sviluppato in me un occhio particolare per i memory leak: tutte le volte che uscivano i risultati di un modulo scoprivo con piacere di essere stato uno di quelli che avevano commesso il minor numero di leak, e a volte quelli che avevo commesso non dipendevano neanche da me ma da alcune librerie che abbiamo dovuto usare
senza contare che naturalmente lo unit testing non permette di scoprire i leak...

[VICIUS]

Originariamente inviato da 71104

io sono da un'altra parte: quei metodi di lavoro funzionano relativamente, e a quale prezzo? noi all'uni abbiamo appena finito di lavorare al progetto del corso di Laboratorio di Programmazione, e abbiamo sempre fatto unit testing (penso che si chiami anche così): il progetto era diviso in 4 "moduli" e per ciascuno bisognava creare oltre al codice principale anche il codice dei test. per la cronaca il progetto era un filtro antispam.
vi do la mia opinione: non solo alla fine il tempo di scrittura del codice è esattamente raddoppiato, ma i test (almeno per quanto mi riguarda) sono risultati al 90% inutili e per il rimanente 10% erano cose che avrei scoperto facendo il debug. conclusione: lasciate perdere quelle cavolate, semplicemente abituatevi a non fare nessun errore fin dalla prima volta: basta che imparate dai vostri errori quando ne trovate.
sono sicuro che queste frasi disgusteranno mjordan, ma non m'interessa: ve lo do come consiglio, fateci quello che volete

Quindi tu prima hai scritto il codice. Poi ti sei fatto un po' di debug ed infine hai scritto i test ? Test Driven Development è proprio il contrario. Prima si scrivono i test, poi si scrive il codice. Da quello che ho visto provandolo un po' su del codice semplice il debugger finisce nel dimenticatoio. Di sicuro per progetti più complessi serve ancora ma non nella stessa misura.

Per quanto riguarda il numero di test sei in linea con quanto detto nel libro. Secondo Beck non ha senso testare tutte le combinazioni possibili ed immaginabili. Con un po' di esperienza si arriva a capire quali casi limite testare e a scartare tutti gli altri. Fa un esempio per una classe molto semplice che gestisce i Triangoli e spiega come ha usato solo 7/8 test per testarla a differenza di un programmatore specializzato nella scrittura di test che è arrivato a ben 65 test.

Ti assicuro che prima di leggere il libro ero scettico pure io sulla utilita di una coa come TDD ma quando sono arrivato in fondo al libro mi sono dovuto ricredere. Non vuole di certo essere la cura a tutti i mali e cancellare tutte le altre metodologie ma semplicemente una tecnica alternativa quando non ti trovi a tuo agio con quello che dovrai andare a scrivere.

Originariamente inviato da 71104

PS: e usate il debugger! e soprattutto usatene uno buono

Qui mi trovi d'accordo. Se si deve usare un debugger meglio usarne uno buono. Usare gdb da console mi ha fatto uscire di testa piu di una volta quando potevo risolvere tutto in 10 minuti usandone uno grafico.

Originariamente inviato da 71104

PPS: un esempio di come io ho imparato dai miei errori: come già detto le MFC al termine dell'esecuzione del programma comunicano al debugger un dump completo di tutta la memoria non deallocata (non solo oggetti, anche comuni blocchi dell'heap), grazie agli hook che il framework installa per gli operatori new e delete. osservare quei dump ha sviluppato in me un occhio particolare per i memory leak: tutte le volte che uscivano i risultati di un modulo scoprivo con piacere di essere stato uno di quelli che avevano commesso il minor numero di leak, e a volte quelli che avevo commesso non dipendevano neanche da me ma da alcune librerie che abbiamo dovuto usare
senza contare che naturalmente lo unit testing non permette di scoprire i leak...

Se non ricordo male cppunit puo tranquillamente controlalre dove e quando allochi la memoria e dirti se non la liberi.

ciao

[fek]

Originariamente inviato da 71104

io sono da un'altra parte: quei metodi di lavoro funzionano relativamente, e a quale prezzo? noi all'uni abbiamo appena finito di lavorare al progetto del corso di Laboratorio di Programmazione, e abbiamo sempre fatto unit testing (penso che si chiami anche così): il progetto era diviso in 4 "moduli" e per ciascuno bisognava creare oltre al codice principale anche il codice dei test. per la cronaca il progetto era un filtro antispam.
vi do la mia opinione: non solo alla fine il tempo di scrittura del codice è esattamente raddoppiato, ma i test (almeno per quanto mi riguarda) sono risultati al 90% inutili e per il rimanente 10% erano cose che avrei scoperto facendo il debug. conclusione: lasciate perdere quelle cavolate, semplicemente abituatevi a non fare nessun errore fin dalla prima volta: basta che imparate dai vostri errori quando ne trovate.
sono sicuro che queste frasi disgusteranno mjordan, ma non m'interessa: ve lo do come consiglio, fateci quello che volete

Mio giovane padawan, sei troppo irruento, "fear leads to anger, anger leads to bugs..."
Ho notato che a volte dai giudizi categorici di impulso, e questi possono essere troppo affrettati, come in questo caso. Dare giudizi affrettati significa non essere in grado di apprezzare tutti gli aspetti di uno strumento e non poter sapere quando questo strumento ti possa venire utile o meno. E meno strumenti hai, meno frecce al tuo arco hai a disposizione quando devi risolvereu un problema. Mi piacerebbe leggere una tua opinione a questo proposito, riguardo al mio post sul WINE.

Tornando al TDD.

Al contrario di quanto si pensa, Test Driven Development non e' una metodologia di sviluppo che ha come scopo il testing del software. Sembra strano detto cosi', ma e' un errore piuttosto comune. Lo scopo del TDD e' scrivere software che risolva un problema e farlo nel minor tempo possibile con il design piu' semplice possibile. I test poi sono un prodotto della metodologia che si rivelano utili di per se'.

Le basi del TDD sono due:
- scrivere i test prima di scrivere il codice
- eliminare tutte le duplicazioni nel codice facendo refactoring

Scrivendo i test prima di scrivere il codice, tu formalizzi un processo mentale che fai sempre quando scrivi il codice.

Mi spiego meglio: quando scrivi un metodo, nel tuo cervello hai uno stato di partenza ed uno stato di arrivo che devi raggiungere e scrivi il codice per raggiungere lo stato di arrivo a partire da quello di partenza. Poi, di solito, lanci il programma e vedi se data una serie di input, il programma si comporta come ti aspetti. Quando questo non avviene, lanci il debugger, controlli lo stato delle variabili, esegui passo passo, sempre controllando che il valore delle variabili sia quello che ti aspetti. Trovi il bug quando hai uno stato che non ti aspetti, e poi modifichi il codice per ottenere il risultato che ti aspetti.

Non stai facendo altro che testing manuale.

TDD si basa invece sul principio che e' meglio che il computer faccia una cosa ripetitiva (testare gli stati del programma e la correttezza dei metodi), piuttosto che farla noi manualmente, di modo da poter usare il nostro tempo in maniera piu' furba.

Allora, dicevo, TDD formalizza quello che gia' facciamo quando programmiamo; davanti alla necessita' di aggiungere una funzionalita' al programma, scriviamo del codice che descriva come la funzionalita' deve comportarsi, in pratica documentiamo l'interfaccia della funzionalita', dettiamo come deve essere esposta, in pratica stiamo facendo il design della funzionalita', poi dichiariamo in maniera inequivocabile ed univoca come la funzionalita' deve comportarsi. Una volta che conosciamo l'interfaccia ed abbiamo dichiarato come il programma deve comportarsi, possiamo scrivere il codice che verifica l'interfaccia e soddisfa i requisiti ed abbiamo un chiaro momento in cui sappiamo quando dobbiamo fermarci a scrivere codice: quando il test passa.

L'ultima affermazione sembra una banalita', ma e' la chiave del tutto: in questo modo si tende a scrivere il codice minimo possibile per risolvere il problema. Il risultato netto e' scrivere meno codice di quando si programma "normalmente".

Passato il test, teoricamente questo non serve piu', il suo scopo e' concluso, possiamo anche buttarlo, ma visto che e' li' perche' non tenerlo? Tenere il test ha due vantaggi: da un lato ti documenta la funzionalita' in maniera univoca, dall'altro (se eseguito spesso) ti dice immediatamente quando scrivendo il codice hai rotto la funzionalita' che avevi gia' scritto. Quante volte ti e' capitato di scrivere codice e accorgerti che quello che avevi scritto non funziona piu' e non sapere che cosa di preciso hai cambiato per introdurre il bug? Accade in continuazione. La differenza facendo TDD e' che hai una rete di sicurezza che ti dice immediatamente quando qualcosa non va, invece che accorgertene magari dopo ore e poi lanciare il debugger a caccia del problema. Gia' solo questo, in pratica, porta ad un enorme guadagno di tempo. Non parlo dal punto di vista teorico, ma da quello pratico: faccio TDD da mesi e mi accorgo della differenza di produttivita' rispetto a quando non lo faccio al lavoro (perche' siamo alla fine del progetto).

Un'altra considerazione: e' impossibile non fare nessun errore fin dalla prima volta. Si diventa buoni programmatori nel momento in cui si accetta questo come un fatto compiuto e si lavora di modo da minimizzare l'impatto degli errori, sapendo che non sara' mai possibile non commetterne.

Sarebbe possibile non commettere mai errori se si avessero i requisiti da soddisfare sempre espressi in maniera inequivocabile dal cliente (e questo sai che e' impossibile), se i requisiti non cambiassero mai (altrettanto impossibile) e se conoscessimo in maniera esaustiva la soluzione al problema (e questo ammazza tutto, e' impossibile). La soluzione di un problema diviene sempre piu' chiara man mano che si risolve il problema stesso, ed e' giusto che il codice si evolva e si semplifichi man mano che conosciamo meglio il problema e la soluzione, da qui il refactoring che porta all'ultimo motivo per il quale i test sono importanti: hai mai provato a fare refactoring senza una batteria di test a proteggerti le spalle? Non lo auguro al mio peggior nemico

[fek]

Originariamente inviato da 71104

senza contare che naturalmente lo unit testing non permette di scoprire i leak...

Come dice Beck, la maggior parte delle volte che si dice che lo unit testing non permette di testare qualcosa e' perche' non si sa come testarlo

Se tu scrivi i test prima del codice, imponi al tuo codice di non avere resource leak scrivendo prima i test che controllano questa condizione, ad esempio che una determinata classe sia distrutta al termine di un'operazione.

[ri]

Originariamente inviato da DanieleC88

Mi pare che fek te l'abbia già suggerito, comunque, te lo ripeto:

era appunto un modo per darci un taglio :|
leggere fra le righe? :|

[cionci]

fek: mi interessa molto questo argomento... Hai link, ma soprattutto esempi... Ho fatto un po' di teoria su questa cosa, ma solo accennata...