Code o No-Code, questo il dilemma
Vorrei dire la mia su una questione molto dibattuta ed assolutamente attuale, dato il numero sempre crescente di strumenti software che consentono di realizzare soluzioni senza scrivere una riga di codice (no-code, appunto).
E' un discorso complesso anche perchè può essere affrontato da una miriade di punti di vista.
Estremizzando, possiamo ricondurre al tema (un po' forzosamente) anche eterne diatribe.
Ci sono, ad esempio, molti sviluppatori che esprimono un'opinione molto marcata a riguardo (sintetizzo qui una sorta di merge di diverse discussioni che ho avuto in passato, nemmeno tanto remoto):
Odio sistemi di esecuzione virtuale perchè non mi lasciano il controllo su tutti gli aspetti dell'applicazione che scrivo. Odio i meccanismi di gestione automatica della memoria perchè non so cosa fanno (a questo si può porre rimedio, però, nda :-), non so quando lo fanno, lo fanno male, io lo posso fare meglio. Uso COM, ma non uso gli smart pointer perchè voglio avere il controllo esplicito sul rilascio degli oggetti, voglio in ogni momento essere in grado di dirti esattamente il reference count (e ci becco sempre), tutto sommato non uso ATL perchè aggiunge solo complessità, mi implemento la QueryInterface a mano ogni volta, scrivo codice altamente ottimizzato. Sono la macchina.
Personalmente sono piuttosto critico rispetto a questo atteggiamento, la cui validità a mio giudizio decresce all''aumentare della complessità del sistema.
Mi viene in mente il tema di italiano che era uscito l'anno in cui mi sono diplomato (scientifico 97): "Siamo nani sulle spalle dei giganti". Anche qui forzo un po' il contesto, ma un discorso come quello quotato sopra mi sa un po' di ciecità nei confronti dei "giganti" e, a volte, di presunzione di essere in grado di "fare le cose meglio". Chiaro che la generalizzazione è sempre foriera di errori e visioni distorte, ma diciamo che il problema che si pone non è esattamente marginale.
Con queste premesse, e spostandoci di qualche livello di astrazione verso l'alto, considerate queste opinioni (sempre sintesi di discussioni raccolte in questi mesi):
Odio gli application server, odio qualsiasi cosa che abbia un pulsante "Next" in basso a destra, odio qualsiasi strumento che si usa e si configura in via amministrativa, odio le soluzioni out-of-the-box. Magari sono programmi ben fatti, pieni di funzionalità, attraenti dal punto di vista grafico, ma di 100 cose che fanno ne uso a dir tanto 10, me ne servirebbero 11 ma quella che manca non riesco a realizzarla. Lo strumento preconfezionato non si adatterà mai al mio scenario reale.
Qui sono meno critico.
Con un *importantissimo* distinguo, però.
Adottare i (cosiddetti) strumenti no-code come componenti dell'architettura di un'applicazione è una scelta che va assolutamente considerata. Ed è fondamentale, a mio giudizio, effettuare questa scelta in base ad alcuni parametri:
- Lo strumento è adatto per il mio dominio applicativo ? (sembra scontato, ma presuppone comunque una solida valutazione dello strumento in questione, cosa che non sempre viene svolta)
- Qual è il costo dello strumento ? (costo nel senso di euro, costo nel senso di tempi di apprendimento, costo nei termini di tempo di sviluppo e manutenzione ... come vedete anche qui non è esattamente banale scegliere)
- Lo strumento è realmente estensibile ?
Non ho commentato inline l'ultimo punto, perchè in realtà è quello che sta alla base di questo post.
Perchè credo sia un fattore realmente determinante e, spesso, sottovalutato.
Per estensibilità, in questo contesto, intendo la possibilità di aggiungere funzionalità non previste e non disponibili nel pacchetto, così come di modificare funzionalità esistenti, ma non perfettamente adeguate allo specifico della soluzione che si va a realizzare.
"No-Code" ?
Ma mica è un male ! Mica possiamo valutare la robustezza e la completezza di una soluzione in base al numero di righe di codice che *noi* scriviamo !!
Però No-Code != "non posso scrivere codice".
No-Code, per come la vedo io, dovrebbe essere uguale a "posso non scrivere codice". Ma anche "posso scrivere codice, se mi serve".
Gioco di parole sottile ma differenza grossa come una casa (di quelle grosse).
Quando si sottolineano i vantaggi di soluzioni no-code, uno dei punti maggiormente rimarcati è che la definizione della soluzione può essere delegata ad un power-user, che non deve necessariamente avere competenze di sviluppo, ma semplicemente essere un esperto del dominio applicativo.
Ottimo !
Però quando il power-user si blocca di fronte ad un (magari apparente) limite dello strumento, chiama il power-dev a dargli una mano, no ?
E il power-dev è mooooooolto contento se si ritrova un ambiente in cui può mettere le mani, anche in profondità, per risolvere le esigenze del suo cliente ;-)