Michele Polo

Imparare dai Giganti: Analogie Interdisciplinari nello Sviluppo Software

Se ho visto più lontano, è perché stavo sulle spalle di giganti
— Bernardo di Chartres, Isaac Newton, Albert Einstein

Una Scienza Giovane sulle Spalle di Giganti

Quando ho iniziato a lavorare come sviluppatore software - o forse ero ancora all'università - qualcuno mi ha detto: "L'informatica è una scienza giovane, si deve basare sulle scienze più antiche."

L'informatica, nata formalmente a metà del Novecento, ha poco più di settant'anni. L'architettura ne ha migliaia. La medicina altrettanti. La filosofia ha attraversato millenni di pensiero strutturato. La fisica ha Newton, Galileo, Einstein.

Noi abbiamo... Dijkstra.

Non è poco, ma è chiaro che c'è un patrimonio di conoscenza umana là fuori, pronto per essere tradotto in pattern, principi e pratiche software. E ho scoperto che le migliori metafore per capire il codice non vengono dal codice stesso.

Christopher Alexander e la Gang of Four

Il primo esempio che ho incontrato sono stati i Design Pattern della Gang of Four (Gamma, Helm, Johnson, Vlissides). Il loro libro del 1994, "Design Patterns: Elements of Reusable Object-Oriented Software", è considerato una bibbia dell'ingegneria del software. I "pattern" non sono certo nati nel software. Sono nati nell'architettura fisica, con Christopher Alexander. Nel 1977, Alexander pubblicò "A Pattern Language: Towns, Buildings, Construction", dove catalogava 253 pattern architettonici: dalla scala delle città fino al dettaglio delle finestre. Seguendo quei pattern chiunque avrebbe potuto ottenere un risultato oggettivo, non soggettivo. Così utilizzando colonne strette e alte si accentuano eleganza e verticalità, introducendo allo stesso tempo sfide strutturali quali l'instabilità laterale.

Alexander scriveva di edifici. La GoF ha tradotto quei concetti in classi e oggetti.

Il Factory Pattern? È la bottega dell'artigiano che produce oggetti su richiesta, senza che il cliente debba sapere come vengono costruiti.

Il Singleton? È il municipio della città: uno solo, accessibile a tutti, punto di riferimento centrale.

Il Decorator? È l'intonaco su un muro: aggiunge funzionalità senza modificare la struttura portante.

L'architettura fisica ha insegnato al software come organizzare la complessità.

Debugging e Medicina.

In ambito sanitario esiste il concetto di sintomo patognomonico: un sintomo così specifico che, da solo, è sufficiente per diagnosticare una malattia. La tosse "abbaiante" del croup. Le macchie di Koplik nel morbillo. Il tremore a riposo del Parkinson.

Nel debugging, cerchiamo la stessa cosa.

Invece di perdersi in mille log generici, un bravo debugger cerca quel segnale distintivo, quell'errore che può manifestarsi solo per una causa specifica.

  • NullPointerException? Patognomonico: qualcuno non ha inizializzato quella variabile.
  • ECONNREFUSED su porta 5432? Patognomonico: PostgreSQL non è in esecuzione.
  • Maximum call stack size exceeded? Patognomonico: ricorsione infinita.

Ho imparato anche le strategie della radiologia diagnostica: "guardare sotto la pelle" del software. Non fidarti di quello che l'utente ti racconta (il sintomo riferito). Vai a vedere cosa succede davvero (l'imaging). Usa i log come una TAC. Usa il debugger come un'ecografia in tempo reale.

La medicina ha insegnato al software come diagnosticare i problemi.

Le Corbusier e il Corpo della Città

Da qualche parte ho letto di Le Corbusier e di Chandigarh, la città indiana che progettò negli anni '50.

La pensò come un corpo umano: il Campidoglio nella posizione del cervello, il centro commerciale dove si troverebbe lo stomaco, le strade principali come arterie, i parchi come polmoni.

Una metafora organica per una struttura urbanistica.

E non è forse quello che facciamo quando progettiamo software?

  • Il controller è il cervello: riceve input, coordina, decide
  • Il database è la memoria a lungo termine
  • La cache è la memoria a breve termine
  • Le API sono il sistema nervoso: comunicazione tra componenti
  • I microservizi sono gli organi: specializzati, interconnessi, collaborativi

Quando un sistema è "malato", usiamo termini anche medici: memory leak (emorragia di memoria), bottleneck (stenosi), dead code (tessuto necrotico).

L'urbanistica ha insegnato al software come pensare in sistemi.

La Sezione Aurea: Da Leonardo alle UI

La sezione aurea (φ ≈ 1.618) affascina l'umanità da millenni. Leonardo la usò nell'Uomo Vitruviano. I greci la applicarono al Partenone. I pittori rinascimentali la nascosero nelle loro composizioni.

E oggi, la usiamo nelle interfacce utente.

La regola del φ applicata al layout:

  • Sidebar a 1/φ della larghezza totale ≈ 38%
  • Contenuto principale a φ-1 ≈ 62%
  • Spaziature proporzionali che "sembrano giuste" senza sapere perché

Non è magia. È che il cervello umano, dopo millenni di evoluzione, trova armoniose certe proporzioni. E quelle proporzioni funzionano per gli edifici, per i dipinti, e per le dashboard.

Allo stesso modo, la regola dei terzi di Steve McCurry (e della fotografia in generale): posiziona gli elementi importanti sulle intersezioni di una griglia 3x3. Funziona per le foto del National Geographic. Funziona per il posizionamento del bottone "Call to Action" in una landing page.

L'arte ha insegnato al software come essere bello.

Aposematismo: I Colori che Avvertono

E poi c'è l'aposematismo, un fenomeno biologico che la natura usa da milioni di anni.

Vespe, rane freccia, serpenti corallo: tutti sfoggiano colori vivaci - giallo, rosso, arancione - per comunicare un messaggio inequivocabile ai predatori: "Sono pericoloso, stai lontano."

Non è una coincidenza che nelle nostre UI usiamo esattamente gli stessi colori per gli stessi scopi:

  • Rosso: errore, pericolo, eliminazione. Il bottone "Delete" è rosso perché deve gridare "attento!"
  • Giallo/Arancione: warning, attenzione. Come la vespa che ti avvisa prima di pungere
  • Verde: sicuro, successo, procedi. L'assenza di minaccia

Questi non sono colori scelti arbitrariamente dai designer. Sono pattern che il nostro cervello ha imparato a riconoscere in milioni di anni di evoluzione. Quando vediamo un banner rosso, scatta lo stesso meccanismo primitivo che faceva arretrare i nostri antenati davanti a un serpente corallo. Anche i colori dei semafori mutuano lo stesso significato, che ci ha insegnato la natura.

La biologia ha insegnato al software come comunicare il pericolo.

Strategie Mnemoniche: Il Pattern della Lavatrice

Nel corso degli anni ho sviluppato una mia strategia personale per ricordare i concetti astratti del software: creare associazioni con la vita reale. Tendo ad associare informazioni a concetti trasversali o spesso all'apparenza completamente scollegati.

L'Observer Pattern o Pattern Lavatrice

L'Observer Pattern è un pattern comportamentale dove un oggetto (il Subject) notifica automaticamente una lista di oggetti dipendenti (gli Observer) quando cambia stato.

Spiegazione tecnica? Corretta ma astratta.

La mia lavatrice nuova fa esattamente questo.

Prima dovevo andare in bagno ogni 10 minuti per controllare se avesse finito. Polling. Spreco di risorse (le mie gambe). Latenza (poteva finire dopo 1 minuto ma io non lo sapevo).

La nuova lavatrice suona quando ha finito. È lei che notifica me. Io mi sono "iscritto" all'evento "lavaggio completato" e ricevo una callback (il suono) quando lo stato cambia.

Non devo più monitorare. Push invece di Pull.

// Polling (vecchia lavatrice)
while (!lavatrice.haFinito()) {
  cammina.versoIlBagno();
  controlla();
  aspetta(10.minuti);
}

// Observer (nuova lavatrice)
lavatrice.onFineLavaggio(() => {
  stendi.panni();
});
// Nel frattempo posso fare altro!

Il Proxy Pattern e la Lista della Spesa

Il Proxy Pattern è un pattern strutturale che fornisce un surrogato o placeholder per un altro oggetto, controllando l'accesso ad esso.

È la fidanzata che ti manda a fare la spesa con un post-it con l'elenco della spesa.

Il post-it è il proxy. Contiene le istruzioni (la lista dei prodotti) ma non è la moglie stessa. Tu, il client, interagisci col proxy. Esegui le istruzioni. Non devi metterci del tuo. Mi raccomando compra esattamente quello che c'è scritto, non interpretare, non decidere che "forse voleva dire...".

// Senza Proxy (vai tu a decidere)
marito.faiSpesa({
  prodotti: interpretaVagamente(intenzioniMoglie),
  // Risultato: torni con cose sbagliate
});

// Con Proxy (post-it)
const listaSpesa = new ProxyListaSpesa(intenzioniMoglie);
marito.faiSpesa({
  prodotti: listaSpesa.getProdotti(),
  // Nessuna interpretazione. Solo esecuzione.
  // "Latte scremato 1L" significa ESATTAMENTE quello.
});

Regola d'oro del Proxy: fedeltà all'originale, zero creatività, compra esattamente quello che era scritto.

Aristotele, Leibniz: Elementi, monadi e SRP

In un talk eccezionale, "Monads and Gonads" di Douglas Crockford (sì, quello del JSON), si parla di encapsulation e Single Responsibility Principle citando le Monadi.

Aristotele, nel IV secolo a.C., teorizzò gli elementi come unità indivisibili, atomi di esistenza, entità semplici e pure che non possono essere decomposte ulteriormente. Erano terra, aria, fuoco e acqua. Nella Monadologia di Leibniz, pubblicata nel 1720, le monadi sono assimilabili ad "atomi spirituali": eterni, indivisibili, individuali, che seguono le proprie leggi, senza interagire con le altre ("senza finestre"). Ogni monade percepisce sì l'intero universo, ma in modo confuso, mentre appercepisce (ovvero, è conscia di percepire) solo la parte dell'universo più vicina a sé.

Crockford traccia un parallelo illuminante:

  • Una funzione pura è una monade: un'unità indivisibile di comportamento, senza effetti collaterali, senza dipendenze esterne
  • Il Single Responsibility Principle è monadico: ogni classe dovrebbe avere una sola ragione per cambiare
  • L'encapsulation crea monadi software: unità autonome con confini chiari
  • L'appercezione del codice, è la comunicazione con gli altri oggetti, le altre classi, le funzioni di integrazione.

La filosofia ha insegnato al software come pensare in principi.

Fisica e Sistemi Distribuiti

Nulla trascende la fisica e le leggi del mondo e "I sistemi distribuiti obbediscono alla fisica, non alle nostre speranze."

  • Entropia: i sistemi tendono al disordine. Senza manutenzione attiva, il caos vince
  • Conservazione dell'energia: non puoi creare performance dal nulla. Se guadagni in velocità, paghi in memoria o in complessità
  • CAP Theorem: come il principio di indeterminazione di Heisenberg, non puoi avere tutto contemporaneamente

La fisica ha insegnato al software i suoi limiti.

Perché le Metafore Funzionano

Queste associazioni non sono solo esercizi mnemonici. Sono ponti cognitivi.

Il cervello umano non è progettato per pensare in astrazioni pure. È progettato per riconoscere pattern nel mondo fisico. Quando collego il Proxy Pattern aa andare a fare la spesa, sto usando circuiti neurali già allenati da anni di esperienza quotidiana.

Non devo costruire un nuovo modello mentale da zero. Innesto il nuovo sul vecchio.

E quando devo spiegare un concetto a qualcun altro, la metafora diventa un ponte cognitivo: entra facilmente perché è familiare, e porta con sé il concetto tecnico nascosto dentro.

Conclusione: Umiltà Intellettuale

"Se ho visto più lontano, è perché stavo sulle spalle di giganti", scrisse Bernardo di Chartres, lo disse Newton, lo ripetè Einstein.

Come esseri umani e a maggior ragione come sviluppatori software siamo sulle spalle di:

  • Architetti che hanno costruito cattedrali
  • Medici che hanno catalogato sintomi
  • Filosofi che hanno strutturato il pensiero
  • Artisti che hanno codificato la bellezza
  • Fisici che hanno scoperto i limiti della realtà

L'informatica è giovane. Ma non è sola.

E ogni volta che trovo un'analogia che funziona, che rende un concetto astratto improvvisamente chiaro, mi ricordo che la conoscenza umana è un continuum. Non ci sono discipline isolate. Ci sono solo prospettive diverse sulla stessa realtà.

Il codice migliore non viene da Stack Overflow o dall'IA.

Viene da tutto quello che impariamo guardando il mondo.

Serie "CodeIntel System: Dal Concetto al Codice"