Ingenuita' Ingegnerizzata

Avevo scritto un frammento di codice in PHP. Dato un input, impiegava 20 secondi a restituire l'output. Ho aggiunto 10 righe, ed ora ce ne mette un paio.
Il protagonista della storia e' GASdotto (il gestionale per Gruppi di Acquisto qualche volta menzionato su questo blog), applicazione che ho imbastito seguendo il piu' possibile la regola secondo cui e' meglio del codice compatto e generico anziche' una gestione manuale (ed ottimizzata) di tutti i casi possibili. Con risultati evidentemente non sempre gratificanti.
Tutta la componente server del programma (cosiccome del resto anche la parte client, in Java) e' fondata su una classe elementare che funge da astrazione per tutte le altre: le sottoclassi di questa definiscono solo quali sono le variabili che contiene (tipo: lo User ha un firstname che e' una stringa, un lastlogin che e' una data...), e tutta la parte di ricostruzione dell'oggetto dal database, serializzazione e deserializzazione JSON, salvataggio, aggiornamento e cancellazione e' implementata una volta sola nella classe di partenza. Tale meccanismo copre anche il caso in cui un oggetto contenga un array di oggetti di altro tipo, i quali sono mappati sul database seguendo una logica predefinita e dunque uguale per tutti e riportata in forma di codice una volta sola. Insomma: una architettura che mi ha permesso di realizzare pressoche' tutta la parte server del software in 2000 righe di PHP (stando alle attuali statistiche su Ohloh), ed in cui posso aggiungere nuovi elementi completi di tutte le funzionalita' con una manciata di altre righe.
Fin qui tutto bello. Il brutto viene mettendo insieme molti oggetti che contengono a loro volta molti oggetti.
Dato un numero di ordini, i quali contengono un numero di prodotti ordinati, ognuno dei quali fa riferimento ad un prodotto disponibile nell'ordine, ognuno dei quali fa riferimento al fornitore che lo distribuisce, e' evidente (soprattutto col senno di poi...) che la quantita' di componenti coinvolti nella semplice richiesta di avere tutte le merci che sono state richieste dai membri del Gruppo di Acquisto e' elevata. Ed attenendosi al primo modello operativo di riferimento ognuno di essi deve essere ripescato dal database e ricondotto ad un oggetto. Anche se e' gia' stato prelevato all'interno dell'elaborazione della stessa richiesta.
Non voglio neanche sapere quante query venivano eseguite in tal frangente, ma non appena mi sono accorto del problema ho applicato in pochi secondi una soluzione basata su un banale array associativo usato a mo' di cache temporanea per tener traccia di quanto gia' ottenuto e recuperarlo subito senza ricostruirlo daccapo: certamente non ottimale, ma funzionale.
La morale di questa narrazione e' di non fidarsi sempre ciecamente dei dogmi dell'ingegneria software: astrarre e' un'ottima cosa, soprattutto se si e' pigri, ma, giacche' la perfezione non e' di questo mondo, per quanto raffinato il vostro sistema avra' sempre una falla, dunque tanto vale rassegnarsi e prepararsi da subito a dover applicare un salutare ed ingenuo hack di quando in quando.