Dijkstra e i 20 minuti che hanno cambiato il modo in cui troviamo la strada

Dalla domanda “qual è il percorso più breve?” a un algoritmo che oggi sostiene mappe, reti e sistemi complessi. Nel frontend siamo abituati a misurare tutto: tempi di caricamento, layout shift, dipendenze, percorsi utente. Eppure una delle idee più potenti dell’informatica nasce da una domanda molto più semplice e “umana”: qual è la strada più breve tra due posti? Quella domanda, formulata in modo generale e trasformata in un procedimento rigoroso, è diventata uno dei pilastri che fanno funzionare infrastrutture moderne come navigazione GPS, routing di rete, supply chain, robotica e persino la struttura di molte piattaforme social. Il nome che rimane attaccato a questa intuizione è quello di Edsger W. Dijkstra.

Il problema giusto: abbastanza concreto da capirlo, abbastanza generale da riutilizzarlo

Quando si vuole dimostrare la potenza di una macchina (oggi diremmo di una piattaforma, una libreria, un framework), la scelta del problema “demo” è fondamentale. Deve essere:

• Comprensibile anche a chi non vive di informatica.
• Non banale, altrimenti non mette in luce nulla.
• Generalizzabile, perché un caso particolare è solo un trucco; un metodo è una scoperta.

Il cammino minimo tra due luoghi è esattamente così: è intuitivo (“voglio arrivare nel minor tempo/costo”), ma si presta a formalizzazione. Basta un passaggio concettuale: rappresentare città e collegamenti come un grafo pesato.

• Nodi: città (o router, o pagine, o magazzini…)
• Archi: collegamenti possibili
• Pesi: costo (distanza, latenza, tempo, consumo energetico…)

Da qui, la domanda diventa: dato un grafo con pesi non negativi, qual è il percorso a costo minimo tra due nodi?

L’intuizione chiave: trasformare “una tratta” in “tutte le tratte”

C’è una differenza enorme tra risolvere un percorso specifico (es. da Rotterdam a Groningen) e progettare una procedura che funzioni per qualsiasi coppia di città. Questo salto di astrazione è ciò che rende un’idea “da giornata di lavoro” una soluzione destinata a vivere per decenni:

• non ottieni solo una risposta;
• ottieni un metodo ripetibile;
• e quel metodo diventa un componente riutilizzabile in sistemi molto diversi.

In altre parole: non stai più cercando la strada più breve una volta, stai definendo un modo per farlo sempre.

Perché l’algoritmo di Dijkstra è così centrale (anche fuori dalla teoria)

Quando parliamo di “cammino minimo” non stiamo parlando solo di mappe stradali. Stiamo parlando di un pattern che ricorre ovunque esista un costo e una rete di scelte. Alcuni esempi concreti:

• Navigazione: trovare il percorso più corto/rapido con vincoli variabili.
• Routing di rete: scegliere il cammino a minor costo (latenza, hop, congestione).
• Supply chain: ottimizzare tratte e trasferimenti tra hub.
• Robotica: pianificazione del percorso in ambienti con ostacoli e costi.
• Grafi sociali: analisi di distanze e connessioni tra entità.

Il punto interessante, per chi costruisce prodotti software, è che l’algoritmo non “appartiene” a un settore: appartiene alla struttura del problema. Se riesci a modellare la tua situazione come grafo, hai accesso a un intero arsenale di strumenti.

Un promemoria utile per chi fa software: scegliere bene l’astrazione

La lezione pratica non è romantica, è ingegneristica:

• Scegli un problema rappresentativo, non un caso isolato.
• Generalizza: chiediti se la soluzione vale per “questa schermata” o per “questa classe di schermate”.
• Modella: spesso il passo decisivo è trasformare la realtà in una struttura dati adatta (qui: un grafo pesato).
• Progetta un metodo, non solo un risultato.

Nel nostro lavoro quotidiano questa dinamica si ripete continuamente: routing client-side, dipendenze nel bundling, priorità di caricamento, grafi di stato, pipeline di CI. Cambiano i nomi, ma l’idea è la stessa: trovare un percorso ottimale in un sistema di possibilità.

Sintesi

L’algoritmo di Dijkstra è diventato un mattone fondamentale perché nasce da una domanda semplice, viene formalizzato in modo generale e si applica a un’enorme varietà di contesti reali. La sua forza non è nella “magia” del risultato, ma nell’astrazione: trasformare un problema quotidiano in una procedura universale. Quando un pezzo di software regge per generazioni, quasi sempre è perché qualcuno ha fatto proprio questo: ha scelto la forma giusta del problema prima ancora di scrivere la soluzione.

Articolo originale: https://frontendfacile.it/blog/dijkstra-e-i-20-minuti-che-hanno-cambiato-il-modo-in-cui-troviamo-la-strada