Ho già avuto modo di dire che quando si deve risolvere un comportamento applicativo anomalo è l’approccio che conta. In quell’occasione ho parlato del metodo replicare, isolare, congelare. Oggi vorrei entrare più nel dettaglio riguardo al secondo punto: isolare, cioè separare il più possibile l’anomalia dai comportamenti normali. Questa operazione serve a identificare la causa dell’errore, ed è forse la parte più difficile del lavoro. Occorre un metodo preciso.
Vi dico questo perché ho notato che in tante richieste di assistenza questo lavoro non è stato fatto o non è stato portato a termine. Capita spesso che, una volta terminata questa piccola indagine, la soluzione venga trovata in autonomia.
Per riuscire in questo compito io seguo un metodo ben preciso che si può riassumere in due passi: dividi e scegli.
La prima cosa da fare è suddividere gli elementi in gioco in due parti ben distinte, da analizzare basandosi sull’osservazione più che sulle conoscenze già acquisite. Bisogna non dare nulla per scontato e mettere tutto in discussione. Se, ad esempio, si deve capire perché un elemento di un report non viene formattato come previsto durante la stampa, le parti in gioco potrebbero essere la query e gli eventi di formattazione.
Il secondo passo è scegliere quale dei due insiemi scartare e su quale invece deve essere continuata l’indagine. Per farlo occorre ideare un test per capire se è la query che non restituisce i dati nella forma che ci si aspetta, oppure se sono gli eventi di formattazione che non considerano correttamente un caso particolare. Il risultato di questo test ci permette di restringere il campo d’indagine. Se si è evidenziato il problema, possiamo ripetere questo metodo concentrandoci sulla sola parte che lo contiene. Se entrambe le parti non hanno dato problemi, allora dovremo riapplicare il metodo scegliendo un insieme di elementi diverso.
Può sembrare un approccio ovvio, ma spesso le contingenze portano ad affrontare i problemi senza questo rigore. E così ci si trova a guardare all’applicazione tutta insieme, cercando un’improbabile intuizione sulla natura dell’errore durante la lettura di un debug sterminato.
Se non avete un vostro metodo di ricerca dell’errore, vi consiglio di provare questo.
Per noi funziona sempre.
