Non esser troppo scrupoloso né saggio oltre misura. Dal Libro dell’Ecclesiaste       Gli sviluppatori moderni, pure quelli di casa nostra, parlano difficile. I loro discorsi sono pieni di inutili inglesismi, spesso cacofonici, quando non semplicemente inventati o malamente riadattati. Vi risparmio il triste campionario di esempi, che tanto conoscete ed usate quotidianamente quanto […]" />
Home » Programmer's Lifestyle » Cicli e ricicli delle eredità del software

Cicli e ricicli delle eredità del software

tron-legacy-d

Non esser troppo scrupoloso né saggio oltre misura.

Dal Libro dell’Ecclesiaste

 

 

 

Gli sviluppatori moderni, pure quelli di casa nostra, parlano difficile. I loro discorsi sono pieni di inutili inglesismi, spesso cacofonici, quando non semplicemente inventati o malamente riadattati. Vi risparmio il triste campionario di esempi, che tanto conoscete ed usate quotidianamente quanto me. Ma vorrei porre l’attenzione su uno in particolare: legacy. Compare in frasi quali sofware legacy, architetture legacy, sostituire il legacy del cliente e in innumerevoli altre; si è perso il significato letterale del termine, perché lo si usa alla strega di tanti altri termimi informatici, quasi come se fosse un neologismo. In realtà nella lingua inglese significa semplicemente eredità. E’ un termine bello e calzante perché rende perfettamente l’idea, cioè quella di qualcosa che appartiene o è appartenuta ad un cliente, in quanto utilizzatore, committente o licenziatorio; o a un tecnico, in quanto autore, sviluppatore o manutentore. E come tutte le eredità, non sparisce mai, ma condiziona sempre il presente e il futuro dei due attori in questione.

Mi rendo conto che che potrebbe sembra un discorso un po’ astratto, ma è importante considerare quanto il proprio passato e i progetti a cui si è partecipato, condizionino il proprio presente e quanto si resti radicati alle cose che si è fatto, facendo spesso resistenza emotiva ai cambiamenti, se questi mettono in discussione la proprità eredità, il proprio legacy.

Riporto un estratto dell’inizio di un articolo che scrissi per una rivista di programmazione, ormai quasi dieci anni fa. L’argomento è la tecnologia .NET Remotiong:

 

Lo scopo di questo e del prossimo articolo sarà offrire i rudimenti della tecnologia nativa di remotizzazione della piattaforma Microsoft .NET che, molto semplicemente, si chiama .NET Remoting, che è la soluzione .NET al problema delle invocazioni remote e cioè all’invocazione tra processi distinti. Infatti è sufficiente che un processo voglia invocare servizi di un altro processo in esecuzione sulla stessa macchina, perché questo richieda già i tipici servizi di un’architettura per le chiamate remote. Paradossalmente non vi è quasi nessuna differenza tra un processo che cerca di interagire con un altro che gira sulla stessa macchina, e quello che gira su una macchina nella stessa rete locale o, addirittura, su una macchina raggiungibile via internet e ubicata a decine di migliaia di chilometri di distanza.
Allo scopo di semplificare questo tipo di gestione remotizzata, .NET introduce il concetto di Application Domain: tipicamente un ambiente nativo tradizionale prevede il concetto di applicazione e di processo; quest’ultimo altro non è che una zona isolata nella memoria del sistema in cui viene caricata l’applicazione e in cui viene riservata un’area di memoria per il corretto funzionamento dell’applicazione stessa. I processi sono tipicamente fortemente isolati: non possono direttamente accedere alle risorse di un altro processo e sono protetti dai tentativi di accesso più o meno coscienti degli altri processi. D’altro canto si rende talvolta necessaria la comunicazione tra due processi e così il sistema operativo prevede i cosiddetti meccanismi di RPC (Remote Procedure Call).

[…]

Quando si prova ad invocare un oggetto presente nell’Application Domain (appdomain, per brevità) corrente, è sufficiente una tradizionale chiamata locale. Se invece l’oggetto è presente in un diverso appdomain si rende necessaria una chiamata remota. In tal caso sul client verrà creato un proxy, cioè un’istanza della classe TransparentProxy, mentre sul server viene creato uno stub. La potenza e la caratteristica innovativa di .NET Remoting, rispetto ad altre archietture di remotizzazione concorrenti, è che tale processo è completamente automatico e non è quindi richiesto allo sviluppatore l’onere di codificare tali strati proxy/stub. Al punto che, in certi casi, si potrebbe essere persino completamente all’oscuro della natura locale o remota di una chiamata.

 

Ero veramente entusiasta di questa tecnologia, tant’è che l’ho usata per anni, basandovi le architetture applicative che di volta in volta ho realizzato per i progetti a cui ho partecipato. Ricordo con quale ottusa convinzione mi ritrovavo a negare l’evidenza e a difendere quella scelta tecnica ad oltranza, nonostante l’affacciarsi di tecnologie e di protocolli più moderni, standard e scalabili come SOAP, WCF e gli RPC basati sul Web. Per mia fortuna, infine, qualcuno mi ha costretto al trapasso, semplicemente perché aveva l’autorità per deciderlo in quello specifico progetto, anche col suffragio di esperti consulenti. La mia resistenza è stata davvero forte contro il superamento del modello .NET Remoting, Windows Service e chatty interface, ma alla fine ho ceduto e di questo non sarà mai abbastanza grato per la costrizione subita.

Per contrappasso, adesso sono coinvolto in un progetto con l’iniziale scopo di traghettare la precedente tecnologia RPC basata su .NET Remoting ad un approccio più SOA basato su WCF, SOAP ed IIS. I dubbi e le resistenze iniziali che ho incontrato sono malinconicamente le stesse: si tratta del solito lirico romanticismo del legacy. E meno male che sopravvive ancora, perché è tra le poche cose che fa ancora vivere questo non come un lavoro normale, ma come una passione.

 

Condividi in rete

  • Facebook
  • Twitter
  • Google Plus
  • RSS
Cicli e ricicli delle eredità del software Reviewed by on . Non esser troppo scrupoloso né saggio oltre misura. Dal Libro dell’Ecclesiaste       Gli sviluppatori moderni, pure quelli di casa nostra, Non esser troppo scrupoloso né saggio oltre misura. Dal Libro dell’Ecclesiaste       Gli sviluppatori moderni, pure quelli di casa nostra, Rating:
scroll to top