Cicli di sviluppo più rapidi, comunicazione più chiara, e un coinvolgimento attivo degli interessati sono alcune delle promesse del Movimento Agile [1].
Apparentemente i DSL, acronimo che sta per Domain Specific Language, possono sembrare un qualcosa di molto tecnico e poco legato a questi argomenti. Tuttavia i sistemi basati su DSL possono velocizzare il raggiungimento degli obiettivi dell’agilità; per questo motivo possiamo considerarli come “abilitatori di un approccio Agile”, in particolare in tutti quei casi dove è necessaria una forte competenza di dominio e in cui la collaborazione tra esperti e sviluppatori è più complicata.
In questo articolo svilupperò la tematica traendo spunto da uno speech di Federico Tomassetti, esperto di DSL e Language Engineering, ospite di un meetup online organizzato da SAM – Scrum Agile Milano.
Dopo avervi dato un minimo di contesto sui DSL, vedremo i tipici problemi di comunicazione tra tecnici (dev) ed esperti di dominio nella gestione di un progetto software e il perché sia utile per ambo le parti adottare un DSL, con una piccola digressione sul Projectional Editing.
E l’Agilità in tutto ciò?
Possono i DSL essere abilitatori di un approccio Agile? I DSL rispettano i valori del Manifesto Agile?
Buona lettura.
DSL interni ed esterni
In base all’obiettivo che devono raggiungere, possiamo dividere i progetti in due macro gruppi: uno in cui è centrale la tecnologia e l’altro in cui ad essere al centro sono la competenza e le capacità, le skill, delle persone. Per capirci meglio farò due esempi abbastanza significativi.
Prendiamo il caso in cui ci viene chiesto di realizzare una applicazione per il monitoraggio dei dati di una certa automobile. E’ evidente che avremo bisogno di competenze, sia tecniche (chi mi realizzerà il software) ma anche di dominio, ovvero chi è esperto del settore (ad esempio meccanici o piloti).
Tutt’altro discorso si avrebbe qualora ci chiedessero invece di realizzare un’applicazione per la riproduzione di brani musicali. In questo caso non avremo bisogno di particolari conoscenze di dominio, ma solo tecniche.
Nel resto dell’articolo si parlerà di DSL per quei progetti dove è l’expertize ad essere centrale, quindi la conoscenza di dominio.
Non leggerete quindi di DSL tecnici, per sviluppatori per intenderci, conosciuti come DSL embedded o DSL interni dei quali comunque parlerò nel breve. Una definizione di DSL interno potrebbe essere la seguente: un tentativo di forzare un linguaggio di programmazione. L’intento è creare delle librerie le quali, quando usate, non sembra di utilizzare quel linguaggio specifico ma appunto un altro magari più umanamente leggibile e comprensibile. Questa forzatura presenta dei limiti dal momento in cui sto comunque scrivendo codice di quello specifico linguaggio e quindi dovrò necessariamente utilizzare un IDE coerente, e avrò a che fare con un interprete che mi restituirà degli errori tecnici. In definitiva un DSL interno è sì facile da realizzare ma i benefici sono ridotti.
Un DSL esterno è invece un linguaggio indipendente, creato da zero, con un suo editor, funzionalità, interprete del codice e in generale tutto ciò che serve realizzato su misura, ad-hoc, senza le limitazioni portate da un altro linguaggio. Tra i diversi strumenti esistenti a disposizione per realizzare DSL, chiamati Language Workbench [2], uno molto utilizzato è MPS, un IDE gratuito della famiglia di prodotti Jetbrains. Qualora voleste approfondire, potete consultare la pagina MPS Rocks [3] ricca di riferimenti utili oppure iscrivervi al gruppo Slack [4] per discutere con utenti magari più esperti.
Da quanto vi ho appena scritto, salta all’occhio quale sia il maggior vantaggio di un DSL esterno: facilitare il lavoro tra sviluppatori ed esperti di dominio con strumenti utilizzabili anche da questi ultimi.
Farebbe molto comodo adottare un DSL in ogni progetto, perché la realtà è ben diversa.
Dev e Esperto di dominio: due mondi apparentemente vicini
Nella stragrande maggioranza dei progetti nel quale lavoriamo abbiamo una situazione “asimmetrica” sul livello degli strumenti a disposizione per i tecnici e gli esperti di dominio.
Un classico dev ha, negli anni, arricchito e migliorato i propri strumenti, pensiamo alla quantità di IDE esistenti al giorno d’oggi. Strumenti che facilitano e non di poco il lavoro (esistono tantissimi strumenti e librerie dedicate al testing del software).
Non possiamo dire altrettanto per gli esperti di dominio; a ben pensarci non esiste uno strumento che li aiuti nelle loro attività, come ad esempio la scrittura e validazione dei requisiti di un progetto.
Immaginiamoci ora questa situazione: chiediamo ad uno sviluppatore di fare il suo mestiere, quindi scrivere il codice di un programma, munito solamente di carta e penna. Niente pc, IDE, compilatore…nulla. E ovviamente pretendiamo che, alla scadenza del progetto, ad esempio tra un mese, il programma dovrà funzionare. Ora, è assurdo pensare che al primo tentativo qualunque programma sarà perfetto e funzionante, esente da bug. E se anche lo fosse, quello sviluppatore avrebbe raggiunto l’obiettivo ma con effetti sulla produttività enormi (magari lavorando 12 ore al giorno sette giorni su sette).
Ecco, la situazione attuale di un esperto di dominio è paragonabile a questa appena scritta del povero sviluppatore.
Ogni volta che il team di sviluppo riceve un documento di requisiti, si deve essere consapevoli che tale artefatto è stato realizzato senza l’ausilio di nessun compilatore o strumento specifico.
Ancora una volta, lo stesso non si può dire per il codice scritto. Ogni singola riga viene validata, testata da appositi test (scritti dal dev stesso) eseguiti su tutto il codice. Si ha quindi la percezione, grazie ai feedback restituiti dal compilatore e dai test, di come si sta lavorando.
Alla luce di queste considerazioni, vediamo le sfide principali in un progetto “esperto-centrico”:
- Semplificare la comunicazione. Tecnici ed esperti di dominio spesso non si capiscono perché entrambi non hanno le competenze dell’altro.
- Evitare di creare situazioni di stallo. Gli sviluppatori, come gli esperti di dominio, possono rimanere bloccati l’uno in attesa dell’altro per diversi motivi: problemi di comunicazione, specifiche mancanti, esperti di dominio che hanno bisogno di aiuto di un dev per rendere la specifica il più comprensiva possibile.
- Rendere lo sviluppo snello e adattabile al cambiamento. Per i problemi appena visti, lo sviluppo spesso è molto lento e costoso, e ogni cambiamento è critico.
Come si può reagire velocemente?
Perché adottare un DSL? Che aspetto ha?
Dotarsi di un DSL porta due grandi vantaggi.
- Forniscono supporto agli esperti di dominio nella scrittura di specifiche.
- Anche gli esperti di dominio possono scrivere dei test per validare le specifiche man mano che vengono redatte.
Che aspetto ha un DSL?
Un DSL deve essere inteso come semplicemente un linguaggio bensì un ambiente di sviluppo completo di tutte le funzionalità utilizzate e apprezzate dagli sviluppatori: simulatori, scrittura ed esecuzioni di test, “validazione inline” durante la scrittura e la possibilità di generare documentazione.
Quando parliamo di strumenti per realizzare DSL non si può non citare il Projectional Editing.
Projectional Editing
Il Projectional Editing è sì una nuova tecnologia, ma non recentissima; già nel 2008 ne parlava Martin Fowler in un suo blogpost [5]. JetBrains fa uso di questa tecnologia per realizzare e mantenere il progetto MPS per il suo workbench linguistico per appunto creare linguaggi specifici del dominio.
Un projectional editor, tradotto “editor di proiezione”, consente all’utente di modificare in modo efficiente la rappresentazione AST (Abstract Syntax Tree) del codice. Può imitare il comportamento di un comune editor di testo per le notazioni testuali, un editor di diagrammi per linguaggi grafici, un editor tabulare per la modifica di tabelle e così via.
L’utente interagisce con il codice tramite visuali intuitive sullo schermo.
Grazie al Projectional Editing un utente “non tecnico”, il nostro esperto di dominio, può lavorare sfruttando uno strumento che lo supporta e valida passo passo il suo lavoro.
DSL come abilitatori di un approccio Agile
Tornando al nostro mondo Agile, sarebbe Agile sviluppare linguaggi? La risposta è sì, se basati su Projectional Editing.
Come realizzare il nostro DSL?
Tre macro fasi:
- Insieme al cliente discutere con chi è coinvolto nel progetto, per capire bene il contesto.
- Sviluppare un prototipo sulla base delle informazioni raccolte.
- Consegnare il prototipo e, sulla base dei feedback ricevuti dagli utilizzatori, organizzare delle modifiche migliorative e iterare il processo.
Comprendere il contesto racchiude una serie di considerazioni su diversi aspetti:
- il dominio: Che cosa si aspettano di esprimere attraverso il DSL?
- il processo: Come stanno lavorando le persone in questo momento?
- la sfida: Cosa non sta funzionando?
- le interazioni: Come comunicano e collaborano tra di loro i vari gruppi?
Partendo da queste domande si dovrebbe poi realizzare un prototipo del DSL che possa trovare una risposta, o meglio una soluzione, per ognuna di esse.
Sarebbe consigliabile riutilizzare parti di DSL di altre librerie laddove è possibile. Quando si reputa il prototipo abbastanza maturo, ovvero in grado di tradurre alcuni esempi d’uso, si va dal cliente per mostrarglielo. Da qui in poi starà al cliente il quale, utilizzando il DSL, fornirà dei feedback per migliorare il prototipo.
Con questo approccio molto Agile, fatto di stretta collaborazione con il cliente, feedback e iterazioni otterremo uno strumento che potrà porre fine a quel divario prima citato tra tecnici ed esperti di dominio.
Con un DSL ad-hoc anche gli esperti di dominio hanno uno strumento affidabile e potranno lavorare autonomamente, senza più dover continuamente coinvolgere i dev i quali potranno svolgere i loro compiti in maniera più autonoma.
DSL e Manifesto Agile
Riprendiamo ognuno dei quattro valori del Manifesto Agile per vedere che impatto i DSL hanno su di essi.
Il software funzionante più che la documentazione esaustiva
Questo valore è perfettamente incarnato dai DSL, dato che semplificano la comunicazione tra le persone aiutandole permettendo la creazione di documenti condivisi chiari e semplici.
La collaborazione col cliente più che la negoziazione dei contratti
Ne abbiamo parlato, tecnici ed esperti di dominio collaborano fortemente grazie ai DSL. Anche questo valore del manifesto viene rispettato.
Rispondere al cambiamento più che seguire un piano
Ne abbiamo parlato, i DSL sono sistemi che, per design, sono pensati per rispondere ai cambiamenti di tutto un contesto. Solo attraverso i feedback si reagisce apportando dovute correzioni, non c’è nessun piano predefinito. Perciò anche questo valore è rispettato.
Gli individui e le interazioni più che i processi e gli strumenti
L’unico valore che non viene rispettato. L’idea di ogni DSL si basa sull’adozione di tool specifici.