The Information School of the University of Washington 13-Oct-2004cse100-07-debug1 Debugging and Troubleshooting INFO/CSE 100, Spring 2005 Fluency in Information.

Presentazione sul tema: "The Information School of the University of Washington 13-Oct-2004cse100-07-debug1 Debugging and Troubleshooting INFO/CSE 100, Spring 2005 Fluency in Information."— Transcript della presentazione:

1 The Information School of the University of Washington 13-Oct-2004cse100-07-debug1 Debugging and Troubleshooting INFO/CSE 100, Spring 2005 Fluency in Information Technology http://www.cs.washington.edu/100

2 The Information School of the University of Washington 13-Oct-2004cse100-07-debug2 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”

3 The Information School of the University of Washington 13-Oct-2004cse100-07-debug3 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.

4 The Information School of the University of Washington 13-Oct-2004cse100-07-debug4 Quando fate il Debug... 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 Debugging non è algoritmo: niente è garantito

5 The Information School of the University of Washington 13-Oct-2004cse100-07-debug5 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

6 The Information School of the University of Washington 13-Oct-2004cse100-07-debug6 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 Riproducibilità

7 The Information School of the University of Washington 13-Oct-2004cse100-07-debug7 Alla ricerca del problema Secondo passo: ipotesi sugli errori »Spesso quando accade un guasto si propaga … cercare all’indietro è una soluzione possibile Database vuoto Etichette Di indirizzi File degli indirizzi Niente stampa NON E’ un problema di stampante

8 The Information School of the University of Washington 13-Oct-2004cse100-07-debug8 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: Ingressi Connessioni “Permessi” Cavi Condizioni di funzionamento La ventola non funziona, non Si accende!

9 The Information School of the University of Washington 13-Oct-2004cse100-07-debug9 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

10 The Information School of the University of Washington 13-Oct-2004cse100-07-debug10 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

11 The Information School of the University of Washington 13-Oct-2004cse100-07-debug11 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!

12 The Information School of the University of Washington 13-Oct-2004cse100-07-debug12 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