Description
Se scrivi programmi innovativi, o ai limiti delle tue abilitá... o anche in caso contrario... i bug, nel tuo codice, ci saranno sempre. Ho molta esperienza a combinare bug, e quindi a scoprirli e rimediarli. A scuola non s'insegna come dar la caccia ai bug, quando t'insegnano programmazione e informatica... quindi, spiego quali atteggiamenti e capacitá aiutano a minimizzare i bug, trovarli, rimediarli, assicurare che non tornino mai piú, e distribuire le correzioni agli utenti del programma.
In questo talk descrivo come iniziare a cercare i dannati bug, dove preferiscono nascondersi, come il tuo cervello t'imbroglia (rendendo piú difficile trovarli), e le procedure che aiutano ad evitarli (o almeno a trovarli molto presto). Testing, pair programming, code reviews, l'open source ("dati abbastanza occhi, tutti i bug sono facili da vedere"), quando usare un programma bug-tracker, sono fra gli argomenti considerati.
Di tutti i consigli pratici nel tak, il piu importante: una volta confermata l'esistenza di un bug, mai cominciare a "ripararlo" fino a quando hai riprodotto il bug in un unit-test. Spesso questo compito ti stupisce, rivelando che il bug é altrove da dove pensavi - e comunque, scrivere il test, assicurarsi che non passa, riparare il codice, assicurarsi che adesso il test passa -- e lasciare il test (piccolo, semplice, veloce) per sempre nella tua suite di unit-test, é l'unico modo di assicurarsi che il bug non torni a farsi vivo senza essere notato (lo fanno, lo fanno, fidati...!). Alcuni spingono il concetto anche piú avanti e applicano tecniche "test driven" o "behavior driven" -- lungi dall'essere cattive idee, se non danneggiano la tua produttivitá.
Molti bug tendono a concentrarsi in piccole parti del codice -- in quelle che usano concetti troppo avanzati, in intricati alberi di decisioni booleane, o in quelle dove l'iniziale comprensione del problema (e quindi l'architettura per affrontarlo) era imperfetta. Se scopri dove sei stato "troppo furbo per il tuo bene", devi semplificare quelle parti del codice. Come dice Kernighan, "Il debug é due volte piú difficile che inizialmente scrivere il programma stesso. Quindi se sei il piú furbo possibile quando lo scrivi, come mai potrai fare a debuggarlo?"