Pensa. Prima di committare, PENSA!

Sarò fissato io... ma di solito quando mi trovo di fronte ad un bug da fixare effettuo i seguenti step:

1. Analizzo il bug. Se non lo capisco chiedo spiegazione a chi l'ha aperto oppure a chi detiene la conoscenza del contesto.
2. Provo a replicare il bug (non è questione di non fidarsi ma chi apre il bug non conoscendo il codice non può fornire un quadro completo e quindi può solo ipotizzare che si verifichi secondo alcune condizioni evidenti a GUI o a configurazione).
3. Analizzo il codice per scovare il bug (nei casi peggiori potrei far uso di debugging pesante).
4. Analizzo le possibili alternative per fixare il bug (un fix anche semplice potrebbe causare infinite regressioni, soprattutto in una situazione da spaghetti code).
5. Fixo il bug.
6. TESTO il fix.
7. Committo il fix sul repository dei sorgenti e dichiaro fixato il bug con annesso commento del come, del quando e del perché.

Nei casi migliori però tutto il processo si potrebbe fermare al punto 2, poiché può capitare che vengano aperti bug che in realtà non lo sono, vuoi per una svista o vuoi perché il comportamento del programma deve essere proprio in quel modo, come dichiarato da specifiche. Della serie "It's not a bug, it's a feature!".

IMMAGINATEVI che nel mio team ci sia un altro sviluppatore che d'ora in poi chiameremo MasterBugProducer e che ha sempre fatto onore a questo soprannome e che sicuramente non ha mai avuto un approccio simile a quello spiegato sopra. 

IMMAGINATEVI un particolare use-case in cui bisogna interagire con una combo presente in una pagina JSP, la cui visibilità (della combo) dipende da alcuni fattori.

IMMAGINATEVI che inizialmente la visibilità di questa combo dipendeva da un controllo hard-coded e che io abbia migliorato la situazione rendendo la visibilità dello stesso dipendente da alcune configurazioni su DB, rispettando le specifiche.

IMMAGINATEVI che a MasterBugProducer venga assegnato un bug che dice "La combo non si vede mai" ma in realtà non è così perché chi ha segnalato il bug si è fermato alla pagina prima rispetto a quella dove la combo è realmente presente, senza andare avanti con lo use-case.

IMMAGINATEVI che MasterBugProducer invece di analizzare il fatto e/o provare a replicare il falso bug, abbia committato un qualcosa che sembra un fix ma non è: non solo avrebbe sovrascritto completamente la mia modifica sulla visibilità di COMBOX reintroducendo il controllo hard-coded, ma lo avrebbe anche scritto MALE producendo una regressione!
IMMAGINATEVI che MasterBugProducer non abbia mai fatto un test!

Ovviamente il cliente se ne accorge, notifica il nuovo bug prodotto dalla risoluzione di un falso bug, me lo trovo io tra le mani, scopro tutto il fattaccio, tiro fuori il mio manganello picchia-sviluppatori-che-dovrebbero-zappare-la-terra™, cerco MasterBugProducer scoprendo tristemente che oggi è in ferie.

Rassegnato da ciò fixo il bug (che consiste nel buttare nel cesso tutte le modifiche fatte da MasterBugProducer) e fiducioso del fatto che tra una settimana me ne vado via, scrivo codesto commento al commit:

Reverted fix by cocked head MasterBugProducer because he doesn't think before commit (PLEASE the next time, if you don't understand the code, can you ASK before OVERWRITE A WORKING FIX?!?!?)

Per quanto faccia cagare il mio inglese, penso di farmi capire molto bene.