L‘aumento della mobilità del personale tecnico ICT, in congiuntura con l‘aumento di disponibilità di framework, metodologie e strumenti open source, ha determinato un aumento repentino della complessità delle applicazioni prodotte. Chi ci ha rimesso è stata l‘economia. L‘articolo esprime su ciò un giudizio chiaro e fa una proposta.
Introduzione
L’articolo è diretto innanzitutto ai Project Manager. Se il tecnico intende usare un oscilloscopio per verificare se alla lampada sul tavolo arriva corrente, deve essere il PM a impedirglielo: basta un cacciavite cercafase. La metafora esprime esattamente ciò che accade, sempre più spesso, da parte di un esercito di tecnici ICT che hanno continuamente bisogno di… dimostrare le loro virtù.
Cosa sta accadendo
Nel corso della vita (lifecycle) di un’applicazione, la parte che richiede maggiori risorse, quindi maggior costo, è la manutenzione. Questa realtà si è parzialmente modificata negli ultimi anni, perche’ è notevolmente aumentata la mobilità del lavoratore ICT. Accade più di frequente che lo sviluppo passi di mano attraverso non solo più programmatori, ma anche diversi progettisti (designer) che modificano le linee progettuali in corso d’opera. Accade più di frequente che ogni intervento di manutenzione, sia correttiva che evolutiva, sia effettuato da mani diverse.
In questo contesto occorrerebbe avere più cura, quindi spendere di più, per la documentazione scritta, ma questa mentalità è dura a prendere piede: non solo occorre che il programmatore e il designer (un tempo chiamato analyst) scrivano, ma poi il capo progetto (project manager, PM) deve ricontrollare; e soprattutto, occorre che i programmatori che vengono dopo abbiano la pazienza di leggere. Accade così che talvolta, durante la manutenzione, il PM decida il rifacimento di parte del software, o anche di tutto, non perche’ esso manifesta chiari segni di inefficienza, ma perche’ ritiene, spesso a ragione, che i nuovi programmatori faranno prima a rifarlo (magari con il framework che conoscono meglio) piuttosto che mettersi a leggere tutta la documentazione, analizzare il codice, scritto da n mani diverse, ed intervenire dove serve. Così tutta la teoria, insegnata nelle università, sul lifecycle del software è sconvolta. E i costi salgono.
L’economia è un’altra cosa
In questo contesto, se dobbiamo sviluppare una web application e vogliamo farlo in Java, è possibile fare delle scelte che riducano sia i costi di sviluppo, sia i costi di manutenzione.
Bisogna cominciare a demolire alcuni miti che hanno preso piede negli ultimi anni: suggestivi quanto volete, ma in nessun accordo con le esigenze dell’economia.
La possibile trappola dei framework
Il primo fra tutti i miti è quello dei framework: nati come moltiplicatori di efficienza, capaci di fornire un modello matematico, elegante e onnicomprensivo, per applicazioni vaste e complesse, che altrimenti sarebbero state, per dimensioni e quantità di interrelazioni, del tutto ingestibili, si è finito per usarli sempre e comunque, con grande dispendio di risorse. Proprio l’aumento della mobilità del personale ha trainato questa espansione: dando grande valore ai framework, questi diventavano i punti qualificanti con cui il tecnico ICT poteva presentarsi al colloquio con il PM per essere scelto a far parte del suo team.
I limiti di MVC
Un altro mito importante è quello del pattern MVC [1]: è stata un’importante sintesi culturale nata nei dipartimenti di Computer Sciences delle università americane. La netta separazione tra l’interfaccia grafica (GUI), la zona di controllo, la logica di business e l’accesso al DB è poi diventata centrale nella cultura dei designer di tutto il mondo.
Ma l’applicazione caparbia e meticolosa di questo principio ha portato un inutile aumento di complessità nelle applicazioni di piccole dimensioni, diciamo quelle con un numero di pagine < 10: cioè la maggioranza.
Do it really simple (DIRS)
Proviamo a dettare poche semplici regole per fare web application in Java, con pagine dinamiche. Saranno contrassegnate dall’acronimo DIRS: Do It Really Simple. Escludiamo l’uso di qualunque framework, e anche di Enterprise JavaBeans; dunque, tutte le applicazioni particolarmente complesse, quelle ad alta sicurezza e quelle con animazioni divertenti non fanno parte del nostro discorso.
Una precisazione: non sono best practices! Sono regole da rispettare puntualmente, se non proprio una metodologia.
Regola 1
L’applicazione parte sempre da una servlet. Ogni servlet prepara una Java Server Page (JSP), nessuna JSP chiama direttamente un’altra JSP. Il nome della servlet è identico a quello della JSP, salvo il fatto che l’iniziale è maiuscola per la servlet e minuscola per JSP.
Regola 2
Per ciascuna servlet, i parametri passati (fosse anche uno solo) mediante get o post formano complessivamente un oggetto, cioè una classe. Nella classe sono presenti sempre i due metodi controlliFormali() e controlliSostanziali(), eventualmente vuoti; questi, in caso di risultato negativo, escono con una exception.
Regola 3
Ciascuna JSP riceve i dati che deve visualizzare (render) da un unico Java Bean, mediante
Regola 4
Tutti i dati da visualizzare devono essere già stati preparati dalla servlet omonima, quindi la JSP deve ridurre al minimo le istruzioni java (<% …), privilegiando la semplice visualizzazione (<%= …). In particolare: i loop possono ciclare solo su array contenuti nel JavaBean; gli if possono avere come test solo variabili booleane contenute sempre nel JavaBean; niente and ne’ or.
Regola 5
Le JSP devono condurre alla generazione di pagine XHTML strict 1.x- Tali pagine XHTML 1.x potranno essere migrate facilmente verso l’incombente HTML5; sono praticamente compatibili con i criteri della legge Stanca inerente l’accessibilità dei siti per i portatori di disabilità; sono compatibili con tutti i browser; come logica conseguenza, saranno associate a un uso intensivo dei CSS.
Regola 6
Niente “virtuosismi” sulle JSP: niente JSTL, tag standard e non; in particolare, niente trasformazioni XSLT on-line (pattern Transform View, vedi ad esempio [2]). L’XSLT è un vero linguaggio di programmazione, e non è sempre facile trovare chi è capace di manutenerlo. Per mantenere un unico look and feel su tutte le pagine, il CSS, associato a un uso intelligente di <%@ include file=" …, è più che sufficiente.
Regola 7
L’accesso al DB è il JDBC, con tante belle query SQL e vari resultSet; ma ogni tabella di DB deve avere una sua classe, con lo stesso nome della tabella, che è semplicemente un JavaBean della riga della tabella stessa.
Regola 8
Ridurre al minimo i JavaScript: devono solo eseguire compiti ausiliari al funzionamento della pagina HTML, non logica di business; più semplicemente, vanno usati solo per ciò che non può essere in alcun modo scritto in Java, nella servlet; per esempio, non devono mettersi a fare i controlli formali o, peggio, sostanziali su quanto digitato dall’utente.
Regola 9
I packages sono costruiti come è descritto nel seguente esempio:
poniamo di lavorare per l’azienda Strada Azzurra SpA e dover realizzare un’applicazione vendemmia, con tre JSP: homepage, catalogo, strada. Si accederà a due tabelle di DB, pietre e canna. Sulla base di queste premesse, il package sarà questo:
package it.stradaazzurra.vendemmia: Costanti.java
più tutte le classi richiamate all’interno dei beans che trasportano dati nelle JSP;
package it.stradaazzurra.vendemmia.bean: HomepageBean.java,
CatalogoBean.java, StradaBean.java
package it.stradaazzurra.vendemmia.params: HomepageParams.java,
CatalogoParams.java, StradaParams.java
package it.stradaazzurra.vendemmia.servlet: Homepage.java,
Catalogo.java, Strada.java
package it.stradaazzurra.vendemmia.dao: Pietre.java, Canne.java
Ci saranno poi, direttamente sotto la root, le directories html, jsp, css, jar, images, eventualmente js; i necessari XML, le directories obbligatorie e quanto serve per i vari deploy. Nient’altro.
Tutte le ordinarie best practices [3] della programmazione in Java, a maggior ragione, continuano a valere.
Le possibili obiezioni
Come in ogni processo di cambiamento, ci saranno delle resistenze, le quali si possono concretizzare in una serie di obiezioni, apparentemente molto sensate. Di seguito riportiamo una serie di obiezioni possibili, e la risposta a ognuna di esse.
E dove sta il vantaggio economico?
I modi con cui si può implementare un programma sono infiniti. I nomi che si possono scegliere per gli oggetti, pure. Ma obbligando il programmatore a seguire queste regole, otteniamo applicazioni quasi autodocumentate che, una volta collaudate e messe in linea, possono essere date in manutenzione a qualunque programmatore junior.
Come documentazione, oltre all’indispensabile JavaDoc, basterà un disegno del flow delle pagine, che può anche essere fatto con uno strumento di grafica vettoriale open source (ad esempio Draw di OpenOffice). L’UML [4] è bellissimo, ma per applicazioni come queste, l’unico diagramma veramente utile è il Sequence Diagram.
Questo programmatore, già nella sua prima ora di lavoro, si farà un’idea di come funziona il sistema, di dove andare a prendere le servlet, di quali parametri passano dall’una all’altra. Poiche’ valgono sempre le vecchie regole di non ripetizione del codice, ogni modifica dovrà comportare un intervento su un numero ristretto di oggetti.
C’è un vantaggio anche nella fase di sviluppo?
Non come quantità di tempo. Facciamo riferimento allo schema dello Unified Process: inception, elaboration, construction, transition. Il fatto di dover seguire queste regole aumenta il tempo dell’elaboration. Il vantaggio è un altro, tutto per il PM: riesce a preventivare quanto tempo e quante persone occorrono (time & material) con minore errore. Ad esempio, è comune andare a fare stime con un errore del ±50%: invece di 2 mesi/uomo, poi ce ne metto 3. Con queste 9 regole è possibile stimare il tempo della fase che generalmente è la più lunga, cioè la construction (molto approssimativamente, corrisponde alla scrittura del codice), con un errore molto più basso. Poiche’ a una servlet corrispondono una JSP, un bean di contenuti e un oggetto-parametri, addirittura si può stimare un tempo pari a 4 giorni a modulo (1 modulo = servlet+JSP+bean+parameters) a priori. Non sono pazzo, si tratta di un valore medio. Ricordate che ho premesso non trattarsi di applicazioni complesse. Su una stima così l’errore c’è, ma è più contenuto: diciamo il ±10%; a questo tempo, calcolato in riferimento a un programmatore senior, occorre poi aggiungere le altre 3 fasi, spesso con un particolare impegno del web graphics designer; questi altri tempi ovviamente non sono stimabili a priori.
Infine il PM ha un metro, un riscontro oggettivo per sapere lo stato d’avanzamento del lavoro (SAL) di sviluppo da parte del programmatore.
La complessità di un’applicazione non è proporzionale al numero delle diverse pagine HTML, quindi non puoi dire: “solo se < 10". Come faccio allora a stabilire se posso usare queste regole?
Certo che non è proporzionale! Però è un criterio per capire subito se si può tentare di applicare DIRS o no. Nel giro di 2 o 3 giorni appare subito evidente se “regge”. E anche se non regge, non è comunque tempo perso: va tutto a vantaggio del lavoro di scrittura della documentazione.
Perche’ non posso usare JavaScript? È tanto intelligente far lavorare il processore del tuo PC, invece che quello dell’application server!
Questi sono ragionamenti da tecnico ICT: il buon PM, che innanzitutto è un ragioniere, la pensa diversamente. Ogni linguaggio di programmazione diverso in più porta un fattore moltiplicativo nella stima del tempo, non un addendo. Il linguaggio Java c’è dentro per definizione. Poi abbiamo SQL, quello è sacro: il genio di Gavin King, con Hibernate, è riuscito a ridimensionarlo, ma non a liberarcene. Poi XHTML e infine il CSS. Non è vero che il CSS è appannaggio del solo web designer: ora non si lavora più così e il programmatore deve comunque abbozzare una pagina HTML con tutti i suoi CSS, brutta quanto volete ma deve farla per poter cominciare a fare i primi piccoli cicli di analisi/sviluppo/test; quando la darà al grafico, all’artista, sarà per realizzare effetti 3D, limpide pennellate, contenuti mozzafiato e quant’altro. Dunque i linguaggi sono già quattro, l’ECMAscript o JavaScript sarebbe il quinto: e non è vero che il JavaScript è java (nemmeno un quasi-Java)! Insomma, senza JavaScript, quello che si spende per un application server più robusto è certamente inferiore a quello che si spenderà in più per la manutenzione nei 2, 3 o 5 anni che l’applicazione rimarrà on line.
Hai inventato l’acqua calda! Così puoi fare solo dei giochetti, non applicazioni professionali
Non è vero. Provare per credere! Nella mia esperienza, solo con queste 9 regole, ho fatto e visto fare applicazioni robustissime, intelligenti, facilmente deployabili su qualunque application server.
Ma queste sono le JSP di 10 anni fa…
Al contrario, 10 anni fa, alla release 1.x, non sapevamo fare buone JSP: erano piuttosto ingenue e ci incastravamo dentro di tutto. Queste sono assolutamente pulite.
E l’MVC che fine fa?
La separazione della “V”, ottenuta con una JSP che riceve un dato già perfetto, a cui la JSP stessa non deve aggiungere nulla, è sufficiente per permettere al web designer di lavorare in parallelo con il programmatore. E questo per l’economia basta.
Mi dispiace per i puristi, ma la separazione tra M e C non c’è. Però quelle 9 regole descrivono una struttura così semplice che, come ho già detto, un programmatore junior può comprenderla in poche ore, e può diventarne padrone in pochi giorni.
Niente questo, niente quest’altro, nomi obbligatori… e la mia creatività che fine fa?
Quanto finora illustrato non è dogmatismo, è disciplina. Spesso si dimentica che un’applicazione informatica è un prodotto industriale. Se tu odi questa disciplina, forse dovresti cambiare mestiere.
OK, scriverò web application secondo questo DIRS, questi schemi. Ma al prossimo colloquio che gli racconto?
Senti un po’, ma l’interesse del cliente mai? Lo sai che se io abbatto i costi di produzione, posso offrire al cliente un prezzo più basso, e lui è incoraggiato a investire anche se le sue possibilità economiche sono modeste? E quindi, alla fine, io posso dare lavoro a te…
Conclusioni
L’articolo piacerà molto poco ai giovani informatici, vedi l’ultima della serie di obiezioni. Ma i dirigenti degli Information and Communication Technology Department e i loro capi progetto faranno un largo sorriso: come accade a zio Paperone (uncle Scrooge), il segno del dollaro apparirà nelle loro pupille.
Riferimenti
[1] Martin Fowler, “Patterns of Enterprise Application Architecture”, Addison Wesley
[2] Sandro Pedrazzini, “Tecniche di progettazione agile con Java: design pattern, refactoring, test”, Tecniche Nuove
[3] Bruce Eckel, “Thinking in Java”, Apogeo
[4] E. Damiani – M. Madravio, “UML pratico”, Pearson – Addison Wesley