Modernizzare senza riscrivere

"Modernizzare" è una parola che in molti reparti significa "rifare", e rifare un applicativo che funziona da vent'anni è la scelta con il rapporto peggiore fra rischio e beneficio che si possa fare.

Il punto di partenza onesto è un altro: il codice che gira da vent'anni ha già superato ogni collaudo possibile. Contiene decine di casi particolari che nessuno ricorda e che sono lì perché sono successi davvero. Riscriverlo significa perderli tutti e riscoprirli uno alla volta, in produzione.

Modernizzare, allora, vuol dire cambiare le parti che vale la pena cambiare, in un ordine che permetta di fermarsi in qualunque momento senza aver lasciato le cose a metà.

Che cosa conta davvero

Non tutte le cose che sembrano vecchie costano qualcosa. Le tre che costano davvero sono queste.

La logica duplicata. La stessa regola scritta in dodici programmi, che quando cambia va cambiata in dodici posti e in uno ci si dimentica. È il costo maggiore, e non ha niente a che vedere con l'età del codice.

L'impossibilità di parlare con l'esterno. Un applicativo che si usa solo dalle schermate verdi non può servire un sito, un'app, un fornitore. È il vincolo che blocca i progetti nuovi, e quasi sempre è la vera ragione per cui qualcuno propone di rifare tutto.

Il codice che nessuno sa più leggere. Non "vecchio": illeggibile. Un programma a colonne scritto bene si legge; un programma con quaranta indicatori e nomi di sei caratteri no, e il costo si paga a ogni modifica.

L'ordine che funziona

1. Estrarre la logica in procedure

È il primo passo perché non tocca niente e abilita tutto il resto. La regola duplicata si scrive una volta in una procedura dentro un service program, e i programmi cominciano a chiamarla — uno alla volta, quando capita di metterci mano.

dcl-proc calcolaImponibile export;
  dcl-pi *n packed(11:2);
    importo packed(11:2) const;
    aliquota packed(5:2) const;
  end-pi;

  return importo - (importo * aliquota / 100);
end-proc;

Da qui in avanti la stessa procedura è chiamabile da un programma RPG, da un servizio web, e — dichiarandola come funzione SQL — da una query. La stessa regola, un posto solo.

2. Renderla richiamabile in SQL

Una procedura o un programma esistente si può esporre al database:

CREATE PROCEDURE PRODLIB.CHIUDI_ORDINE (IN NUMERO DECIMAL(7,0))
  EXTERNAL NAME 'PRODLIB/CHIUDIORD'
  LANGUAGE RPGLE
  GENERAL;

Da quel momento chiunque sappia parlare SQL — un report, un altro sistema, un programma Java — può eseguire quella logica senza sapere che dietro c'è dell'RPG, e senza che nessuno gli dia accesso agli archivi.

Consiglio

è anche il modo più pulito per aprire un applicativo all'esterno tenendo chiusi i dati. Si concede l'esecuzione della procedura e non la lettura delle tabelle: chi sta fuori può fare quello che la procedura permette e nient'altro, e le regole restano dentro l'applicativo invece di essere riscritte da chi si collega.

3. Esporre i servizi

Tre strade, che rispondono a esigenze diverse:

Integrated Web Services — il sistema espone un programma o una procedura come servizio REST o SOAP, con la configurazione e senza scrivere codice di rete. È la strada più diretta quando serve far chiamare una funzione dall'esterno.
Le API SQL — chi si collega in JDBC o ODBC chiama le procedure di cui sopra. È la strada più semplice quando dall'altra parte c'è qualcuno che sa già usare un database.
XMLSERVICE — chiama programmi e comandi da PHP, Python, Node e altri linguaggi. È la strada usata dagli applicativi web scritti fuori dal sistema che devono riusare la logica che c'è dentro.

4. Sostituire le interfacce, non il motore

Le schermate 5250 si possono cambiare senza toccare i programmi che ci stanno sotto: sia con la modernizzazione automatica delle schermate, sia con Open Access, che permette a un programma RPG scritto per un file video di essere pilotato da un'altra interfaccia — un browser, un'app — senza modificarne la logica.

Avvertenza

rifare l'interfaccia lasciando invariato il resto dà un risultato visibile in fretta ed è la parte più facile da vendere, il che la rende anche la più sopravvalutata. Un applicativo con una faccia nuova e la logica ancora duplicata in dodici programmi costa da mantenere esattamente quanto prima. L'ordine dei passi in questo capitolo non è casuale.

Che cosa non fare

Non riscrivere in un altro linguaggio "perché l'RPG è morto". Non lo è, i compilatori ricevono funzionalità nuove a ogni rilascio, e il costo di una riscrittura completa si paga tutto in una volta contro un beneficio che si vedrà negli anni — ammesso che il progetto arrivi in fondo, e la maggior parte non ci arriva.

Non convertire in free-form come progetto a sé. Va fatto quando si mette mano a un programma per altri motivi. Da solo, produce un applicativo identico da riprovare da capo.

Non cominciare dalla parte più difficile. Il primo pezzo da modernizzare è quello che si tocca più spesso, non quello che fa più paura: serve un risultato che si veda entro poche settimane, altrimenti il progetto perde sostegno prima di produrre qualcosa.

Non farlo senza misurare. "Quante volte al mese si tocca questo programma", "quanto dura la chiusura", "quanti errori arrivano da questa area" sono numeri che si possono avere prima e dopo. Senza, la modernizzazione è un'opinione, e le opinioni non reggono a un taglio di budget.