De rerum bug fixing
5 09 2008Quando si arriva finalmente nel momento di consegna in un progetto software, tutti bravi programmatori si rilassano. Le ultime fatiche, nottate, righe di codice, discussioni hanno portato al tanto desiderato rollout in produzione del vostro progetto.
Tutti i libri di progettazione del software parlano anche di una parte del ciclo di vita del progetto che può risultare molto urticante: il bug fixing!!!
Non esiste una vera e propria letteratura che vi permette di apprendere i rudenti essenziali di questa fantastica fase del ciclo di vita del software. Ognuno affronta la cosa come meglio crede, quindi in questa umile sede mi permetto di delineare qualche linea guida che potrebbe risultare utile…
Punto 1. Quando c’è un’anomalia bisogna subito capire il contesto funzionale dove si verifica, per capire il corretto funzionamento che dovrebbe avere
Punto 1 nella realtà. Secondo la sempre giusta legge di Murphy, se te conosci il 70% delle funzionalità di un progetto, l’anomalia che ti verrà assegnata è nel rimanente 30%. Inizia quindi una laboriosa ricerca nei meandri di documenti di specifica e di dettaglio che dovrebbero farti capire come la cosa funziona (o almeno dovrebbe).
Punto 2. Talvolta potrebbe essere utile confrontarsi con la persona che ha sviluppato una certa funzionalità per poter accelerare i tempi di risoluzione dell’anomalia
Punto 2 nella realtà. Tendenzialmente la persona che scritto una determinata funzionalità, specialmente se colpevole di un’anomalia tende a dimenticarla poco dopo la consegna. Praticamente tutta la conoscenza che aveva accumulato casualmente vola via a tal punto che può anche dirti “Ma sei sicuro che l’abbia fatta io ’sta cosa?”. In tale circostanza bisogna armarsi di tanta pazienza e cercare di ristudiarti tutta la funzionalità da solo o cercare l’aiuto di qualche anima santa che talvolta viene in tuo aiuto
Punto 3. L’utilizzo di pattern noti nello sviluppo e di un flusso generalmente ben definito dell’applicazione può aiutare molto per identificare il punto in cui si verifica un problema
Punto 3 nella realtà. Purtroppo la parte che non funziona non è quasi mai in un punto del codice “pulito”, altrimenti sarebbe troppo semplice. L’anomalia è malefica, cattiva, annidata vicino a quel pezzo di codice che in teoria quasi non dovrebbe essere usato perchè deprecato o che comunque pure il compilatore quasi ignora.
Punto 4. Gli strumenti di sviluppo sono il migliore amico dello sviluppatore e ti vengono incontro nel momento del bisogno
Punto 4 nella realtà. Troppe volte succede che sono propri alcuni maledetti tool di sviluppo che creano problemi durante lo sviluppo e che poi “ricicciano” soltanto nel momento della produzione (solo a titolo d’esempio potrebbe essere un bellissimo prodotto della Serena Software). Oltre a questo come non nominare il simpaticissimo problema del DISALLINEAMENTO, che magari avviene tra diverse versione del vostro software e che quindi manda allegramente a puttane pezzi di codice.
Punto 5. Durante il test di alcune funzionalità il vostro cliente potrebbe inavvertitamente dimenticare alcuni aspetti delle feature richieste e quindi aprire anomalie che non esistono
Punto 5 nella realtà. Tu paghi, tu decidi, quindi voglio sperare che quando vai a testare una cosa conosci l’applicazione e quello che deve fare. Invece questo potrebbe non verificarsi e quindi può capitare che il simpaticissimo cliente apre anomalie, facendoti perdere tempo (vedi altri punti precedenti) per arrivare alla conclusione che non è un problema del software consegnato ma semplicemente il cliente nemmeno sa quello che vuole.
Si potrebbe continuare ancora a lungo ma sento che almeno con questo piccolo post ho dato sfogo a qualche settimana di BUG FIXING!!!!!
P.S.
Un saluto al carissimo Roberto che in questo momento affronta in prima linea il cliente tutto solo soletto
Categories : fun, personale, programmazione, pensieri
