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