Una storia alla volta

Per sessant'anni il costo di scrivere codice ha deciso le nostre architetture. Quel costo è crollato. Ne è rimasto un altro.

Ad aprile, in un webinar, ho fatto una domanda alla sala: l'ultimo progetto su cui avete lavorato, quanto ci avete messo a capirlo? Un giorno: nessun pollice. Una settimana: qualcuno. Un mese: parecchi. Poi l'ultima: alzi la mano chi ancora oggi quel sistema non l'ha capito del tutto. Lì mi aspettavo l'esplosione, perché quando l'ho chiesto a mia moglie mi ha risposto che il suo, dopo vent'anni, ancora le sfugge.

Quel tempo lì è un costo, ed è il costo di cui parliamo di meno. Per sessant'anni le scelte di architettura le ha guidate un altro costo, quello di scrivere il codice. Negli anni Sessanta la macchina costava un patrimonio e il tempo macchina si prenotava: programmi piccoli, semplici per forza. Negli anni Ottanta il computer ha smesso di essere il pezzo caro ed è diventato caro il programmatore: sono arrivati gli oggetti, l'incapsulamento, le astrazioni che ti difendono dal cambiamento ("metti che un domani cambio database", capitato a chiunque dozzine di volte, giusto?). Poi il web, la scala, i microservizi, gli orchestratori. Strumenti nati dai principal engineer di Netflix e Amazon per problemi di Netflix e Amazon, e adottati da tutti gli altri leggendo, nella migliore delle ipotesi, un articolo. Spesso un titolo.

Lo so perché ci sono dentro anch'io. Preparando le slide di quel webinar ho scoperto che Roy Fielding, l'inventore di REST, considera REST solo ciò che è HATEOAS. Tutto il resto è RPC sopra HTTP. Faccio questo mestiere da trent'anni e l'ho imparato ad aprile.

Poi è arrivato il coding agentico, e i conti hanno smesso di tornare. Scrivere codice oggi costa poco: quando Claude Code è giù, io vado a farmi una passeggiata, perché tornare a scrivere come prima è come usare la tastiera coi guantoni da boxe. Ma se scrivere è diventato quasi gratis, le architetture costruite per risparmiare scrittura hanno perso il loro perché. L'unico costo rimasto in piedi è capire. Capire il dominio, il processo, il problema, prima ancora del codice.

E le nostre codebase, su quel costo lì, sono carissime. Chiedo un ordine a magazzino e l'implementazione mi risponde con un controller, che crea un DTO, che passa da un validatore, che chiama un service, che interroga il servizio prezzi, che mappa tutto per un repository che mi astrae la persistenza. Volevo una banana e mi avete dato il gorilla che la tiene e tutta la foresta intorno, come diceva Joe Armstrong. Quella catena racconta tutto di come ho implementato l'ordine e niente dell'ordine: cosa fa, perché esiste, dove vive nel mio business.

In azienda da noi questa cosa l'abbiamo presa di petto. Il modo l'ha inventato il mio capo; io mi sono limitato a formalizzarlo e a dargli un nome più serio del necessario, perché a un webinar sull'approccio delle storielle chi si iscrive? L'idea si tiene in una frase: ogni operazione di business è una storia, e una storia si legge dall'inizio alla fine in un posto solo. Un file per operazione. Dentro, tre fasi in fila: carichi tutto quello che ti serve, validi tutto quello che va validato, e solo alla fine esegui e tocchi il sistema. Se qualcosa deve fallire, fallisce prima di aver alterato mezzo mondo. Il file si chiama come l'operazione, la cartella parla del business, e niente magia: zero decoratori che dietro le quinte fanno cose, perché la magia confonde un umano e confonde pure l'agente.

Sì, ogni tanto questo significa ripetere del codice. Apposta. Quando mi sono opposto anch'io, all'inizio, brandivo il principio DRY come tutti. Poi sono andato a rileggermi da dove arriva, The Pragmatic Programmer di Hunt e Thomas, ventisette anni fa: parla di conoscenza. Ogni pezzo di conoscenza deve avere una sola rappresentazione autorevole nel sistema. Della duplicazione del codice in sé, lì dentro, c'è molto meno di quanto si racconti. E come dice Sandi Metz, la duplicazione costa molto meno dell'astrazione sbagliata.

La parte che mi ha sorpreso è cosa succede quando ci metti in mezzo un agente. Gli ho chiesto di rifattorizzare un'aliquota IVA che era spatarrata identica in tre file. Io avrei portato a fattor comune tutto: costante, subtotale, calcolo. Lui ha centralizzato la costante e ha lasciato l'aritmetica dov'era, spiegandomi che la costante è conoscenza condivisa, mentre ogni storia usa quella conoscenza a modo suo: un domani il rimborso tratterà l'IVA in un modo, l'ordine in un altro, e alla prima divergenza l'helper comune si riempie di if. Aveva ragione lui, e il codice si legge pure meglio.

Funziona ovunque? Da consulente vi rispondo: dipende. Va benissimo sul software di business, gestionali, ordini, fatturazione, workflow, coi team piccoli e medi e con le codebase mantenute da junior, che devono caricarsi in testa il business e basta. Va male sui sistemi ad alte prestazioni davvero distribuiti, sugli stack incatenati a un framework e sugli algoritmi pesanti. La buona notizia per il 99% di noi: tranquilli, Google è un datore di lavoro raro.

Tre pensieri per chiudere, gli stessi che lascio dal palco. L'agente è un amplificatore e per ora vi risparmia il giudizio: su una codebase chiara fa miracoli, su una confusa propaga il disastro alla stessa velocità, e la firma resta la vostra. La semplicità è finalmente una scelta: per sessant'anni era saggio frammentare per scrivere meno, oggi quel risparmio vale poco e capire costa come prima. E ogni processo ha una storia da raccontare: il prossimo ticket, prima di aprire l'editor, provate a immaginarlo come una storia. Poi guardate cosa succede quando la date in mano al vostro agente.

Il webinar completo è nel video; la codebase degli esempi è su GitHub.