Ecosistemi di sviluppo poliglotti: pro e contro

Con il diffondersi dei diversi linguaggi di programmazione molte compagnie sono diventate "poliglotte", ovvero gli sviluppatori software che lavorano per esse sono in grado di padroneggiare una vasto ventaglio di linguaggi di programmazione. Il mondo open source ha infatti aperto le porte ad un ecosistema di sviluppo software non vincolato ad una singola tipologia di linguaggio o stack tecnologico. Gli sviluppatori possono quindi svolgere la propria attività con il linguaggio e le tecnologiche che desiderano o che più si adattano al tipo di applicazione in sviluppo.

In genere nello sviluppo software un programmatore apprende un nuovo linguaggio per eseguire un task nel migliore dei modi, esistono infatti linguaggi progettati per determinati compiti e che offrono modi più rapidi per eseguirli rispetto ad altri. In buona sostanza il mondo dello sviluppo software è poliglotta per natura.

La creazione di un ambiente lavorativo poliglotta è spesso graduale e situazionale. Ad esempio, quando un'impresa acquisisce un'altra azienda, acquisisce anche altri stack tecnologici, inclusi i linguaggi di programmazione e gli sviluppatori. Oppure, quando la leadership aziendale cambia, è possibile che vengano introdotte nuove tecnologie. Anche le tecnologie possono passare di moda o tornare in auge, espandendo o diminuendo il numero di linguaggi di programmazione che un'organizzazione deve mantenere nel tempo.

Un ambiente poliglotta risulta però essere un'arma a doppio taglio per le imprese. Laddove esistono tecnologie diverse, linguaggi di programmazione, strumenti legacy e stack tecnologici emergenti, vi è complessità. I team di progettazione dedicheranno più tempo all'aggiornamento delle loro competenze sui nuovi linguaggi, oltre che sulla sicurezza e sulle dipendenze necessarie. Allo stesso tempo, la dirigenza può non riuscire a valutare un rischio in modo corretto se non ha a disposizione precedenti esperienze con le nuove tecnologie da utilizzare. Le imprese infatti hanno al loro interno vari gradi di qualità di codice sviluppato oltre ad un'alta variabilità nel supporto degli strumenti impiegati per lo sviluppo.

Risulta inoltre difficile diventare esperti in un determinato linguaggio quando ti viene richiesto di lavorare con una dozzina di linguaggi e stack software diversi. C'è una grande differenza nel livello di abilità tra una persona che parla correntemente Francese e Italiano e una persona che può unire insieme alcune frasi in otto lingue. Lo stesso vale per gli sviluppatori e i linguaggi di programmazione.

Tuttavia allargare il campo di competenze di uno sviluppatore o di un team renderà l'azienda più competitiva, dunque la risposta ad una scarsa specializzazione non è negare strumenti o l'uso di un linguaggio al programmatore. Nel dettaglio ci sono almeno tre elementi che le imprese dovrebbero tenere in considerazione quando lavorano con un ambiente di sviluppo software poliglotta:

• visibilità: al termine di un progetto un team può essere sciolto e sparpagliato in altri progetti, tuttavia può capire che le applicazioni rilasciate non ricevano più aggiornamenti e arriva sempre il momento in cui emerge un bug di sicurezza. Quando questo capita spesso l'azienda non ha la giusta visione d'insieme del suo ecosistema e non sa esattamente quanti e quali servizi o applicazioni possono contenere il codice difettoso. Per risolvere tali problematiche ci si affida a team dedicati all'esplorazione del codice dei vari progetti e questo, ovviamente, ha un costo per l'azienda che deve privare di risorse altri progetti.
• Aggiornamento o sviluppo: Alcune imprese centralizzano la funzione di aggiornamento e di fix in un singolo team. Altre invece richiedono che ogni team gestisca i propri strumenti di sviluppo e si occupi della loro manutenzione. In entrambi i casi, il team e il management pagano un prezzo ed in certi contesti capita che invece di sviluppare nuove funzionalità questi team aggiornino di continuo il proprio applicativo, senza mai aggiungere nuove funzionalità, perché si hanno poche risorse a disposizione.
• Reinventare la ruota: visto che le librerie utilizzate e le dipendenze richieste per un determinato software possono essere aggiornate costantemente, capita che un bug trovato in alcune versioni del proprio applicativo possano costringere il team di sviluppo a dover ricreare l'ambiente originale, perché non più disponibile sui server. Questo dover "reinventare la ruota" è un'enorme spreco di tempo e risorse, quindi è sempre bene programmare il ciclo di vita di un applicativo sin nei minimi dettagli.

Esistono quindi delle soluzioni pratiche per evitare queste problematiche:

• monitorare il codice in produzione e rispondere alle problematiche in base al rischio e al tipo di vulnerabilità.
• Aggiornare costantemente il codice in modo da tenerlo il più possibile bug-free.
• Sfruttare il supporto commerciale dei progetti open source per ricevere un aiuto diretto.
• Utilizzare build standard dei linguaggi in modo da sviluppare un ecosistema comune tra i vari team e minimizzare le dipendenze specifiche.
• Impostare degli avvisi sugli aggiornamenti.
• Scegliere o creare delle regole uniche per il package management.
• Distribuire build solo con i pacchetti realmente necessari al funzionamento.

Via Bart Copeland