Sviluppare low-code e no-code: pro e contro di un metodo che rappresenta un aiuto, ma non un’alternativa, alla scrittura di codice

Quando si parla di sviluppo low-code si intende quella tecnica di “scrittura” software che, tramite un’apposita piattaforma, consente di prendere pezzi di codice già scritto come punto di partenza, sul quale andare poi a implementare nuove parti di codice scritte ad hoc. La creazione del software avviene quindi tramite una componente minima di scrittura di codice.
Lo sviluppo no-code rappresenta l’estremizzazione del low-code: in questo caso, infatti, ci si basa solamente su quanto messo a disposizione dalla piattaforma di sviluppo, senza implementare nessuna nuova riga di codice.
Queste tecniche di sviluppo sono note già dai primi anni 2000 e hanno avuto un vero e proprio boom negli anni ’10: oggi queste tecnologie sono in forte espansione e il tema assume sempre maggiore rilevanza. È quindi importante conoscere pro e contro di sviluppare low-code e no-code, per comprendere meglio quale può essere il reale utilizzo di queste tecniche.

In Idem-tech ci occupiamo di sviluppo di sistemi embedded e della scrittura di codice ma, in seguito alla sempre maggiore rilevanza e diffusione delle tecniche low-code e no-code, abbiamo voluto analizzarle meglio, per comprenderle a fondo e poterne identificare pro e contro.
Una piattaforma di sviluppo low-code, ad esempio, fornisce un ambiente per creare un software applicativo, generalmente attraverso un’interfaccia grafica. Le piattaforme no-code, invece, sono esclusivamente correlate ai linguaggi di programmazione visuale. Il mondo no-code si basa quindi interamente sulla GUI (Graphical User Interface) e sul drag and drop degli elementi, mentre il low-code permette di integrare anche snippet di codice personalizzati.

Il termine no-code può trarre in inganno. In questo caso, infatti, il codice non è assente, ma nascosto e inaccessibile all’utente. Molto spesso un’app sviluppata tramite no-code ha più codice al suo interno di una sviluppata con una piattaforma classica. Semplicemente, quel codice non è stato scritto dal programmatore che ha lavorato all’app in questione, bensì da chi lo ha implementato in precedenza sulla piattaforma di programmazione utilizzata. La programmazione no-code, infatti, si fa attraverso delle piattaforme, dei framework di sviluppo, che permettono di fare il drag and drop di componenti scritti in precedenza. Se da un lato questo semplifica notevolmente l’attività di programmazione, dall’altro fa sì che chi sviluppa no-code possa avere un controllo a monte e a valle del processo, quindi su quali componenti utilizzare e sul risultato finale, ma non su quanto sta nel mezzo. Questo, a sua volta, complica (o addirittura rende impossibili) diverse attività, dalla manutenzione alla personalizzazione dell’applicativo.
Ricapitolando, con il no-code è possibile creare delle applicazioni da zero sfruttando dei blocchi che hanno un codice sottostante. Da questi blocchi di partenza si può costruire l’applicativo, dopodiché sarà la macchina a generare il codice binario e l’applicazione funzionerà di conseguenza. A chi sviluppa tramite no-code occorrono quindi dei framework, cioè dei programmi che consentano di procedere in questo modo.

WordPress consente infatti di sviluppare pagine tramite dei plugin, cioè dei blocchi logici che, una volta inseriti, creano una parte della pagina web senza che occorra scrivere del codice. WordPress funziona infatti attraverso blocchi Gutenberg e fornisce anche un editor di codice per personalizzare le pagine web.
Per fare un altro esempio, sviluppare in no-code è come lavorare in Microsoft Excel, programma che già nel lontano 1985 arriva sulle scrivanie degli uffici: senza scrivere codice, infatti, tramite Excel l’utente può creare rappresentazioni visive di dati e automazioni più o meno complesse, nonché connettere sorgenti dati diverse, automatizzare task a orari pianificati e gestire accessi e funzionalità in base a diverse utenze.
Rimanendo nel campo della suite Microsoft che tutti ben conosciamo, anche Word funziona in modo simile a Excel. In Word, tutte le funzioni di impaginazione sono fatte in logica no-code: all’utente non serve scrivere dei comandi, ma gli basta interagire con menù e pulsanti. Al contrario, con programmi come LaTeX è possibile scrivere e impaginare usando un linguaggio di markup da cui si genera poi un testo. In Word quello che l’utente ottiene come risultato finale corrisponde a quanto vede sullo schermo. In LaTeX, invece, l’utente imposta delle regole di base e si occupa poi esclusivamente della scrittura del contenuto: sarà il programma a gestire formattazione e impaginazione tramite le regole stabilite a monte. Da questo esempio è evidente come non esista una soluzione più efficiente o migliore di un’altra: a seconda delle capacità di programmazione di ciascun utente e delle sue necessità, la risposta cambia.

I pro di sviluppare low-code e no-code sono diversi: questo tipo di sviluppo è molto più semplice, richiede conoscenze tecniche minori e un tempo di lavoro ridotto. Per tutte queste ragioni, sviluppare low-code e no-code ha anche un costo più contenuto rispetto a sviluppare scrivendo del codice da zero. Il low-code è ad esempio molto utilizzato dai cosiddetti Citizen Developer, cioè sviluppatori non propriamente detti, formatesi solitamente in ambito amatoriale e che spesso non sono in grado di scrivere in modo massiccio del codice.
Sviluppando in low-code e no-code si riducono anche i rischi di bug rispetto a quando un codice viene invece scritto da zero.

Nonostante i pro prima evidenziati, programmare low-code e no-code non può essere sempre la soluzione.
Nella maggior parte dei casi, ad esempio, sussistono dei problemi di proprietà legati all’utilizzo di queste tecniche. Le parti di codice già scritto, integrate nella propria applicazione quando si programma low-code, sono infatti solitamente dei software proprietari. Di conseguenza, quanto sviluppato non è poi – almeno non del tutto – proprietà dello sviluppatore finale. Questo complica inoltre la manutenzione dell’applicazione, anche perché non si ha il controllo del processo di svolgimento dei compiti assegnati, ma si conosce solo il risultato finale: per questo in ambito aziendale è molto più semplice e sicuro manutenere un applicativo sviluppato interamente all’interno del reparto IT, di cui si è completamente proprietari e su cui è possibile intervenire sotto ogni aspetto.
Il low-code, e ancor più il no-code, hanno poi dei vincoli tecnici. Le applicazione sviluppate con questa logica non sono scritte da zero e non possono quindi essere interamente personalizzate, nemmeno in termini di compiti da eseguire.
La personalizzazione possibile è molto più elevata quando un applicativo è sviluppato in ottica embedded. Ad esempio, aggiungere o togliere una periferica da un sistema fatto su misura è molto più semplice, mentre può non essere possibile se a monte si è lavorato in logica low-code o no-code.
Un tema importante rimane poi quello di coniugare sicurezza informatica e performance: se si ha bisogno che il programma faccia determinati compiti in determinati tempi, anche stringenti, è preferibile scrivere il codice da zero. In questo modo è possibile stabilire a monte e far rispettare dei tempi di esecuzione dei task. Ma se invece, come nel caso dello sviluppo low-code e no-code, non si conosce il codice sottostante, è difficile sia far rispettare dei tempi di esecuzione, sia garantire alti livelli di sicurezza. Ad esempio, nel caso di app che raccolgono e utilizzano i dati dei consumatori, possono emergere delle criticità lavorando in low-code e no-code, nonostante questi sistemi siano in continuo aggiornamento per aumentare i livelli di sicurezza.
Va considerato infine che la programmazione low-code e no-code non supporta il Machine Learning, l’analisi dei Big Data e l’IoT. Forse un giorno le piattaforme low-code e no-code arriveranno anche a questo, ma ad oggi questi limiti vanno tenuti in considerazione.
I limiti legati a sviluppare low-code e no-code sono quindi numerosi, ma è vero che oggi questo mercato è in espansione e spesso tende ad affiancarsi a quello dello sviluppo professionale e dello sviluppo embedded.

Sempre seguendo la logica di questa metafora, lo sviluppo low-code e no-code rappresenta un attrezzo amatoriale, come quelli che tutti noi utilizziamo per i piccoli lavori di casa. Proprio come nel fai da te non possiamo però utilizzare martello e cacciavite per costruire una casa, così la programmazione low-code e no-code non è la risposta adeguata a compiti complessi.
Sviluppare low-code e no-code ha indubbiamente dei pro, perché non è necessario occuparsi di scrivere il codice: rappresenta ad esempio una buona soluzione per sviluppare app mobili che si limitano a compiti semplici, per creare sistemi di CRM, per prototipare software in maniera rapida o per creare applicazioni che raccolgono e analizzano dati su scala limitata.

A nostro avviso, la risposta è certa: no. Lo sviluppo di software che richiedendo un alto livello di competenze rimarrà appannaggio di sviluppatori professionisti, ma allo stesso tempo il low-code e il no-code consentiranno a sempre più persone di realizzare piccoli progetti con scarsa o nulla conoscenza di codice.