Linee guida per l'esecuzione del debug

Articolo
09/12/2008

Aggiornamento: novembre 2007

Nelle linee guida riportate di seguito vengono illustrate alcune tecniche per l'esecuzione del debug del codice.

Operazioni necessarie

Imparare a utilizzare gli strumenti di debug.

È necessario comprendere il funzionamento e acquisire familiarità con gli strumenti di debug. Per ulteriori informazioni, vedere Debug in Visual Studio.
Conoscere la posizione in cui sono archiviati i simboli.

Poiché i simboli di ciascun prodotto devono essere archiviati nei server di simboli, è sufficiente conoscere l'ubicazione di tali server. Per ulteriori informazioni, vedere l'articolo "How to Use the Microsoft Symbol Server" della MSDN Library (informazioni in lingua inglese).
Studiare e risolvere gli errori che bloccano i processi.

Un'applicazione che non risponde più (si blocca) produce per gli utenti gli stessi danni di un arresto anomalo del sistema. In entrambi i casi si verifica una perdita del lavoro che è necessario recuperare. In precedenza si riteneva che i blocchi fossero più difficili da studiare e risolvere. La maggior parte dei blocchi dei processi non presenta più questo problema. Gli strumenti e le tecniche più recenti, infatti, consentono di risolverli con maggiore facilità. Per ulteriori informazioni, vedere l'articolo "How to Troubleshoot Program Faults with Dr. Watson" della MSDN Library.
Imparare a eseguire il debug di un minidump.

Molti tester e clienti producono errori nel codice senza il vantaggio di un debugger collegato. Se non si riesce a riprodurre il problema con facilità, si avrà a disposizione solo un minidump. Imparare a eseguire il debug mediante un minidump è fondamentale. Per ulteriori informazioni, vedere l'articolo "Minidump Files" della MSDN Library.
Imparare a recuperare uno stack danneggiato.

Il recupero di uno stack danneggiato è un'attività complessa ma necessaria in quanto molti errori che si verificano in scenari reali presentano stack apparentemente incomprensibili. Per ulteriori informazioni, vedere l'articolo "Troubleshooting Common Problems with Applications: Debugging in the Real World" della MSDN Library.

Operazioni da evitare

Presupporre che il test rilevi tutti gli errori.

Un test non sarà mai in grado di trovare tutti gli errori. Si tratta di un obiettivo irrealizzabile in quanto il codice è troppo complesso e anche se fosse possibile identificarli tutti, non si disporrebbe del tempo necessario per correggerli nella loro totalità. È opportuno quindi che il prodotto venga progettato in modo da evitare che contenga errori sin dall'inizio e che sia quindi necessario correggerli in un secondo momento. La qualità del codice sviluppato deve essere garantita dal programmatore in quanto il team destinato alle attività di testing si limita solo a verificarla e non si occupa della risoluzione dei problemi rilevati.

Operazioni consigliate

Imparare a eseguire il debug di applicazioni multithreading.

L'introduzione di thread in un programma può generare nuovi tipi di errori. Tutte le operazioni eseguite in un ambiente a thread singolo per facilitare il debug delle applicazioni diventano ancora più importanti quando il numero di thread aumenta. Non sempre, infatti, l'errore viene intercettato nel punto in cui si verifica. Generalmente viene rilevato in un secondo momento, magari in un altro thread. In queste situazioni non è nemmeno possibile risalire allo stack di chiamate per trovare il problema in quanto l'errore era in un altro thread, con un altro stack. Un approccio preventivo facilita il processo di debug in generale.
Imparare a effettuare il debug remoto.

Il debug remoto viene utilizzato quando si desidera eseguire il debug di un problema rilevato in un altro computer pur continuando a lavorare dal proprio computer. Gli sviluppatori si avvalgono spesso di questo tipo di debug quando un segmento di codice non presenta alcun problema sul proprio computer ma produce errori in un altro sistema. È possibile infatti che desiderino eseguirne il debug sull'altro sistema in modo remoto, senza la necessità di operare fisicamente dall'altro computer. Per ulteriori informazioni, vedere Installazione del debug remoto.
Imparare a eseguire il debug su server attivi.

Quando si tenta di eseguire il debug del codice su un server attivo a cui accedono i clienti vengono utilizzate procedure di debug diverse. Il ricorso a questo tipo di debug è sempre più frequente in quanto la quantità di codice destinata al Web cresce costantemente. Per ulteriori informazioni, vedere l'articolo "Troubleshooting Common Problems with Applications: Debugging in the Real World" della MSDN Library.
Inserire commenti in tutte le correzioni degli errori.

Quando si corregge un errore, includere nel codice un numero di versione, l'ID errore e il proprio alias. In questo modo sarà possibile contattare l'autore del codice per richiedere informazioni e chiarimenti relativi alla correzione.
Esaminare tutte le correzioni degli errori.

È opportuno analizzare tutte le correzioni apportate al codice. Chiedere ad almeno un'altra persona, un collega, di esaminare il codice.
Verificare la correzione degli errori di difficile individuazione prima dell'archiviazione.

Evitare di correggere lo stesso errore due volte. Utilizzare una build per verificare che la correzione sia giusta, soprattutto per gli errori di difficile individuazione.
Utilizzare un documento di rilascio di prova per segnalare tutte le correzioni degli errori.

Inviare tramite posta elettronica al team dedicato alle attività di testing un documento di rilascio di prova in cui siano riportate tutte le correzioni degli errori.
Utilizzare il server di simboli per indicizzare e archiviare i simboli del prodotto.

L'indicizzazione e l'archiviazione dei simboli del prodotto nel server di simboli rende più semplice e veloce l'esecuzione del debug da qualsiasi sistema, inclusi quelli dei clienti.

Operazioni non consigliate

Correggere gli errori di altre persone senza informarle.

Studiare il codice sviluppato da altri e tentare di correggerne gli errori è sicuramente un'ottima pratica. È utile infatti approfondire la conoscenza del codice altrui in modo da poter anche sostituire l'autore quando non è disponibile. È importante però segnalare le eventuali correzioni al proprietario del codice prima di procedere all'archiviazione.
Dichiarare un errore come "Non riproducibile" senza provare la stessa versione nello stesso ambiente.

È necessario ripristinare la versione precedente del prodotto in cui è stato rilevato l'errore. Non presupporre che l'errore sia stato corretto se non è presente nella versione corrente del prodotto. Non è detto infatti che la correzione sia stata effettuata. È possibile che il codice sia stato modificato e che l'errore sia quindi solo nascosto. Se si studia un errore fino ad osservarlo mentre si verifica, è possibile risalire alla causa originaria del problema ed eliminarla per evitare che si ripeta.