Come gestire il codice legacy, i consigli di Codemotion

Il codice legacy obsoleto affligge aziende e coinvolge molti progetti software. La rapida evoluzione delle tecnologie rende il codice scritto in passato difficile da mantenere, modificare o integrare con nuove funzionalità. Il codice legacy obsoleto può, inoltre, causare problemi di sicurezza, prestazioni, compatibilità e qualità del software. Abbiamo quindi chiesto ad Andrea Ferlito, CTO di Codemotion, di spiegarci nel dettaglio le difficoltà del codice legacy e quali sono le soluzioni migliori per gestirlo.

Codice legacy, Codemotion ci aiuta a capire come gestirlo

Tutte le aziende hanno bisogno di innovare. I macchinari migliorano, le risorse cambiano, persino le skill dei dipendenti hanno bisogno di tenere il ritmo dei tempi. Ma questo vale particolarmente per il mondo software, che specialmente negli ultimi anni ha visto rivoluzioni continue.

Quella del codice legacy è una realtà che Andrea Ferlito, che è il CTO di Codemotion da circa 10 anni, conosce bene. Ingegnere informatico con un’ esperienza trentennale, oggi gestisce “il team di software engineering che si occupa dello sviluppo della piattaforma di Codemotion, attraverso la quale gli sviluppatori della nostra community, la più grande in Europa con oltre 250mila professionisti esperti di oltre 100 tecnologie, possono accedere a contenuti digitali per aggiornarsi sulle novità e i trend tecnologici del momento e partecipare ad una serie di conferenze ed eventi live settimanali per fare networking”.

Il problema del codice legacy e come affrontarlo

L’azienda, che da un anno ha lanciato anche la piattaforma Codemotion Talent, per far incontrare le esigenze delle aziende con le skill degli sviluppatori, conosce bene il mondo di chi scrive codice. E quali problemi deve affrontare ogni giorno.

Proteggi i dati del tuo PC con Bitdefender, Leader in Cybersecurity

Abbiamo quindi discusso con Ferlito di quali sono le difficoltà principali nel gestire e manutenere il codice legacy.

TB: Quali sono le difficoltà di manutenere del codice legacy molto vecchio in ambienti di produzione?

AF: “Non sempre scegliere di manutenere applicazioni scritte con codice legacy è un problema. In un’autofficina di Gdansk, in Polonia, c’e’ un Commodore 64, da 25 anni regolarmente usato per gestire alcune misurazioni sulle vetture. In questo caso, abbiamo un sistema (hardware e sistema operativo) che non ha mai bisogno di aggiornamenti e il software è stato scritto per fare quel mestiere in eterno, per lo meno finché non cambierà qualcosa di importante sulle auto.

“Per capire quando diventa realmente complicato gestire la manutenzione, bisogna considerare principalmente questi elementi: l’ambiente, nel senso più ampio del termine, in cui il software vive; i linguaggi di programmazione che diventano obsoleti; la volontà di aggiungere feature a un prodotto software che ormai non è più manutenibile.

L’ambiente

“Partendo dall’ambiente: come noto, le nostre applicazioni software girano all’interno di altre applicazioni software (sistema operativo e framework) e utilizzano dell’altro software (librerie). Ai tempi del Commodore 64 l’ambiente non diventava praticamente mai obsoleto, mentre negli ultimi anni lo diventa sempre piu’ rapidamente. Bug, buchi di sicurezza, nuove versioni possono rendere incompatibile l’ambiente col nostro software anche se, paradossalmente, “potrebbe”continuare a funzionare.

“Alla base di questo fenomeno ci sono trend di mercato, tech vendor che spingono sulle loro nuove tecnologie da fruire con nuovi linguaggi e anche poca attenzione, rispetto ad un tempo, nella scrittura del codice, perché, anche se i software sono molto piu’ complicati di prima, oggi c’è anche la tranquillità di poter rilasciare patch a nastro”.

I linguaggi

“I linguaggi, invece, diventano obsoleti per motivi legati a prestazioni, espressivita’ sintattica, accesso a nuove tecnologie e per la spinta da parte della community e del mercato verso la “moda” del momento, che a volte può portare a eccessi come nel caso dell’attuale ecosistema javascript.

“La durata di un’applicazione dipende dall’ambiente in cui gira e da quanto va evoluta come prodotto. Ci sono casi in cui ha molto senso attrezzarsi per riscriverla con una tecnologia più moderna piuttosto che fare manutenzione, ma ovviamente occorre prepararsi per tempo”.

TB: Che tipo di approccio ha la vostra organizzazione riguardo questi problemi?

AF: “Il software core nella nostra organizzazione e’ stato progettato pochi anni fa (2019) utilizzando le piu’ recenti tecnologie: l’infrastruttura è in cloud, l’architettura del software è a microservizi, l’ambiente di deploy è Kubernetes, ma nonostante questo gia’ soffriamo di alcuni problemi di obsolescenza. Per fare qualche esempio: il cloud vendor aggiorna i suoi servizi managed per lo meno una volta l’anno, la versione di kubernetes va aggiornata almeno 2 volte l’anno per essere up to date e compliant con le policy del vendor, introducendo a volte delle breaking changes. Ogni volta dobbiamo verificare che tutti i servizi non vengano impattati.

“Per contro abbiamo del codice legacy che ha circa 10 anni che continua a funzionare nel suo ambiente specifico. Nel frattempo abbiamo tutto il tempo per decidere quali parti ha senso migrare nella nuova infrastruttura.

“Con questo non voglio assolutamente dire che ‘si stava meglio quando si stava peggio’, ma l’esperienza di questi ultimi anni mi porta a dire che la scelta che abbiamo fatto ci ‘costringe’ ad anticipare di moltissimo il problema della manutenzione del codice, e quindi alla fine il codice non sarà mai piu’ vecchio di uno o due anni.

“Di contro, questo approccio è assolutamente più costoso del precedente poiché è necessario fare update continui, da cui se, ad esempio, una certa applicazione non è così core per il business, e quindi non ha bisogno di costante aggiunta di nuove feature, ma per qualche motivo è necessario che resti in esercizio, va comunque inserita nel ciclo di update costante. Una situazione ottimale per il cloud vendor, un po’ meno per gli utenti che devono gestire il budget per l’infrastruttura, per lo meno in certe situazioni”.

Esistono, attualmente, delle soluzioni sul mercato?

“Sinceramente non saprei se esistono dei tool specifici che gestiscono la manutenzione del codice legacy, non ho mai approfondito la cosa. Ritengo che ogni caso abbia le sue peculiarità e quindi, a parte la oculata scelta dell’ambiente di produzione e l’utilizzo di best practices, sicuramente non è semplice trovare una soluzione sul mercato che possa adattarsi a tutte le casistiche“.

Una delle soluzioni che si stanno provando oggi è quella di tradurre librerie legacy in linguaggi moderni facendo uso di AI tipo ChatGPT e Bard. Ci sono secondo lei delle controindicazioni? Il risultato è manutenibile da un essere umano, o siamo punto a capo?

“I limiti attuali di questa tecnologia fanno sì che il codice risultante possa non essere funzionante, in più la struttura che una AI darebbe al codice potrebbe essere poco leggibile, la AI non può conoscere in modo puntuale il contesto e il dominio applicativo e potrebbe non capire le scelte fatte nel codice legacy. Quindi in sintesi si può sicuramente usare come base, come alleato, ma serve sempre l’occhio del programmatore umano, tra l’altro esperto del dominio.

“Ribadisco che personalmente sarei per la riscrittura dell’applicazione, se necessario, e non tanto per la traduzione del codice in un linguaggio piu’ moderno”.

Guardando invece al futuro; quali sono secondo lei le best practice che dovremmo adottare oggi nel produrre software per evitare di trovarci nella stessa situazione tra 20 anni?

“Come dicevo prima, i moderni ambienti e lo sviluppo agile ti portano a cicli di aggiornamento delle applicazioni e dei sistemi molto stretti e devono essere messi in conto, come dire a budget, da subito. Tutto ciò aumenta i costi di sviluppo e di manutenzione ordinaria. Lo scenario è stato scritto a mio avviso dai tech vendor che sono oggi orientati alla vendita di servizi. Sinceramente non saprei dire quanta percentuale di bene o di male ci sia in questo, al momento siamo costretti ad adeguarci.

“Cosa succederà tra 20 anni? Spero ci sia ancora un Commodore 64 funzionante, e sono più che sicuro che sara’ cosi’. Forse proprio nell’autofficina di Gdansk.

“Resta invece una cosa importantissima come best practice che vale sempre, in ogni caso: la documentazione.

“Riprendendo la provocazione iniziale, non ritengo che il codice legacy sia necessariamente un male. Se l’applicazione funziona, il lavoro per cui è stata creata è ancora utile, si trova in un ambiente ‘protetto’ ed è ben documentata, per quanto mi riguarda può continuare ad esistere. Anzi, il developer che si specializza in linguaggi legacy potrebbe essere una risorsa interessante e ben remunerata”.

Il codice legacy, quindi, può diventare una risorsa extra per gli sviluppatori piuttosto che un limite. Quando qualcosa funziona, non c’è bisogno di cambiarla: solo di farla fruttare al massimo.