Debugging: croce e delizia

By abell on 2009-09-08-19:53:54 | In debugging

Lo sviluppatore divide il suo tempo tra programmazione e debugging. O meglio, tra analisi, programmazione e debugging.

In realtà tra analisi, programmazione, debugging e studio di nuove tecnologie e linguaggi.

Per dirla tutta, a dire il vero si divide tra analisi, programmazione, debugging, studio di nuove tecnologie e linguaggi e cazzeggio su internet. Comunque sia, il debugging gli prende una buona fetta del tempo lavorativo.

Ricordo con raccapriccio i vari giorni passati a capire perché la mia libreria di array dinamici in C++ non funzionasse come doveva. Stavo imparando il linguaggio e quando liberavo la memoria non chiamavo il distruttore per ogni singolo oggetto. Persi giornate a scervellarmi, a fare prove su prove, rompendo quello che funzionava, guardando il codice con l'intensità con cui guarderei dalla finestra se avessi la Cucinotta come dirimpettaia, finché...

"Ah... bisogna mettere le quadre dopo il delete..."

Due caratteri due e il problema era risolto. Due quadre che mi avevano fatto perdere giorni, e la libreria semplicemente funzionava, come avrebbe dovuto fare dall'inizio.

Ci fu il sollievo dopo la frustrazione, ma anche la rabbia per il tempo perso. Cose del genere non devono capitare, mi dissi. Invece, continuano a capitarmi, a più di un decennio di distanza, in altri contesti, in altri linguaggi, a tutti i livelli dell'architettura software. Semplicemente, fanno parte del mestiere, così come il cuoco deve scottarsi ogni tanto e il falegname perdere una falange. Tutto sommato, presa con filosofia, non ci va tanto male.

E di recente ho capito che il debugging non è una iattura da maledire. E' un gioco che ogni tanto tocca fare, una sfida che ci viene posta dalla nostra stessa creatura. "Prova a trovarmi, se ci riesci".

Nell'esecuzione, il debugging somiglia alla ricerca scientifica:

  1. si verifica un evento inaspettato, che contraddice le nostre aspettative sul software. "Questo non dovrebbe succedere";
  2. formuliamo delle ipotesi (quando il contatore supera un certo valore, la variabile va in overflow);
  3. elaboriamo un esperimento e lo eseguiamo (inseriamo comandi che stampano il valore di variabili in momenti cruciali, esaminiamo il contenuto di variabili in un debugger);
  4. se l'esperimento conferma le nostre ipotesi, implementiamo una soluzione, altrimenti formuliamo nuove ipotesi e ripetiamo.

Purtroppo spesso il debugging si rende necessario a ridosso di scadenze o quando passeremmo volentieri il tempo a fare altre cose, ma se uno riesce a gustarsi il sapore della sfida intellettuale può essere anche divertente.