Il mese scorso ad Aarhus si è svolta la decima edizione della JAOO Conference, probabilmente il più importante evento europeo nel campo dello sviluppo e dell‘ingegneria del software. Ecco un riassunto dell‘accaduto.

Ho avuto la fortuna di partecipare alla recente edizione della JAOO Conference, svoltasi ad inizio ottobre ad Aarhus, in Danimarca, probabilmente (come testimoniato dall‘impressionante board http://www.jaoo.dk/speakers/ degli speaker) il più importante evento a livello europeo,nel campo dello sviluppo di applicazioni Java, di metodologie di sviluppo, ma non solo. Le track di quest‘anno spaziavano dalle metodologie agili, a SOA, alle tecnologie per il rich client (web e standalone) con uno spazio riservato anche a Ruby e .Net, con il risultato di creare uno spazio aperto ad influenze esterne, più pragmatico che dogmatico.

Tra i miei obiettivi c‘era quello di “annusare il vento” delle tendenze nella comunità  Java, ed ecco il risultato, argomento per argomento. Tra parentesi ho riportato l‘impressione sulla tendenza dell‘argomento: tale giudizio deriva dai contenuti degli interventi e delle discussioni.

 

UML (giù)

Argomento decisamente freddino, le recenti evoluzioni di UML non hanno scatenato particolari entusiasmi. Da più parti (Eric Evans e Dave Thomas, per citarne alcuni) è stato rimarcato che UML ha valore in quanto strumento di comunicazione più che di definizione delle specifiche. Meglio un diagramma disegnato alla lavagna e condiviso da tutto il gruppo di lavoro, che analisti che lavorano in isolamento disegnando diagrammi UML sui loro CASE tools.

 

XP (giù)

Sembra che anche questo termine abbia perso un po‘ di smalto. La maggior parte degli speaker, ma anche degli iscritti, era in linea di principio orientata favorevolmente rispetto alle metodologie agili. Tuttavia XP non è più un termine di riferimento così interessante: determinate pratiche quali Continuous Integration o Test Driven Development sono state fatte proprie anche da altre metodologie, mentre XP nel suo insieme ha subito qualche scacco (orde di barbari che predicano l‘anarchia chiamandola XP, o più realisticamente una difficoltà  ad adattarsi a tutti i contesti) che ne ha un po‘ minato la credibilità .

 

SCRUM (su)

Dal calderone delle metodologie agili, SCRUM sembra emergere con una certa autorevolezza. Jeff Sutherland ha mostrato nel suo intervento come SCRUM faccia proprie le attitudini del lean thinking di scuola Toyota e si prefigga obiettivi decisamente ambiziosi in tema di produttività  ed efficienza del processo di sviluppo. I case study presentati portano a definire SCRUM come la metodologia agile più adatta a scalare in alto come dimensione, senza restare ancorata alla dimensione del gruppo di sviluppo medio-piccolo, che sembra essere il destino di XP.

 

DSL – Domain Specific Languages (su)

Si sono meritati l‘onore di un‘intera track e, nel complesso, un notevole interesse da parte degli addetti ai lavori. In generale, la tendenza riscontrata è quella di riportare il domain model al centro dello sviluppo delle nuove applicazioni; se il dominio è complesso, ed è normalmente espresso in formalismi che non hanno molto a che vedere con un linguaggio di programmazione tradizionale, allora permettere agli esperti di dominio di operare con il proprio formalismo all‘interno di uno scenario applicativo più complesso può diventare un‘alternativa praticabile.

È possibile, in altre parole, pensare a un linguaggio pensato per una determinata nicchia molto specializzata di utenti (come il linguaggio Fortress – il FORTRAN del futuro, presentato da Guy Steele – la cui sintassi è quella delle espressioni matematiche), che possa essere innestato su un‘ “intelaiatura” Java, oppure a una personalizzazione della sintassi Ruby per venire incontro alle esigenze espressive di un determinato dominio.

Alcuni interrogativi al riguardo restano tuttavia ancora irrisolti; uno per tutti: la definizione di un dialetto proprietario per l‘espressione del dominio sembra un‘ottima cosa se questo è perfettamente definito al primo colpo, ma può rivelarsi una trappola nel ciclo di vita complessivo dell‘applicazione.

 

100% pure Java (giù)

Oltre alle track sui DSL, su Ruby e su .Net si respirava un‘aria più rilassata rispetto all‘onnipotenza di Java. Se è tuttora vero che Java è il linguaggio più completo e versatile rispetto alle possibilità  d‘uso e alle piattaforme hardware che lo possono ospitare, è tuttavia evidente che Java non è il miglior linguaggio per risolvere specifiche classi di problemi. L‘attenzione monomaniacale da parte dei programmatori a un solo linguaggio ha fatto in molti casi dimenticare che problemi complessi in Java sono banali in altri linguaggi. Ogni linguaggio nasce per una classe di problemi ben definita: la conoscenza di altri linguaggi, oltre a Java, permette in molti casi di individuare strade alternative, non visibili a chi è abituato a “ragionare in Java”. La diffusione di architetture SOA rilassa i constraint sul linguaggio che invece i pervasivi framework J2EE avevano contribuito a introdurre. Da più parti è arrivata la raccomandazione a imparare più linguaggi, o a non dimenticare quelli appresi all‘università , in quanto rappresentano un patrimonio di soluzioni brillanti o di errori già  commessi che non può essere ignorato.

 

Agile Software Development (stabile)

Non sono state presentate novità  di rilievo, ma la track sulle metodologie agili è stata decisamente una delle più seguite, probabilmente anche grazie alle notevoli doti di intrattenimento di alcuni speaker quali Alistaire Cockburn e Kevlin Henney. Ad alzata di mano, si è verificato che circa l‘80% dei partecipanti adottava metodologie agili sui propri progetti, anche se non tutte le pratiche erano effettivamente adottate. È stato anche interessante notare che le differenti leggi che regolano il mercato del lavoro e i mercati commerciali in Europa e negli Stati Uniti hanno un forte impatto sulle metodologie: negli Stati Uniti il mercato del lavoro ha meccanismi di incentivi piuttosto organizzati e formali (per esempio, il bonus al miglior sviluppatore del team), che impattano direttamente le dinamiche di gruppo, specialmente quando queste sono più elastiche rispetto a quelle retributive; in Europa, l‘organizzazione aziendale non ha le stesse caratteristiche di turnover “selvaggio” (qualcuno ha sarcasticamente fatto notare come certe metodologie agili non fossero altro che la correzione di rotta rispetto all‘ossessione tutta americana per il processo, e la meccanica intercambiabilità  degli sviluppatori), per cui si presta meglio all‘adozione di metodologie agili. Le leggi europee, d‘altro canto, portano a formalizzare i contratti di sviluppo software includendo i requisiti. Ciò crea una discrepanza forte tra il processo agile (per il quale i requisiti possono cambiare in corsa) e il vincolo contrattuale, che è poi quello da rispettare a termini di legge. Problema tutt‘altro che banale.

 

Domain Driven Design (su)

Il libro, uscito un po‘ in sordina qualche anno fa, sta pian piano diventando un testo di riferimento. Eric Evans, inoltre è decisamente un ottimo comunicatore: le slide della sua presentazione erano probabilmente le migliori del lotto. Uno dei principi alla base del DDD è che, per le applicazioni enterprise, il valore principale non è nella tecnologia ma nel modello utilizzato, che può risultare un acceleratore o un freno per le prospettive commerciali dell‘azienda. Il modello ideale (per certi versi un ritorno all‘OOP “prima maniera”) è indipendente dalla tecnologia, e si evolve parallelamente ad essa. A conclusioni molto simili, sia pure sul versante tecnologico è giunto anche Rod Johnson nell‘affermare che l‘architettura deve permettere di sviluppare un modello OOP puro, basato sui POJO. Ovviamente Spring permette esattamente questo.

 

CASE tools (giù)

Se qualche anno fa la domanda “quale strumento utilizzate per il design?” era ricorrente (probabilmente, per cercare di spendere oculatamente il proprio budget), oggi nessuno sembra considerare più il problema particolarmente interessante; o comunque, la scelta di uno strumento piuttosto che un altro non è più un fattore determinante per la definizione del processo di sviluppo da adottare.

 

MDA (giù)

Stesso problema dei tool CASE. In un certo senso, MDA avrebbe potuto avvantaggiarsi del trend di “ritorno al Domain Model”, che è uno dei principi fondanti della Model Driven Architecture. Balzava comunque all‘occhio il fatto che ogni speaker che si esprimeva in favore di Domain Driven Design o Model Driven Design si affrettava a specificare che non stava parlando di MDA e dei relativi meccanismi di code generation. Più esplicitamente, Rod Johnson ha messo in luce che l‘adozione di MDA per garantire l‘indipendenza del modello dalla piattaforma tecnologica, allo stato attuale finisce per introdurre dipendenze, forse ancora più pericolose, dalla piattaforma MDA adottata e dal relativo processo di sviluppo. La sensazione complessiva – in assenza di miracolosi interventi vendor oriented – è stata che il contesto di applicabilità  si limita ad una nicchia abbastanza ristretta di progetti.

 

AOP (stabile)

Le buone notizie sono che nessuno mette più in dubbio che possa funzionare, e che possa diventare parte integrante di strumenti di uso comune, come testimoniato dall‘abbondante ricorso ad AspectJ da parte di Spring 2.0, o di altre applicazioni di infrastruttura. Tuttavia l‘effettiva utilità  di AOP nelle applicazioni tradizionali resta ancora piuttosto dubbia: meglio sfruttarne le potenzialità  indirettamente utilizzando un framework che ne nasconda le caratteristiche più sconcertanti come la sintassi e le possibili violazioni dell‘incapsulamento.

 

Ruby (su)

Una track dedicata specificatamente a Ruby, che ha riscosso molto interesse tra gli addetti ai lavori, anche per le caratteristiche del linguaggio, progettato per soddisfare il palato degli sviluppatori. Tutti i Javisti vorrebbero farci almeno un giro…

 

AJAX (su)

Sta diventando la tecnologia mainstream per tutti, volenti o nolenti. Sia per le applicazioni enterprise, che per quelle più spiccatamente Web 2.0. La presentazione del Google Web Toolkit ha fatto molto parlare di sà©, e fatto venire l‘acquolina in bocca a più di uno sviluppatore. Le possibilità  offerte dall‘idea delle mash-up web applications appaiono sterminate: resta solo da vedere dove ci porteranno.

 

ORM (giù)

Tutte le domande al riguardo venivano accolte con annoiata sufficienza; e lo sesso dicasi per XML. In generale ci si aspetta (più o meno ragionevolmente) che il supporto a queste problematiche, almeno per quanto riguarda l‘XML, possa essere risolto in maniera nativa quanto prima, per permettere ai programmatori di concentrarsi sui veri problemi.

 

Conclusioni

Tutto sommato, l‘elemento comune dell‘intera manifestazione è stato il pragmatismo che ha contraddistinto praticamente tutti gli interventi. Decisamente pochi gli interventi “vendor-oriented”, e in generale nessuno di stampo “miracolistico”. Da rimarcare invece l‘attenzione a quanto avviene in ambiti non-Java o a quanto è già  avvenuto nel passato, o addirittura alle esperienze interdisciplinari, perché, sia pure nella sua peculiarità , il mondo dello sviluppo software è un‘industria giovane, con molto da imparare, ma anche con un fardello di esperienze non trascurabile.

 

Riferimenti

[1] Il sito ufficiale della JAOO Conference http://www.jaoo.dk