Ciao, e benvenuto nella sesta puntata della cinquantasettesima stagione. Nella scorsa puntata abbiamo visto il flagello delle interrogazioni nascoste. Oggi guardiamo la manopola che sta dietro a quel flagello, la decisione che, presa bene, lo previene, e presa male, lo scatena. Oggi parliamo di caricamento pigro contro caricamento impaziente.
Partiamo dalla domanda di fondo, perché è semplice ma decisiva. Quando carichi un oggetto, per esempio un utente, cosa deve fare il mappatore con le cose collegate, come la sua azienda o la lista dei suoi ordini? Le va a prendere subito, insieme all'utente? Oppure aspetta, e le prende solo se e quando tu le tocchi davvero? Non è un dettaglio tecnico: è una scelta che decide quante volte il tuo programma andrà a bussare al database. E le due risposte possibili hanno due nomi, e due caratteri opposti.
Voglio darti il primo carattere, il pigro. Il caricamento pigro dice: prendo solo l'utente, e delle sue cose collegate non mi occupo. Le andrò a prendere più tardi, solo nel momento esatto in cui il tuo codice le chiede. È un atteggiamento economo: non fatico per dati che forse non useremo mai. Se ti serve solo il nome dell'utente, il pigro è perfetto, perché non spreca un solo viaggio al database per l'azienda che non guarderai. Ma, e qui torna il fantasma della puntata scorsa, se poi in un ciclo tocchi le cose collegate di cento utenti, il pigro fa scattare cento viaggi separati, uno per volta. È proprio la pigrizia, applicata dentro un ciclo, a generare il flagello.
Voglio darti il secondo carattere, l'impaziente. Il caricamento impaziente dice: quando prendo l'utente, prendo subito anche tutte le sue cose collegate, in un colpo solo. È un atteggiamento previdente: porto a casa tutto quello che potrebbe servire, così non devo tornare. Se sai che userai le aziende di tutti gli utenti, l'impaziente è la salvezza: due viaggi, non centouno. Ma anche l'impaziente ha il suo difetto opposto: se poi le aziende non ti servivano, hai caricato una montagna di dati per niente, sprecando memoria e tempo su cose che non guarderai. Troppa premura è uno spreco tanto quanto troppa pigrizia.
Voglio darti l'immagine che rende chiara questa idea, perché la fissa. Pensa a fare la spesa con in mano una ricetta. Il modo pigro è comprare solo il primo ingrediente, e poi tornare al negozio ogni volta che la ricetta ne chiede un altro. Se cucini solo l'antipasto, hai risparmiato: non hai comprato roba inutile. Ma se cucini tutto il menu, farai dieci viaggi al negozio. Il modo impaziente è comprare in un colpo solo tutti gli ingredienti della ricetta. Se cucini tutto, geniale: un viaggio e via. Ma se poi ti fermi all'antipasto, hai riempito la dispensa di roba che marcirà. La domanda giusta, in cucina come nel codice, è sempre la stessa: quanto di questa ricetta cucinerò davvero?
Voglio darti la regola pratica, perché è ciò che ti serve. Non esiste un carattere giusto in assoluto: esiste quello giusto per la situazione. La regola è: sii pigro quando accedi ai dati collegati raramente e in modo imprevedibile; sii impaziente quando sai che ti serviranno, soprattutto dentro un ciclo. Il pericolo più grande è non scegliere affatto, e lasciare che sia il valore predefinito del mappatore a decidere per te, alla cieca. Perché il valore predefinito, qualunque sia, sarà giusto in metà dei casi e sbagliato nell'altra metà. La padronanza sta nel decidere tu, consapevolmente, caso per caso. E il modo per farlo bene è sempre lo stesso: guardare le interrogazioni che partono davvero, misurare, e correggere il tiro dove serve. Il carattere giusto non si indovina a tavolino, si scopre osservando come la tua applicazione usa davvero i suoi dati.
Voglio darti la lezione generale, perché va oltre. La lezione è che quando fare una cosa è importante quanto se farla. Prendere o rimandare, calcolare subito o solo al bisogno: sono decisioni che attraversano tutta l'informatica, non solo i database. E quasi sempre la risposta non è una regola fissa, ma una domanda sull'uso reale: userò questo dato, o no? Con che frequenza? Rispondere bene a questa domanda, invece di affidarsi a un valore predefinito, è ciò che trasforma un programma lento in un programma veloce, spesso senza cambiare una sola virgola della logica. È una delle poche ottimizzazioni che regalano molto e costano poco: non riscrivi il programma, cambi solo il momento in cui i dati vengono presi. Poche cose, nel nostro mestiere, hanno un rapporto così buono tra fatica spesa e velocità guadagnata.
Per oggi ci fermiamo qui. Abbiamo visto la manopola dietro il flagello: caricamento pigro contro impaziente. Il pigro prende solo l'oggetto e va a cercare le cose collegate solo quando le tocchi: perfetto se non ti servono, disastroso dentro un ciclo, dove scatena le tante interrogazioni. L'impaziente prende tutto subito: la salvezza se userai i dati collegati, uno spreco se poi non li guardi. Come fare la spesa un ingrediente alla volta oppure tutto in un viaggio: dipende da quanto della ricetta cucinerai davvero. La regola: scegli tu, consapevolmente, invece di subire il valore predefinito. Nella prossima puntata: lo schema che vive nel codice, le migrazioni. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.