Anti-pattern: pausa caffè

Durante i miei trascorsi universitari ho potuto notare che le “materie” che mi hanno arricchito di più sono sempre state quelle più orientate alla teoria che alla pratica. La cosa si è rivelata lampante durante la preparazione dell’esame di “Sistemi II” che richiedeva la presentazione di un caso di studio dall’analisi al codice finale. L’esame ha avuto risvolti tragicomici così eclatanti che sebbene abbia difficoltà a ricordare la data della seduta di laurea, non ho alcuna difficoltà a ricordare quel maledetto 28 Maggio 1993. Da allora ho sempre guardato con occhio estremamente critico a tutto quanto recepito durante quel corso e mi son ritrovato più che spesso a fare cose e riflettere: “quanto aveva torto quel professorone”. Insomma, la mia è diventata una vera e propria malattia, per fortuna ne sono conscio e penso di essere in via di superamento del trauma. Un episodio però mi ha colpito in maniera positiva ed è ritornato alla mente ieri. Assistevo all’esposizione di un collega (quanto ci piaceva appellarci così) e al fatto che volesse difendere l’implementazione estremamente criptica quanto esageratamente performante di un pezzo di codice. Implementazione anche molto curata rispetto a quasi tutto il resto del lavoro. Al che il professorone esordisce: “immagino che questo pezzo di codice per essere così intenso debba essere fondamentale…”. Il malcapitato però ammette che si trattava di un pezzo di codice non critico al funzionamento dell’applicazione sul modello di “codice di rigenerazione degli indici” che fa tanto figo a pronunciare ma poco utile alla prova dell’atto pratico, tant’è che “il cliente è supposto di rigenerare gli indici al massimo una volta al giorno per garantire prestazioni adeguate all’uso normale dell’applicazione”. Fu lì, durante la seduta d’esame, che il professorone espose l’anti-pattern della pausa caffè (nome ‘inventato’ da me in quanto la Gang of Four ha pubblicato il mitico lavoro solo nel 1995). Il professorone sosteneva che pezzi di codice lento e scarsamente ottimizzato, se accoppiati con funzionalità di uso molto raro in applicazioni di carattere produttivo (leggasi: destinate agli uffici), sono fondamentali per la soddisfazione dei clienti che – nei momenti più noiosi della giornata – possono giocare la carta “lancio la rigenerazione degli indici e vado a fare un caffè”. Il professorone faceva altresì notare che il fatto che tale funzionalità sia non-fondamentale all’uso della applicazione è conditio sine qua non per l’introduzione dell’anti-pattern. Se un pezzo di codice di uso molto frequente richiedesse lunghe pause caffè si avrebbe l’effetto collaterale di produrre clienti impazienti, insoddisfatti o magari epilettici. Osservazioni come queste meritano un solo tipo di aggettivo: geniali.

A questa storia sono così affezionato che la riciclo spesso quando vedo qualche collega combattere con l’ottimizzazione esagerata di pezzi di codice di scarsa utilità. Cosa buffa ieri, mentre ero in preda ad un piccolo attacco di insonnia che mi ostinavo a combattere con un po’ di refactoring domino (*), mi sono accorto che stavo facendomi pippe mentali davanti ad un pezzo di codice perfetto o quasi per l’anti-pattern pausa caffè generalizzato. È stato un lampo e pienamente soddisfatto della scelta “strategica” sono tornato a nanna. Certe volte funziona così.

-quack

(*) materiale per un’altra storia.