Newsgroup: it.lavoro.informatica
Titolo: Debugging

Non so se in altre professioni esistano dei momenti cosï¿œ frustranti come 
il debugging dei programmatori.
Parlo del fatto che dopo tutta l'analisi, il design, l'interface con i
'project commissioner'  qualche poveraccio in fondo alla catena 
produttiva un bel giorno deve cominciare a codificare il tutto e 
produrre  un programma.
Oltre ad essere uno dei lavori piï¿œ scoccianti, piï¿œ ingrati che ci siano
ï¿œ anche il meno riconosciuto. Perchï¿œ secondo tutta la gerarchia che sta 
'sopra', il tempo che uno perde a fare il debugging non viene quasi mai 
riconosciuto. E' difficile spiegare al capo che anche se si sta con le 
gambe sulla scrivania a guardare il soffitto, uno sta 'lavorando' e pure 
molto seriamente. Le idee geniali vengono solamente in posizioni 'comode'.
Come quando si sta sul cesso.
Allora sï¿œ che la ignoranza, l'ingratitudine dei livelli gerarchici 
superiori, diventa reale, palpabile, visibile in tutta la sua magnificenza.
Salvo quando tutto gira perfettamente allora si che si hanno 
sosddisfazioni come quelle che Michelangelo provava quando vedeva il suo 
Mosï¿œ finito). La differenza tra me e Michelangelo ï¿œ che lui prese il 
martello e lo lanciï¿œ a Mosï¿œ dicendogli 'perchï¿œ non parli ?'.
Io invece stasera il partello lo lancerei contro il display che mi 
mostra il coding, gridando 'perchï¿œ non giri, maledfetto stronzo ???'
L'apice della frustrazione ï¿œ quando giornate intere davanti ad un codice 
magari come questo
for i= 1 to 20
print i, chr$(i)
next i
e non ti stampa un caï¿œï¿œo.  Poi scopri, che la variabile i era giï¿œ stata 
usata in un loop molto piu 'grande' che racchiudeva questo piccolo loop. 
Al che ti dai meritatamente del coglione e correggi. Cioï¿œ lo chiami ii.
Manco cosï¿œ non funziona. Allora ti arrovelli nel cercare perchï¿œ sto 
ca$$o di loop insignificante, semplicissimo, cornutissimo, non ti stampa 
una caï¿œï¿œo. Sarï¿œ perchï¿œ il chr(ii) deve essere sostituito da chrw(ii) per 
chï¿œ oggi si lavora in Unicode ?? Okay. Correggiamo.
Provati tutte le variazioni possibili, chr(ii), chrW(ii).
Manco pel kakkio.
Ho riposto il martello. Sono andato a farmi una passeggiata sul 
lungomare e sono ritornato di buonumore, pronto a riaffronatre il nemico.
Per fortuna che io sono comtemporaneamente Project manager, analyst,
system designer e codificatore, cosï¿œ posso prendermi a calci in culo 
davanti per ogni grado di gerarchia.
Ma ora mi fa male il deretano a forza di auto-calci in culo.
Ora, se stanotte non risolvo il problema, dovani esisterï¿œ un computer di 
meno ed un martello rotto !
Cari saluti collegiali.
Codificatori di tutto il mondo, unitevi !
John.

Non so se in altre professioni esistano dei momenti cosï¿œ frustranti come 
il debugging dei programmatori.
Parlo del fatto che dopo tutta l'analisi, il design, l'interface con i
'project commissioner'  qualche poveraccio in fondo alla catena 
produttiva un bel giorno deve cominciare a codificare il tutto e 
produrre  un programma. Che gira.
Oltre ad essere uno dei lavori piï¿œ scoccianti, piï¿œ ingrati che ci siano
ï¿œ anche il meno riconosciuto. Perchï¿œ secondo tutta la gerarchia che sta 
'sopra', il tempo che uno perde a fare il debugging non viene quasi mai 
riconosciuto. E' difficile spiegare al capo che anche se si sta con le 
gambe sulla scrivania a guardare il soffitto, uno sta 'lavorando' e pure 
molto seriamente. Le idee geniali vengono solamente in posizioni 
'comode'. Come quando si sta sul cesso.
Allora sï¿œ che la ignoranza, l'ingratitudine dei livelli gerarchici 
superiori, diventa reale, palpabile, visibile in tutta la sua magnificenza.
Salvo quando tutto gira perfettamente allora si che si hanno 
sosddisfazioni come quelle che Michelangelo provava quando vedeva il suo 
Mosï¿œ finito). La differenza tra me e Michelangelo ï¿œ che lui prese il 
martello e lo lanciï¿œ a Mosï¿œ dicendogli 'perchï¿œ non parli ?'.
Io invece stasera il martello lo lancerei contro il display che mi 
mostra il coding, gridando 'perchï¿œ non giri, maledfetto stronzo ???'
L'apice della frustrazione ï¿œ quando giornate intere davanti ad un codice 
magari come questo
for i= 1 to 20
print i, chr$(i)
next i
e non ti stampa un caï¿œï¿œo.  Poi scopri, che la variabile i era giï¿œ stata 
usata in un loop molto piu 'grande' che racchiudeva questo piccolo loop. 
Al che ti dai meritatamente del coglione e correggi. Cioï¿œ lo chiami ii.
Manco cosï¿œ non funziona. Allora ti arrovelli nel cercare perchï¿œ sto 
ca$$o di loop insignificante, semplicissimo, cornutissimo, non ti stampa 
una caï¿œï¿œo. Sarï¿œ perchï¿œ il chr(ii) deve essere sostituito da chrw(ii) per 
chï¿œ oggi si lavora in Unicode ?? Okay. Correggiamo.
Provati tutte le variazioni possibili, chr(ii), chrW(ii).
Manco pel kakkio.
Ho riposto il martello. Sono andato a farmi una passeggiata sul 
lungomare e sono ritornato di buonumore, pronto a riaffrontare il nemico.
Per fortuna che io sono comtemporaneamente Project manager, analyst,
system designer e codificatore, cosï¿œ posso prendermi a calci in culo 
davanti allo specchio, per ogni grado di gerarchia.
Ma ora mi fa male il deretano a forza di auto-calci in culo.
Ora, se stanotte non risolvo il problema, domani esisterï¿œ un computer di 
meno ed un martello rotto in piï¿œ!



era solo per rendere l'idea.
Nel loop summenzionato ï¿œ ovvio che non esce niente : i caratteri ASCII 
dallo 0 al 32 non sono 'visibili' :-)))
Ma era solo per rendere l'idea di un loop 'semplicissimo e cretino' ma 
che non funziona.

 Oltre ad essere uno dei lavori piï¿œ scoccianti, piï¿œ ingrati che ci siano [...]
Ciao, le tue parole presuppongono una distinzione netta fra analisi e
sviluppo che non ï¿œ detto debba sempre esistere.
Ci potrï¿œ essere uno sviluppatore senior che ha una visione piï¿œ di alto
livello e che, oltre ad occuparsi delle parti piï¿œ complesse, cerca di
trasmettere questa visione agli sviluppatori junior che, va da se, di
analisi ne faranno poca.
Ma ï¿œ, appunto, una questione di esperienza, non di distinzione netta
delle fasi di analisi e sviluppo che, nella mia esperienza, ï¿œ il modo
peggiore di lavorare: gli sviluppatori sono frustrati perchï¿œ devono
implementare dei requisiti assurdi su cui non hanno potuto dire la loro,
mentre chi ha fornito questi requisiti ï¿œ incazzato perchï¿œ, dopo giornate
di riunione-fiume, non vede realizzato quello che aveva deciso. Per non
parlare delle stime sui tempi.
Ti consiglierei qualche lettura introduttiva sulle metodologie agili,
per vedere il mestiere di analista/sviluppatore con un'ottica diversa.
Oppure, e lo dico senza intento provocatorio, puoi sempre cambiare
mestiere; non te l'ha mica prescritto il medico.
Ciao.
b.


caro Bishop, di 'cambiare mestiere' non ci penso nemmeno. Sono nato e 
morirï¿œ 'programmatore'.
Ho cominciato nel 1964, quando avevo 17 imparare 'i computer', quando 
allora marciavano a 'schede perforate'.
Ho seguito tutti gli step della carriera, programmatore, designer, 
analista fino ad arrivare, nel 1991, a 'capo' del 'PC and Workstation 
Coordination and support'. Nel 1996 mi sono ritirato a vita privata ed 
ora applico l'informatica alla biologia/fisiologioa, per 'hobby', per la 
ricerca.
Sono sempre stato profondamente innamorato ed orgoglioso della mia 
professione di programmatore di computer.
Il mio post (che ï¿œ piï¿œ uno 'sfogo' in tono umoristico) era piï¿œ per 
quelli che 'leggono' questo NG che per i 'professionisti', che sanno 
benissimo quanto 'ingrato' sia fare il programmatore.
Infatti, ho preso uno spunto da un articolo di fine anni 80 su una 
rivista americana divulgativa di computer, che esponeva gli stessi 
concetti.
Cioï¿œ in poche professioni la 'visibilitï¿œ' tra 'bug' e 'autore del 
programma' ï¿œ cosï¿œ nascosta e perfida. C'ï¿œ solo una categoria di persone 
che ha la peggio : i medici-investigatori come il Dr House.
In fisiologia perï¿œ ï¿œ comprensibile, perchï¿œ noi non abbiamo 'costruito' 
l'essere umano. Quindi non ne possediamo i 'circuiti stampati' o il 
source code.
Ma tutte le altre categorie (perfino gli ingegneri elettronici, che 
studiano i circiti) hanno una vita molto piï¿œ facile a 'trovare il bug' 
in un circuito che non funziona. Le tracce sono 'lineari'.
Invece, per avere una speranza di poter trovare con precisione in un 
software ci vorrebbe una opzione 'trace' del compiler, che riporti 
istruzione per istruzione (del linguaggio ad alto livello) esattamente 
le istruzioni assembler. E questo potrebbe anche non bastare. Infatti si 
dovrebbe vedere anche lo status dei registri 'prima' e 'dopo 
l'istruzione, per poter 'vedere quello ce succede'.
Questa almeno era la procedura normale ca. 25-30 anni fa.
Ora non so nemmeno piï¿œ se esistono queste possibilitï¿œ. Probabilmente per
le nuove generazioni di informatici sto parlando arabo.
Oggi si lavora a oggetti. Cioï¿œ per le cose 'normali' ci sono giï¿œ delle 
classi che fanno tutto. Da una parte ï¿œ difficile fare errori 'low 
level', dall'altra perï¿œ rendono il debugging piï¿œ difficile.
E credetemi, situazioni come quella che ho descritto, cioï¿œ di codice
'semplicissimo, cortissimo, elementarissimo, fottutissimo' che 'non 
gira' e non si capisce perchï¿œ, ï¿œ possibile averlo ancora oggi. Io ne ho 
un esempio proprio ora sotto il naso.
Ciao.
John.

 il debugging dei programmatori.
dipende. frustrante è quando si deve intervenire sul codice fatto da 
altri. sul codice che ho scritto io non mi capita più da tempo di perdere 
ore a scovare un bug, a meno che non sia codice che abbia scritto dieci 
anni fa.

rootkit schrieb:

A me invece non è andata altrettanto bene. Molissime volte infatti sono 
stato a ragionare su un pezzo di codice che 'logicamente' doveva 
funzionare tutto alla perfezione, invece non funzionava.
Il caso più eclatante della mia carriera, sul quale mi ruppi le corna 
diversi giorni, fu questo :
    CALL CICCIO(A, B, 6, D)
    .....
    .....
    SUBROUTINE CICCIO (F, G, K, Z)
    F = 1
    G = 2
    K = 8
    Z = 9
    RETURN
    .......
    .......
    R = 6
    WRITE (6,100) R
100 FORMAT(I5)
  ed il risultato era :  8.
Qualcuno puo' intuire il perchè ? A me allora (anni 70) ci volle una 
settimana per rendermene conto.
Scritto così, cioé isolate le proprie 'linee cruciali' del programma, la 
causa è facilmente identificabile. Ma su un programma di venti pagine,
con molte istruzioni, non è facile intuire il perchè non funziona.
Prima o dopo i bug si risolvono tutti. Ma il tempo che passa tra la 
scoperta del bug e la scoperta della causa è 'quantificabile 
economicamente' solamente perchè si contano le 'ore perse', ma è 
difficile stabilire degli standard, delle linee guida per misurare 
quanto tempo si 'puo' spendere al massimo' prima di trovare la causa.
Insomma  'per domani sera deve funzionare tutto' è una imposizione 
irrealistica.

 Codificatori di tutto il mondo, unitevi !
Ricordiamoci sempre che : "Chi poco compila, nulla linka" :-)
C'ya
  STeve

 anni fa.
Te lo ha mai detto nessuno che sei fortunato ? :-)

 gira' e non si capisce perchè, è possibile averlo ancora oggi.
Non c'e' bisogno di credere nulla.
Chi FA questo lavoro lo SA perfettamente e fa di tutto per non
dimenticarlo MAI.
Solo uno sciocco o chi non fa il nostro lavoro puo' credere di
scrivere SW senza errori.
C'ya
 STeve

 
Giusto... :-)))
Ciao.
John.

 che bello trovare qualcuno che ti capisce...<hahahahaha>
Basta cercare tra quelli oltre gli "anta" :-)))
48 fra pochi mesi :-(((
Non credo siano molti qua dentro che hanno presente cosa fosse un
HP2000A o una memoria a toroidi :-)))
C'ya
  STeve


Penso anch'io.  Io ho cominciato la professione sul IBM 1620 :-))
E nella stanza accanto c'era un IBM 750  A VALVOLE coperto da un 
lenzuolo. Come in un museo...<hahahahaah>
Ah che passione i computer !!
Ciao.
John.

 Te lo ha mai detto nessuno che sei fortunato ? :-)
no, aspetta, io parlavo di "scovare" un bug. poi risolverlo dipende, 
magari il bug è che quando ho scritto il codice non ho capito un tubo e 
va riscritto tutto :P
mi pare che john parlasse del caso classico in cui si brancola nel buio 
per ore e ore alla ricerca di una cazzatella all'interno del proprio 
codice. questo con i linguaggi che uso attualmente e con un sano utilizzo 
di essi è quasi impossibile che avvenga anzi sarebbe grave se succedesse 
spesso. cioè, con java, gli unittest, i debugger, è improbabile che uno 
possa impiegare tanto tempo per isolare il problema di una stessa 
variabile usata su due cicli annidiati (posto che questi sono errori che, 
fatti una volta, alla seconda scatta la riflessione filosofica "ma allora 
sono proprio idiota!").
poi è chiaro, se uno mi parla di altri tempi e di linguaggi in cui 
bisogna andare a cercare a mano gli errori su paginate di tabulati alzo 
le mani, capisco la frustrazione.
se vuoi il mio parere ti dico anche che per fare debug ci vuole come 
minimo metodo, esperienza e anche un po' di predisposizione. l'altro 
giorno è capitato che un mio collega stesse appunto brancolando nel buio 
da giorni dietro ad un malfunzionamento, ha chiesto il mio aiuto, in un 
ora ho isolato il problema in una libreria di terze parti e in due ore 
abbiamo scritto il workaround. poi per dirla tutta a fine giornata ho 
ricompilato la libreria di terze parti corretta (sia lodato l'open 
source) :-) confesso che un po' mi diverto ma lo dico a voce bassa perché 
è facile approfittarsene :-D
 

 
Ciao, la penso esattamente allo stesso modo! Mi era sembrato che
aspirassi a "mollare" il prima possibile lo sviluppo per dedicarti al
ruolo di "analista puro", senza aver acquisito l'esperienza necessaria.
Se non piace programmare, piuttosto che diventare pessimi analisti, imho
tanto vale diventare, ad esempio, commerciali puri, o grafici, o anche
idraulici!
Mi fa piacere apprendere che la tua situazione ï¿œ ben diversa (a
proposito, complimenti per la carriera).
p.s.: le situazioni di debug frustrante le ho vissute anche io, sia sul
mio codice che su quello di altri, ma non ï¿œ che le riunioni fiume "di
analisi" di 6 ore dove alla fine non si decide nulla non ï¿œ che siano
molto meglio eh!
b.

 
Non parlarmi di riunioni fiume. Erano riunioni in cui le prime voci 
dell'agenda, che consistevano nel finanziare progetti, per centinaia di 
migliaia di dollari, passavano in fretta. Poi per finanziare 500 marchi 
al mese per per pagare una donna delle pulizie che venisse a riordinare 
gli uffici alla sera, ci si impiegava due ore per decidere !

trovato il bug.
...mi ero dimenticato di chiamare 'call Init', il modulo che 
inizializzava un array.
Per punizione oggi non andrï¿œ al bar a vedere la partita !   :-)

 Per punizione oggi non andr� al bar a vedere la partita !   :-)
Questo forse puo' interessare (ce l'ho, ma non l'ho ancora letto):
http://www.pragprog.com/titles/pbdp/debug-it
  ngw
-- 
Nicholas Wieland (ngw)
Zooppa CTO
911 Western Avenue, Suite 420
Seattle, WA  98104  US

 ragionamento quello che avviene.
Certamente hai ragione, spesso è questo il modo più efficace di fare
debug, non solo nell'embedded.
Ma, caspita, 50 anni di "evoluzione" IT e tocca fare il debug coi
DISPLAY!
(chi conosce il Cobol sa cos'è.. :-) Vedo anche colleghi javisti che
spesso risolvono le cose in quel modo, perchè naturalmente i debugger
non possono essere usati direttamente in ambienti di produzione.
E siamo costretti pure ad imparare queste presunte tecniche
"evolute",  via via ammannite come la Soluzione.

 
interessantissimo. Ma ormai, preferisco andare 'a naso' (come Steve) 
facendo dei 'print' ovunque per seguire la traccia del programma. E' 
cos� che ho trovato il bug.
Esistono anche delle 'regole' che molte ditte adottano, proprio per 
evirare il pi� possibile errori.
Ai miei tempi, si era deciso che tutti i nomi di variabili dovevano 
iniziare con una lettera che identifdicava il tipo di variabile :
h mer le 'halfword', i per gli integer, f per i floating, d per i 
double, s per le stringhe.
Questo evitava di sfogliare decine di pagine per andare a vedere come 
erano state dichiarate. In sistemi molto grandi puo' fare la differenza.

 è facile approfittarsene :-D
:-)
C'ya
  STeve

 "evolute",  via via ammannite come la Soluzione.
:-)
Al momento non vedo molte alternative.
Non ho sentito nessuna news di qualche tool capace di gestire questo
genere di problemi.
Bei tempi quando un programma era lineare :-)
C'ya
   STeve

 Questo forse puo' interessare (ce l'ho, ma non l'ho ancora letto):
http://www.pragprog.com/titles/pbdp/debug-it
L'avevo visto tempo fa .. non sapevo se ne valeva la pena.
Se qualcuno lo legge poi potrebbe mettere giu' due righe di commento ?
Ho gia' tonnellate di libri ovunque e vorrei evitare di comprare roba
che alla fine descrive gia' quello che normalmente si fa :-)))
Denghiu
  STevee

 mestiere; non te l'ha mica prescritto il medico.
Anche agli imprenditori e ai dirigenti (o aspiranti tali) non glielo
ha mica ordinato il medico... Specialmente di lavorare nell'informatica
senza sapere niente di ingegneria del software
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 E poi, vuoi mettere? Almeno diversifichi l'attivit� :P
concordo in tutto. Infatti dopo una nottedi sonno ristoratore e qualche 
'print' messo nei punti strategici, ho identificato il punto dove c'era 
il 'bug' ed ho corretto. Era una inizializzazione che mi ero dimenticato 
di fare.
Ma sento che, con l'eta che avanza, mi affatico troppo gli occhi e il 
cervello e mi gira la testa dopo un paio di ore.
Penso che la prossima mossa 'ergonomica' sar� quella di avere un display 
grande come una TV al plasma, di 100cm di diagonale ed
una tastiera senza fili e programmare stando seduto sulla poltrona del 
salotto...<hahahahaha>



E' tra i prossimi. Se mi ricordo quando l'ho finito dico qualcosa. La 
qualit� media dei pragprog, comunque, � abbastanza alta.
