Quando ho iniziato a lavorare su sistemi bancari legacy, la mia reazione iniziale è stata: "Ma davvero si usano ancora queste tecnologie?". Servlet, JSP, WebSphere, CICS, mainframe z/OS... sembrava di tornare indietro di 20 anni.

Poi ho capito qualcosa di importante: questi sistemi funzionano. Da decenni. Senza interruzioni.

Il contesto: core banking

Lavoro su sistemi che gestiscono milioni di transazioni al giorno, dove un bug non si risolve semplicemente con "ricarica la pagina" o "spegni e riaccendi", dove un bug significa potenzialmente migliaia di euro persi o conti correnti sballati.

La stack è "antica":

Lezione 1: La semplicità scala

I framework moderni sono comodi, ma aggiungono layer su layer; una Servlet, invece, è brutalmente semplice:

public class TransactionServlet extends HttpServlet {
    
    @Override
    protected void doPost(HttpServletRequest req, 
                          HttpServletResponse resp) {
        String accountId = req.getParameter("accountId");
        BigDecimal amount = new BigDecimal(req.getParameter("amount"));
        
        // Logica di business diretta
        transactionService.transfer(accountId, amount);
        
        // Risposta
        resp.sendRedirect("/success.jsp");
    }
}

Niente dependency injection magica, niente annotation processing, niente proxy dinamici. Il codice fa esattamente quello che vedi.

Lezione 2: La backward compatibility è sacra

In un sistema bancario, non puoi "fare breaking changes", mai! I clienti usano ancora interfacce create nel 2005.

Questo mi ha insegnato a:

Lezione 3: Il mainframe non è morto

Il mainframe z/OS processa il 90% delle transazioni bancarie mondiali. Non è legacy, è battle-tested.

Caratteristiche che lo rendono imbattibile:

Certo, parliamo di strumenti datati, ma quando devi garantire che un bonifico da 10 milioni non fallisca a metà, vuoi un sistema provato.

Lezione 4: La documentazione è tutto

I sistemi legacy vivono o muoiono in base alla documentazione. Senza di essa, nessuno sa più perché certe scelte sono state fatte.

Ho trovato commenti del tipo:

// Non modificare questa logica - bug fix del 2003 
// per gestire il caso XYZ della banca ABC

Questi commenti sono oro. Spiegano il perché, non solo il cosa.

Da allora, documento sempre:

Lezione 5: Testing in produzione non è un'opzione

In ambiente enterprise, non puoi "deployare e vedere cosa succede". Il testing deve essere:

Ho visto ambienti di test con copie anonimizzate di dati reali, infrastrutture parallele, simulatori di mainframe. Il costo è enorme, ma l'alternativa (bug in produzione) costa di più.

Cosa porto nel mondo moderno

Queste lezioni le applico anche quando sviluppo in Spring Boot o Next.js:

Conclusione

Lavorare con legacy J2EE non è glamour, ma è educativo, ti insegna cosa significa software che deve funzionare, non software che "sembra figo".

La prossima volta che qualcuno parla di "codice legacy" con disprezzo, ricordagli che quel codice probabilmente gestisce i suoi risparmi.