The Information School of the University of Washington
Debugging and Troubleshooting
INFO/CSE 100, Spring 2005
Fluency in Information Technology
http://www.cs.washington.edu/100
13-Oct-2004
cse100-07-debug
1
The Information School of the University of Washington
Readings and References
• Reading
» Fluency with Information Technology
• Chapter 7, To Err is Human
» “To err is human, but it takes a computer to
really foul things up”
13-Oct-2004
cse100-07-debug
2
The Information School of the University of Washington
Usare i computer...
• In IT, le cose vanno male … debugging è il
processo in cui si trovano gli errori
» Termine coniato da Grace Murray Hopper
• La migliore soluzione …non fare errori!
» Siate accurati … e funzionerà subito
» Seguite un processo che vi facilita le cose giuste
» I computer non hanno “senso comune" Fanno
quello che dite e solo quello.
13-Oct-2004
cse100-07-debug
3
The Information School of the University of Washington
Quando fate il Debug...
Debugging non è algoritmo: niente è garantito
• Ci sono linee guida…
Piuttosto che girovagare senza meta,
mettetevi nei panni di un investigatore
•
•
•
Chiedetevi: quali sono i miei indizi? Quali le mie ipotesi?
Ho bisogno di più dati?
Guardatevi consciamente mente lavorate– è un’esperienza
fuori dal corpo
Se vi affossate,non perdetevi d’animo “dove sto
sbagliando?”
siate Sherlock Holmes
13-Oct-2004
cse100-07-debug
4
The Information School of the University of Washington
Alcune direttive
Verificate che l’errore sia riproducibile
Determinate esattamente il problema
Eliminate le cause “ovvie” con la prova
Dividete il processo in parti buone e guaste
Se vi cacciate in un vicolo cieco, ridefinite le
informazioni che avete, cercate di individuare
l’errore
» Formulate delle ipotesi e testatele
»
»
»
»
»
13-Oct-2004
cse100-07-debug
5
The Information School of the University of Washington
Riproducibilità
• Primo passo: verificate se l’errore è
riproducibile
» You can't find something that you can't
reproduceNon potete trovare cose non
riproducibili
» Uscite e tornate indietro. Capita ancora?
• Fate ripartire l’applicazione.
• Provate con un’applicazione diversa
• Fate ripartire il sistema. A volte funziona,
specialmente se il guasto è in una periferica
Uscite e tornate indietro
13-Oct-2004
cse100-07-debug
6
The Information School of the University of Washington
Alla ricerca del problema
• Secondo passo: ipotesi sugli errori
» Spesso quando accade un guasto si propaga …
cercare all’indietro è una soluzione possibile
NON E’ un
problema
di stampante
Database
vuoto
13-Oct-2004
Etichette
Di indirizzi
File degli
indirizzi
Niente
stampa
cse100-07-debug
7
The Information School of the University of Washington
Eliminate le cose ovvie
• Terzo passo:eliminate le cose ovvie
“Se la causa è ovvia, il problema sarebbe stato
riparato!” – si, giusto.
» Ci sono alcune cose standard da controllare:
•
•
•
•
•
13-Oct-2004
Ingressi
Connessioni
“Permessi”
Cavi
Condizioni di funzionamento
cse100-07-debug
La ventola non
funziona, non
Si accende!
8
The Information School of the University of Washington
Isolate il problema
• Cerccate di “ripartire” la situazione in parti
che funzionano e parti che NON funzionano
• Formulate un’ipotesi sul guasto
• Fate meno assunzioni possibili
• Non prendete nulla per garantito
L’obiettivo è scartare quante più
cause possibili
13-Oct-2004
cse100-07-debug
9
The Information School of the University of Washington
Se finite in un vicolo cieco…
• Quando tutto sembra funzionare, che rabbia!
• Chiedetevi “Cosa sto trascurando?”
» L’obiettivo è vedere la situazione come essa E’,
non come vi sembra che sia
• Sto facendo troppe ipotesi?
• Sto trascurando gli indizi?
• Cosa posso semplificare?
• Consultate un amico
13-Oct-2004
cse100-07-debug
10
The Information School of the University of Washington
Fate previsioni e controllate
• A cominciare dalle parti , seguite il processo
» Una previsione mancata, dimostra…
• Un possibile guasto
• Un possibile errore
• Una possibilità di restringere il campo di ricerca
Dormirci sopra’ spesso aiuta!
13-Oct-2004
cse100-07-debug
11
The Information School of the University of Washington
Conclusioni
• Il debug non è algoritmo, ma ci sono delle
linee guida
» State calmi –
» Siate metodici
» Riconoscete di essere sorpresi quando trovate il
problema.
• Se foste perfetti, non sbagliereste mai ...
• Un po’ di umiltà non fa mai male
» Guardatevi mentre fate il debug – valutate
quello che fate e quello che dovete conoscere
13-Oct-2004
cse100-07-debug
12