Di Tony Graham
La peculiarità principale dello sviluppo low-code è il fatto che permette di sviluppare applicazioni business-critical anche a persone con poca esperienza di programmazione. In effetti, negli ultimi due anni, il confine tra low-code e no-code è diventato sempre più sfumato. Le piattaforme low-code hanno incorporato funzionalità no-code sempre più utili per aumentare ulteriormente l'efficienza dello sviluppatore. Alcune di queste piattaforme sono diventate così intuitive da usare,che l'idea che chiunque possa creare un'app si è evoluta nell'idea degli citizen developer. Ma il low-code è davvero l'essenziale quando si tratta di sviluppo di app? Sembra che la risposta sia: "Dipende".
È diventato evidente che esclusivamente piattaforme no-code non possono creare applicazioni complesse. Ma poi di nuovo, queste piattaforme non sono mai state progettate con quel tipo di funzionalità in mente. L'assenza di codice può essere uno strumento di prototipazione rapida di grande valore, nonché uno strumento decente per app molto piccole e molto specifiche. Queste app sarebbero più adatte per l'uso intradipartimentale o per estendere la funzionalità di strumenti SaaS molto specifici. L'assenza di codice non alimenterà le tue applicazioni business-critical e uno sviluppatore non proprio non alleggerirà il tuo carico IT.
Ma per quanto riguarda il low-code? Il low-code può essere il ponte tra citizen developer e l'elenco in continua crescita di app backlog? Può essere. L'utilizzo di citizen developer comporta un mucchio di problemi che devono essere affrontati. Sebbene questo argomento possa essere oggetto di un intero blog a sé stante, posso evidenziare rapidamente le principali questioni da considerare. Quanto tempo uno citizen developer dovrebbe essere dedicato allo sviluppo di app? L'utilizzo di citizen developers creerà problemi di arretrato nei loro dipartimenti primari? Chi formerà e supporterà gli citizen developer? In che modo l'IT garantisce che le app create dagli citizen developer siano sicure, scalabili ed estendibili? Per quanto grandi possano sembrare i citizen developer, non sono ancora una soluzione definitiva.
Una realizzazione è nata nel settore low-code. Il low-code non può fare tutto, ma può essere un utile strumento di sviluppo per accelerare lo sviluppo delle applicazioni. Tuttavia, la maggior parte delle piattaforme low-code si trova nella propria fase di sviluppo, separati da altri strumenti di sviluppo con i propri IDE. Invece, un'idea è creare un'interfaccia utente rapida e facile da usare, trascinare e rilasciare alcune funzionalità dell'app e quindi completare le app complesse in un linguaggio con cui la piattaforma low-code possa integrarsi, come Java o tramite un Visual Plug-in di Studio. Persino i più grandi e migliori fornitori di low-code ammettono che il semplice utilizzo di codice ridotto è auto-sufficiente.
Il low-code non può essere tutto, ma può essere una parte importante di tutto. Deve solo apparire diverso da come sono progettate la maggior parte delle piattaforme low-code. L'utilizzo di un approccio ibrido low-code consentirà alle organizzazioni di utilizzare veramente low-code dall'inizio alla fine nel processo di sviluppo dell'app. Piuttosto che considerare il low-code come uno strumento separato nel processo di sviluppo, un approccio ibrido low-code porta il low-code all'interno di un IDE in cui vengono ancora utilizzati i metodi di codifica tradizionali.
Il low-code ibrido è il futuro dello sviluppo di app? Direi che il low-code ibrido è un passo successivo nell'evoluzione dello sviluppo di app. Gli strumenti di sviluppo low-code non dovrebbero essere isolati nei propri IDE. Può essere frustrante lasciare un IDE low-code per completare l'app in un altro IDE e quindi collegare i diversi elementi in un'unica app coerente. Come puoi vedere, l'efficienza si riduce ogni volta che uno sviluppatore lascia un IDE per un altro. Il low-code ibrido vede il low-code come uno strumento all'interno di un toolbox di sviluppo più grande. È disponibile quando è conveniente, ma uno sviluppatore non è obbligato a utilizzare solo low-code. Possono importare risorse già create da altre lingue, codificare manualmente soluzioni complesse, trascinare e rilasciare quando ha senso e creare tutti i componenti necessari di un'app Web progressiva con un clic di un pulsante.
Mentre potrebbe esserci una profonda consapevolezza che il low-code "tradizionale" non può fare tutto ciò che originariamente promette, il low-code ibrido potrebbe, invece, mantenere quella promessa.