Sono finiti i tempi in cui tutte le aziende di uno stesso settore facevano più o meno la stessa cosa. Al giorno d'oggi il successo di un business è strettamente legato alla sua unicità e all'unicità dei suoi flussi di lavoro.
Come risultato le aziende innovative sono sempre più spesso alla ricerca di soluzioni software su misura che seguano i loro processi di lavoro e che possano essere modificate nel tempo per adattarsi ai cambiamenti dell'azienda.
Noi come altre software house riceviamo sempre più spesso delle richieste di sviluppo di soluzioni personalizzate. Il tempo e il costo di sviluppo sono i fattori chiave. Il cliente si aspetta che dalla sua richiesta a quando viene consegnato il software passino pochi mesi e il costo sia il più contenuto possibile.
Nasce quindi l'esigenza di seguire degli approcci rapidi allo sviluppo che permettano di ridurre il time to market e i costi.
Inoltre, nel tempo l'asticella dei requisiti si è alzata. Se fino a qualche anno fa "software gestionale" era sinonimo di applicazione desktop e nel migliore dei casi client server, al giorno d'oggi "software gestionale" è sinonimo di web application utilizzabile ovunque e possibilmente anche con dispositivi smartphone e tablet.
Anche per questo motivo gli strumenti RAD (Visual Basic, Delphi, ecc.) che tanto hanno avuto successo negli anni 90 oramai sono obsoleti.
Ma allora quali alternative ha oggi uno sviluppatore chiamato a realizzare software gestionale in tempi brevi?
Vediamo le principali.
Approccio Naif#
La prima possibilità seguita un po' da tutti all'inizio è quella di partire da zero e sviluppare ciascuna schermata e qualsiasi funzionalità una riga di codice alla volta. Se il programmatore è abile porterà a termine il progetto con una soluzione funzionante. Ma statisticamente, per progetti un minimo complessi, questa è l'eccezione.
Le tempistiche del cliente e/o il budget a disposizione portano il programmatore a trascurare una o più tra le seguenti caratteristiche: usabilità del software, manutenibilità, stabilità della soluzione, scalabilità, correttezza e completezza della soluzione.
Il risultato sono soluzioni costose, poco usabili, con bug e difficili da modificare.
Come mai ciò accade?
Il motivo è che nell'approccio Naif il programmatore deve occuparsi allo stesso tempo di un sacco di problemi riguardanti aspetti diversi che consumano le sue risorse mentali:
- deve preoccuparsi dei dettagli del salvataggio e reperimento dei dati dal DB;
- deve preoccuparsi degli aspetti della sicurezza del software;
- deve preoccuparsi delle logiche del software;
- deve preoccuparsi dell'usabilità;
- deve tenere presente gli aspetti ad alto livello del dominio applicativo del cliente;
- deve scrivere codice ben organizzato che sia facile da manutenere;
- deve possedere il dono dell'astrazione per poter avere una visione d'insieme e allo stesso tempo di dettaglio;
- deve compiere delle scelte di progettazione che siano scalabili;
Per dominare la complessità negli ultimi anni sono nate molte metodologie di programmazione che hanno lo scopo di migliorare la qualità del software prodotto, ma hanno il difetto di essere poco incisive nella riduzione di tempi e costi.
Approccio Framework#
Con il tempo i programmatori hanno capito che poteva aver senso raccogliere la soluzione a problemi ricorrenti prima in librerie e poi in framework.
Lo sviluppatore che ha provato l'approccio Naif solitamente come seconda scelta decide che è giunto il momento di affidarsi a un framework "collaudato" in modo da demandare a lui l'organizzazione del codice e la soluzione a problemi noti.
Ben presto però il programmatore si accorge che il tempo che prima spendeva nel risolvere i problemi da solo, adesso lo passa a leggere documentazione, cercare soluzioni su internet per aggirare i limiti del framework e capire dove inserirsi nella logica del framework per fare quello che vuole.
Per qualche strano motivo i framework di successo sono stati quelli ad oggetti basati sul modello MVC. Il flusso logico non è più in sequenza, ma è sparpagliato tra una serie di file e nascosto dall'ereditarietà tra classi. Capire dove inserirsi con la propria modifica può richiedere più tempo della modifica stessa.
Ma perché i framework generici hanno fallito nell'obiettivo di velocizzare i tempi di sviluppo?
Il difetto dei web framework è che sono troppo generici. Vogliono consentire lo sviluppo di qualsiasi applicazione web, ma così facendo aggiungono uno strato di complessità fornendo in cambio funzionalità per lo più generiche. Non solo, imbrigliano il programmatore nelle loro logiche senza però risolvere completamente i problemi al posto suo.
Concetti di alto livello come griglie paginate, form di manutenzione dati, stampe, lavori batch sono tutti concetti non gestiti dai framework general purpose perché troppo specifici. Di conseguenza il programmatore dovrà occuparsene ancora in prima persona con l'aggravante di doversi inserire nelle logiche pensate da qualcun altro.
Adminer#
Adminer non è propriamente un metodo di sviluppo, ma ho scelto di inserirlo in questa carrellata perché permette di intravedere una modalità di sviluppo nuova nella realizzazione di software gestionali in tempi rapidi.
In realtà nasce come una interfaccia web per amministrare un database, ma di fatto, grazie ai suoi plugin e alle sue funzionalità può essere utilizzato come web application grezza per l'inserimento e la modifica di dati.
I tempi di sviluppo sono rapidissimi perché coincidono con la creazione della struttura del DB.
I difetti per un uso reale di questo strumento sono:
- l'interfaccia creata da adminer attorno al database è limitata dalle informazioni che possono essere dedotte dalla struttura delle tabelle. Ad esempio non è possibile variare la visibilità di un campo in base all'utente connesso, non è possibile modellare il fatto che il valore di un campo dipende dal valore di un altro campo (es. categoria e sottocategoria), non è possibile specificare che i dati di un campo trascinano i valori di altri campi, ecc.
- non sono previste logiche. Ovvero non c'è un modo facile di creare delle logiche come ad esempio l'invio di una mail quando viene inserito un record, la possibilità o meno di modificare un certo record in base al valore di alcuni campi, la validazione dell'input, la comunicazione con API esterne, ecc.
- non è possibile stabilire come sono disposti i campi nelle maschere di inserimento dati.
- non copre tutte le funzionalità tipiche dei gestionali come le stampe, i lavori batch, il controllo fine di ruoli, utenti e permessi.
A parte le ovvie limitazioni, comunque, se uno pensa al tempo per realizzare le stesse funzionalità con un framework o un metodo naif si accorge subito della potenzialità che potrebbe essere sprigionata da uno strumento più evoluto di Adminer.
Linguaggi visuali#
I linguaggi visuali stanno tornando in voga anche nel settore delle web application. Purtroppo però non è il fatto di essere visuale o meno la soluzione al problema dello sviluppo rapido di software.
Per come sono concepiti i linguaggi visuali sono solo un modo diverso di presentare gli stessi concetti dei linguaggi di programmazione testuali.
Inscatolare le istruzioni in rettangoli colorati e disegnare frecce che rappresentano il flusso dell'esecuzione non aumenta la produttività rispetto a scrivere le stesse istruzioni in un editor di testo, anzi.
Inoltre rendere visuale il flusso logico non mette al riparo dalla gestione della complessità. Ad esempio il codice spaghetti non è dovuto all'utilizzo di un linguaggio testuale rispetto a uno visuale, ma più che altro alla confusione mentale che c'è nel programmatore che lo scrive o lo disegna.
Chiunque abbia usato un linguaggio visuale si rende conto ben presto che per una qualsiasi applicazione pratica, ovvero un minimo complessa, il guazzabuglio di frecce e rettangoli diventa presto ingestibile.
I linguaggi visuali possono essere un modo per semplificare alcune parti dello sviluppo, come lo sono stati in passato per il disegno delle UI, ma nulla di più.
Inoltre, se stai pensando che potrebbe essere bello avere un editor visuale per disegnare le form anche sul web ti rassicuro subito, sarebbe inutile. Nel web le interfacce devono essere responsive. Ad esempio la visualizzazione che sul desktop si vede sottoforma di griglia, sullo smartphone deve diventare una lista.
Quello che serve non è un tool grafico che permetta di disporre gli elementi al pixel, ma più che altro un linguaggio che permetta di descrivere come devono essere fatte le interfacce (es. la form deve avere 3 tab, nel primo tab ci deve essere la ragione sociale seguita dal codice fiscale, ecc.).
Il nostro approccio#
Nel corso del tempo e dei progetti abbiamo avuto modo di provare un po' tutti gli approcci allo sviluppo rapido di software e di valutarne pregi e difetti.
Abbiamo fatto vari tentativi per superare i limiti dei framework general purpose, degli strumenti come adminer e dello sviluppo naif.
Prima di tutto abbiamo abbandonato l'idea di realizzare un framework generico in favore del META-Sviluppo RAPIDO specifico per il settore dei software gestionali. Questo ci ha permesso di introdurre delle funzionalità ricorrenti nel campo dei software gestionali già a livello di libreria come la visualizzazione di dati in griglie paginate e la modifica dei dati con form e campi di inserimento dati avanzati (date con calendario, riferimenti esterni, ecc.).
Il primo risultato di successo lo abbiamo ottenuto con un tool autoprodotto di generazione di codice. In pratica abbiamo realizzato un compilatore che partendo da un codice descrittivo in formato JSON (il metalinguaggio) produceva il codice della web application.
Il codice generato era una sorta di semilavorato che andava poi modificato e personalizzato manualmente per modificare le logiche o aggiungere comportamenti diversi da quello generato.
Con questo primo compilatore abbiamo realizzato vari progetti custom in tempi relativamente brevi. Il difetto principale stava nel fatto che una volta modificato manualmente il codice del semilavorato non era possibile rigenerarlo a partire dal codice JSON perché le modifiche apportate al semilavorato sarebbero andate perse. In qualche modo quindi era veloce la fase di realizzazione dell'applicativo, ma la modifica o l'aggiunta di funzionalità era ancora un'attività lenta.
Dall'evoluzione di questo strumento e del compilatore è nato un nuovo META-linguaggio che è quello che utilizziamo attualmente. Non è più un linguaggio compilato, ma è un META-linguaggio descrittivo interpretato da un motore per web application gestionali.
Ad esempio con un solo file descrittivo come il seguente il motore sa già che deve visualizzare una griglia con i campi indicati, rendendo possibili le azioni specificate e adattare la visualizzazione al dispositivo utilizzato (desktop, tablet o smartphone). Il tutto con poche righe di codice dichiarativo. Infine con una serie di hook si possono modificare i comportamenti di default o inserirsi nel giro standard e apportare le opportune modifiche.
{
"label_s": _("User"),
"label_p": _("Users"),
"name": "user",
"type": "table",
"order": {"by": "user", "dir": "asc"},
"sorting_orders":{
"role": ["role","user"]
},
"permissions": [
{
"name": "user_management",
"label": _("User Management")
},
{
"name": "company_user_management",
"label": _("Company User Management"),
"condition": "#company = t.company"
},
{
"name": "profile_management",
"label": _("Profile management"),
"condition": "#id = t.id"
}
],
"actions": [
{
"name": "show",
"required_one": ["user_management", "profile_management", "company_user_management"]
},
{
"name": "edit",
"required_one": ["user_management", "profile_management", "company_user_management"]
},
{
"name": "new",
"required_one": ["user_management"]
},
...
],
"unique": [
['user']
],
"list_mobile": [
{
"field": "id",
"title":"name",
"left": "active",
"right_top": ["end_validity"],
"subtitle": ["company","role"],
}
],
"fields": [
{
"name": "id",
"type": "integer",
"label": _("Code"),
"readonly": true,
"grid_visible": false,
"form_visible": false
},
{
"name": "active",
"type": "boolean",
"label": _("Active"),
"required": true,
"access": {
"show": ["user_management"]
},
},
{
"name": "valid",
"type": "boolean",
"label": _("Valid"),
"table_read": true,
"access": {
"show": ["user_management"]
},
},
{
"name": "user",
"type": "string",
"label": _("User"),
"required": true,
"access": {
"edit": ["user_management"]
}
},
{
"name": "password",
"type": "password",
"label": _("Password"),
"required": true
},
{
"name": "role",
"type": "reference",
"label": _("Role"),
"required": true,
"reference": {"meta": "roles", "ondelete": "restrict"},
"decoding_view": "roles_dec",
"access": {
"edit": ["user_management"]
}
},
.....
]
}
Conclusione#
Secondo noi il futuro dello sviluppo rapido di software passa dalla definizione di nuovi linguaggi specifici per un singolo dominio in contrapposizione a linguaggi general purpose.
Per approfondire le caratteristiche del META-Sviluppo RAPIDO puoi consultare l'articolo META-Sviluppo RAPIDO per Gestionali Web