Actual WORKING Production Code 2

public MetaBean(Element element, String elementString, Node node, String nodeString){
setElement(null);
setElementString(“”);
setNode(null);
setNodeString(“”);
}

Ancora una nota di colore : element è sempre la stessa istanza di node, solo che è castata a Element.

Advertisements

Essere xenofili

E’ forse vero che l’erba del vicino è sempre più verde, ma quando mi trovo davanti a certe cose mi chiedo come potrebbe non esserlo.

L’aeroporto di Lyon Saint Exupery si trova a una certa distanza da Lione, è raggiungibile in treno (treni normali e TGV) e in autostrada.

Se ci vai in macchina hai due opzioni di parcheggio : sosta breve e sosta prolungata.

La sosta breve ti permette di pagare meno se stai poco, ma se ci resti per ore ti costa molto di più che la sosta prolungata. Così se prendi l’aereo da solo lasci la macchina nella sosta prolungata, ma se accompagni qualcuno, o vai a prendere qualcuno, puoi lasciare la macchina nella sosta breve e, in un quarto d’ora, puoi accompagnare chi deve partire o andare a prendere chi deve arrivare pagando al minuto.

E’ logico, visto che alcune persone vanno in taxi / da sole, e l’altra metà vengono accompagnate / ricevute da amici e parenti. Direi che è scontata sia l’esistenza di entrambe le tipologie di viaggiatori, sia la dinamica delle loro necessità di parcheggio.

Ora… all’aeroporto di Torino Caselle, che, come si può facilmente evincere dal mio precedente post, frequento spesso, hanno notato lo stesso fenomeno delle persone sole e accompagnate, ma a quanto pare ne hanno tratto conclusioni molto diverse.

Esistono anche qui la sosta breve e la sosta lunga. La sosta breve però viene tariffata all’ora…. e fin qui, amen, non spacchiamo il capello in quattro.

Ma, udite udite, la prima ora costa 2 euro! Quattromila Lire, e poi il costo scende a un euro l’ora! Se poi ci stai 8 ore paghi meno ancora, e così via. Così se io vado a prendere la mia ragazza all’aeroporto ho due opzioni : restare in macchina e piazzarmi in doppia fila davanti al gate congestionato (dove trovo i gentili poliziotti che mi obbligano a fare un periodico giro di boa attorno all’aeroporto e dove rompo le palle a tutti), oppure entrare nel parcheggio, rimanerci magari dieci minuti, e pagare 2 euro.

Visto il macello che c’è davanti alle partenze, per il medesimo motivo, se voglio salutare con calma la mia ragazza devo pagare 2 euro, se no la devo scaricare in corsa.

Io non credo che i due ‘use case’ : accompagnato e solo con mezzo proprio, siano così difficili da analizzare, non credo che ci siano una banda di microcefali alla direzione, al contrario. Penso che l’intrinseca inadeguatezza di questo sistema tariffario sia palese alla direzione dei parcheggi (l’alternativa è che si tratti di scimmie bendate).

Io sono quasi certo che l’idea dei 2 euro la prima ora per la sosta BREVE sia una voluta manovra per lucrare sul fatto che sono stati eliminati tutti i possibili parcheggi alternativi a quelli dell’aeroporto stesso nel raggio di chilometri.

Io non sono xenofilo quando vedo le cose ‘funzionare meglio all’estero’. Io divento xenofilo quando mi rendo conto che a casa mia c’è chi architetta i servizi a mio preciso svantaggio.

Quindi non dico “che bella la Francia” se vedo che l’aeroporto di Lione non ha 200 macchine in doppia fila davanti al gate, dico “che gentaglia questi Italiani” se l’aeroporto di Torino ha il gate intasato dalle macchine di gente che vuole semplicemente evitare di essere sfruttata dall’ennesima “petty tyranny”.

Se questo vuol dire essere xenofili, ben venga la xenofilìa.

Torino Città Olimpica

Visto che manca pochissimo alle olimpiadi invernali di Torino 2006 l’aeroporto ha subito estesi lavori di ammodernamento.

In particolare la più utile aggiunta all’infrastruttura aeroportuale torinese è un buco nella sala di ritiro bagagli degli arrivals. Il grosso foro congiunge l’area dove i passeggeri ritirano i bagagli dai rulli con quella dove vengono trasferiti i bagagli dai carrelloni ai rulli stessi.

Ora coloro che giungono a Torino in aereo hanno finalmente il grande privilegio di riappropriarsi della propria valigia eseguendo una carica stile Braveheart direttamente sui carrelli dei bagagli e poi, volendo, riempire di mazzate gli aguzzini di sempre : gli addetti al bagaglio.

Ieri, ad esempio, per poco non si è giunti alle estreme conseguenze quando, dopo cinquanta minuti di attesa davanti ai rulli che giravano vuoti (non tutti i rulli, ovviamente, troppo facile, prima il rullo 3, poi il 7, poi il 3 di nuovo) i passeggeri del volo Catania-Torino hanno fatto irruzione tramite il suddetto buco e hanno trovato i loro agognati bagagli ancora ammonticchiati sui carrelloni e due simpatici omini con le cuffie che li fissavano con sguardo vacuo. Catatonìa? No.. pare che non gli avessero ancora detto su quale rullo metterli.

Io davvero spero che quel buco non venga chiuso. Non scherzo.

La trave nel mio occhio

Una tragedia annunciata.

Dopo un paio mesi di refactoring e testing di un codice legacy dei più gustosi mi trovo a essere ‘quello che risolve’, la stella, insomma, il padrone del vapore che sa fare cose che gli altri non conoscono (per quanto uno abbia provato a spiegare che è tutta questione di applicare un certo metodo… ma va beh!).

Bug dell’ultimo minuto su codice d’altri che non conosco : “Risolvilo tu!” Ormai nulla mi spaventa e questa richiesta è solo un’altra iniezione alla mia ormai super-muscolosa autostima.

Questo codice è orribile….

Beh, fai come hai già fatto in altri casi simili, circoscrivi l’intera ‘area’ del cambiamento che devi effettuare per fixare il bug con degli unit tests che ti assicurino che dall’esterno il codice modificato sia visto sempre allo stesso modo, insomma, la teoria della scatola chiusa. Quindi dovresti fare una mattinata di costruzione di tests che devono prima di tutto riuscire, poi inizi a toccare quell’unica linea di codice che sai essere la fonte del problema (e come potrebbe non esserlo, stupisce che funzioni il resto!), quando il bug è sistemato -E- tutti i test che hai scritto in precedenza tornano a essere verdi allora passi tutto nell’ambiente di acceptance per controlllare che i tuoi unit test rappresentino effettivamente ogni angolo della scatola. Fatto in precedenza, bug a posto e, a distanza di mesi, zero regressioni. Non solo è il metodo teorico più sicuro che conosci, si è anche dimostrato ottimo quando l’hai messo in pratica e, assieme a XP, è stato ciò che ha creato la tua reputazione, no? Saresti stupido a fare altrimenti… no?

Si però…. però in fin dei conti ci sono due settimane di tempo questa volta, non una giornata scarsa, creare quei tests è una vera scocciatura, sai che dovrai fare un bel po’ di extract method, e creare mezza dozzina di Stubs solo per avere l’impalcatura e avere dei punti d’accesso per creare i tests.

E’ pur vero che è più costoso trovare un errore in fase di acceptance testing che non trovarlo in fase di unit testing.. ma tanto TU sei la stella no? Mica ti potrai sbagliare così tanto, e poi anche fosse… due settimane.

E così faccio il fix senza scrivere i tests, ci sto attento, controllo ‘a mente’ che tutto torni e in mezza giornata (20 minuti di programmazione effettiva) mando tutto in acceptance.

Mi sono risparmiato un sacco di lavoro e la mia autostima non è per niente diminuita, anzi, mi stanno scoppiando i muscolazzi tanto sono pompato.

I criceti di acceptance tanto faranno il loro lavoro no? Non sono automatizzati, ma è come se lo fossero… no? Sono in tre o quattro e hanno solo quello da fare, visita tutte le pagine e controlla il test-book.. entro domani avranno sviscerato lo sviscerabile.

Sono in una botte di ferro.

Se proprio, per qualche assurdo motivo, esce fuori che avevo dimenticato di ‘vedere’ un qualche lato del codice che ho modificato, alzeranno la bandierina e io lo sistemerò in due minuti. Insomma, anche questo è feedback, anche questo è TDD!! Anzi, meglio, io faccio il D, e altri fanno il TD, grande ottimizzazione! Sono un genio assoluto, la mia autostima è così solida che si proietta e rassicura l’intero continuum spazio-tempo attorno a me, i bicchieri se cadono non si rompono, anzi, non cadono affatto, nessuno si prende l’influenza e il prezzo del petrolio scende in picchiata (ma solo se ci sono io nei pressi).

Il giorno dopo non ci sono notizie dai criceti… Vuol Dire Che Va Tutto Bene.

Due giorni dopo giunge l’ok :qui è tutto a posto, avanti così.

Troppo facile… + cinque metri cubi di helio. Ora ho altro da fare, devo pensare a portare il verbo nel mondo, quella faccenda è sicuramente chiusa per sempre… no?

Passa un altro giorno, poi una settimana, poi dieci giorni… quel giorno siamo tutti caldi per il rilascio finale, il più robusto rilascio della storia… grazie anche a me e a Godzilla, il mio ego, ormai mostruoso.

Era venerdì ovviamente :

– “Ah, abbiamo un bug riportato da acceptance… ci dai un’occhiata tu?”

– “Ci date un’occhiata voi -Oscuro Signore-”

– “Si, scusi, ci date un’occhiata voi Oscuro Signore?”

– “E sia!”

Spendo un paio d’ore solo per rintracciare la fonte del problema: sono passati dieci giorni e nè io, nè acceptance si ricorda più del bug 5325, quindi la descrizione è diversa e io inizio a guardare nel posto sbagliato. Dopo lunga analisi finalmente mi ritrovo a guardare quella stessa famosa linea di codice… e lì inizio a ricordare, ma poco, quella componente non è mia e non l’ho nemmeno ristrutturata, quindi la collective code ownership è un lontano fantasma che urla vendetta.

Soprattutto non c’è uno sputo di test a ricordarmi i dettagli. Da qualche parte.. da Godzilla, giunge un sibilo, come di aria che esce a gran velocità. Ma non ci faccio caso.

Con grossa fatica, e buttando un pomeriggio, che sarebbe stato meglio sfruttato su google, mi raccapezzo e scopro che non dovevo usare strAlF1, ma intBka1 (quella che sembra hungarian notation in quel codice è ormai solo un sottile mezzo di mistificazione, si tratta in entrambi i casi di stringhe). La modifica faceva quel che doveva fare, ma con la stringa sbagliata.

Amen, ormai non c’è tempo di scrivere degli unit tests, l’ultima volta che ho applicato quell’aureo sistema mi ci è voluta una giornata intera, ora è quasi sera e mancano 40 ore lavorative al rilascio, di certo non voglio fregarmi il week-end, ergo : metto una pezza al codice e una a Godzilla e me ne vado a casa.

Lunedì (1 day to release):

“Questa è la versione sistemata.. ma quelli di acceptance devono darmi -subito- prova e risultato dei loro tests.”

Entro sera due notizie :

– Da acceptance dicono che sono al 70% dei tests e che finora è tutto ok.”

– Pare che una mail di nove giorni fa dicesse qualcosa tipo : il fix non funziona, anzi è peggio. Ma a quanto pare qualcuno nella catena l’ha interpretata come : qui è tutto a posto, avanti così! Adoro il sistema del telefono senza fili, è per questo che deve essere adottato da tutti coloro che si occupano di applicazioni business critical fortemente integrate.

“Fessi di acceptance che non sanno scrivere le mail!” Dico io, e tutti : Amen Signore! Amen!

Martedì :

“Il sistema è online e siamo al 99% OK e quasi pronti al live.”

“Il restante 1% è KO e non si può procedere se non viene risolto -ORA- : pare che una delle sei pagine iniziali del portale non sia visibile…”

“Non potrebbe essere quella modifica che avevi fatto tu…”

“Come osi dubitare… e poi quella pagina non passa da quel codice no?”

“Beh, sì, è la prima che ci passa.”

“Ma me l’avreste detto fosse stato così, e poi figurati.. quella pagina non ha l’attributo B, se la si facesse passare dal mio codice modificato si pianterebbe tutto…. oh c…”

“La tua modifica non tiene conto dell’assenza di B?”

“Certo che no! Non c’era scritto da nessuna parte!”

“Oh c….”

“Ma come, ma una cosa del genere non me la dite… ma quelli di acceptance non l’hanno testata quella pagina?”

Tutto inutile, Godzilla ormai si chiama Spinky, la lucertola col sederino rosa.

“Pare che acceptance fosse così rassicurata dal fatto che tutto andasse bene in tutte le pagine interne che hanno dato per scontato che la pagina iniziale fosse a posto.”

Qualcuno sta battendo una pacca sulle spalle di Spinky :

“Tu non lo sapevi, non era colpa tua… dai che ci possiamo fare un work-around e tutto andrà a posto.”

“Eh, dannazione, ma proprio la pagina iniziale dovevano saltare nei loro controlli?!” E tutti : “Amen, Signore! Amen!”

Ma quale signore, magari secondo gli altri, per me sono la lucertola con il sedere rosa : anche detto, un fesso.

Per risparmiare mezza giornata di testing ho impiegato due settimane e ho consegnato del software fallato. Non sarebbe capitato se fosse stato un software più gestibile, meno soggetto a burocrazia e telefoni senza fili vari, ma è proprio per questi contesti che secondo me sono necessarie certe pratiche, fosse facile non ci sarebbe bisogno di un metodo.

Secondo me non è un caso che gli esercizi di TDD li si chiami Kata. E’ un po’ come un’arte marziale orientale, finchè si tratta di tirare pugni a un sacco tutte quelle scene e quegli strani allenamenti non sembrano giustificati, un pugno lo sai tirare anche senza quella roba, ma è quando ti ritrovi preso di sorpresa (tempi brevi), in condizione di svantaggio (poco potere nel sistema), senza alleati (sei l’unico responsabile di successo e fallimento del progetto) che quegli strani gesti di colpo assumono un significato.

Da allora, un mese fa circa, me lo ripeto spesso, oltre che a tenere a bada spinky.

Crap! Cancellare la sporcizia dal codice legacy

Il codice legacy, passato da mille mani, presenta sempre molti problemi, alcuni di questi sono una vera iattura e includono questioni di design cattivo o assente, rigidità, ripetizioni e chi più ne ha più ne metta. Una di queste problematiche, in un caso specifico, è trattabile programmaticamente in modo molto semplice e ingenuo.

Essendo io tale (semplice e ingenuo), ho sviluppato un piccolo plugin per Eclipse che fa esattamente questo.

Si tratta di identificare quei rami morti nella sequenza delle chiamate di un sistema che invariabilmente compaiono quando un nuovo sviluppatore si avvicenda al precedente e, non sicuro del ruolo di ogni metodo, non cancella quelli che ormai non vengono più chiamati in alcun modo. In breve si ci ritrova con metodi chiamati da metodi chiamati da metodi che non vengono mai chiamati a loro volta, questo perchè l’arborescenza delle chiamate del main è cambiata senza che venissero rimossi ogni volta i metodi inutili/obsoleti.

Quando il ‘main’ è unico (il sistema viene chiamato dall’esterno sempre con lo stesso messaggio) allora si può usare Crap! per scoprire cosa è diventato inutile.

L’algoritmo, come detto sopra, è semplice ed ingenuo, quindi non aspettatevi chissà quali prestazioni, ma, come dice il nome stesso, fa il suo sporco lavoro.