C’è un detto nell’industria informatica: Un progetto si sviluppa due volte, e la prima versione è quella “da buttare”, la seconda è quella definitiva. La prima versione sarà immancabilmente piena di errori, poco scalabile, poco flessibile, e viene utilizzata per capire come si deve fare il progetto definitivo, cosa si deve e cosa non si deve fare. Una volta capito e appreso l’approccio giusto, si procede allo sviluppo del progetto definitivo.
Questa frase è, ovviamente, un po’ burlesca, ma un fondo di verità lo contiene. Ogni progetto complesso porta con se anche molte incognite. Molti sviluppatori, anche espertissimi, si trovano a volte davanti a un progetto che richiede sviluppo di parti per le quali è difficile fare in modo accurato l’analisi esaustiva e prevedere alcune categorie dei problemi che possono sorgere e fare una qualsivoglia stima di lavoro da fare. E c’è sempre il rischio (per non dire un’alta probabilità) che il prodotto sviluppato sia tutt’altro che utilizzabile.
Ed è per questo che entra in gioco la prototipazione rapida. Mettere su rapidamente un prototipo funzionante o semifunzionante è di assoluta importanza per poter delineare il percorso del progetto e per poter fare le stime del lavoro da fare, dei tempi di sviluppo e dei fondi da stanziare.
L’errore che le aziende spesso fanno, ed è quello che aggiunge un ulteriore strato di verità alla frase dell’inizio della pagina, è quello di utilizzare lo stesso linguaggio di programmazione per lo sviluppo del prototipo e per lo sviluppo della soluzione definitiva. Facendo così, di fatto si sviluppa il progetto due volte. La tentazione di fare così è forte e c’è sempre l’illusione che si potrà riciclare del codice della prima versione e farlo confluire nella seconda. Non è che questo non capita, ma molto meno frequentemente di quanto ci piacerebbe che succedesse. E c’è sempre, in agguato, il rischio di voler portare - per motivi di fretta, scadenze, pigrizia o altri - del codice vecchio nel progetto nuovo, “sistemando gli errori”. Spesso, però, si portano dietro anche dei difetti strutturali ed errori progettuali e delle scelte archittetturali sbagliate. Alla fine, non è che si risparmia tempo, il tempo così si perde.
E’ molto meglio utilizzare qualche linguaggo più semplice, o una combinazione di linguaggi, facili da usare, flessibili, poco prolissi, possibilmente se hanno la metaprogrammazione integrata, e mettere in piedi qualcosa che ci dia delle idee sul da farsi.
In realtà, spesso non è neanche necessario (anche se è fortemente consigliato!) sviluppare il prototipo dell’intero progetto. Come detto sopra, nella Vostra squadra di sviluppo probabilmente avrete già delle persone che sono già a loro agio con la più grossa fetta del progetto, e non hanno problemi a fare l’analisi, prevedere i problemi e fare le stime. E’ quella residua parte del progetto che crea problemi e che può - nei casi più pessimistici - portare anche al fallimento dell’intero progetto. Ed è quella la parte che necessità, più dell’altra, la prototipazione, per portare dei chiarimenti. Se ritenuto necessario, si può comunque decidere (e come già detto: è fortemente consigliato) di fare il prototipo dell’intero progetto.
Questo discorso può essere portato ancora avanti: Non è applicabile solo al progetto nella sua totalità o alle sue parti “oscure” e ancora da definire, ma anche alle frazioni di queste parti assegnate a ogni singolo programmatore, per ogni “recinto” del progetto che gli è stato affidato. Ognuno deve essere in grado di mettere in piedi rapidamente un modello che lo aiuti a definire il percorso per lo sviluppo della sua parte del progetto.
Gli strumenti e i linguaggi che raccomandiamo di più per la prototipazione rapida sono:
L’ultimo punto richiede informazioni aggiuntive. Per elaborazione dei flussi di caratteri tra un processo e altro spesso si utilizza la venerata coppia sed + awk, che è una buona soluzione (e fa parte del nostro catalogo di corsi). Ma ci sono diversi linguaggi, già menzionati nel primo punto, che possono essere utilizzati al loro posto, con più o meno successo (possiamo, con certezza, dire: spesso è il “più”). Forse tra di Voi già avete dei programmatori che li padroneggianoi; Se è così, tanto meglio. Questi linguaggi sono tutti candidati validi per questo scopo. Però, secondo noi, il linguaggio che eccelle per questo tipo di compiti è Perl. Perl fa tutto quello che fanno sed e awk e anche molto di più, in modo più flessibile e potente. Le espressioni regolari di Perl sono proverbialmente il punto di riferimento per l’elaborazione dei testi, con la sintassi concisa e flessibile che meglio si presta per questo tipo di compiti. In più, pochi sono i linguaggi che hanno così tanti moduli aggiuntivi e installabili quanti ne ha Perl, moduli che estendono le funzionalità del linguaggio, e prevengono la necessità di dover avviare processi diversi anche per dei compiti più semplici. Fare prototipi con Perl diventa un processo straordinariamente facile e rapido.
Oltre a Perl, raccomandiamo anche i linguaggi Python, Common Lisp e Racket (questi ultimi due sono dialetti della stessa famiglia di Lisp, ognuno di questi che può essere più adatto dell’altro in un contesto particolare. Impararare tutti questi linguaggi (e sono tutti nel catalogo dei nostri corsi) Vi da una potenza indescrivibile, in quanto ogni piccolo prototipo può essere sviluppato in modo più veloce usando il linguaggio più appropriato. Common Lisp e anche Racket sono particolarmente adatti per le loro capacità di metaprogrammazione. Estendere il linguaggio Lisp è la stessa cosa come scrivere un programma in Lisp. Lisp permette di sviluppare programmi che poi sviluppano se stessi. Per questo è molto usato nel campo dell’intelligenza artificiale, ma non solo. In ogni tipo di progetto, Lisp può essere di grande aiuto.
Ci sono, potenzialmente anche altri linguaggi che si possono prestare bene per le prototipazione dei determinati progetti. Se, per esempio, il progetto definitivo deve, per scelte aziendali, essere sviluppato per la macchina virtuale Java, ha senso usare per prototipazione un linguaggio di scripting (o uno che può funzionare in modalità scripting) che gira sulla macchina virtuale Java. Quello può per esempio essere Jython (che è sempre Python, implementato per la Java VM), oppure Clojure, o Scala, JRuby, ecc.
Alla fine non di rado capita che un prototipo sviluppato, per esempio in Perl, Python, Scala, Clojure o altri (sono in realtà tutti linguaggi molto usati negli ambienti delle corporazioni, sistemi bancari, assicurazioni, ecc), soddisfi pienamente le esigenze del progetto, e invece di passare alla reimplementazione in un altro linguaggio, si mantiene il prototipo, facendolo evolvere. In quesi casi la seconda scrittura del codice sopra ipotizzata non serve più. Nulla di male in questo, anzi…
Il nostro corso sulla prototipazione rapida è organizzato in modo di essere strettamente correlato al nostro corso sull’Ingegneria del codice e al corso di sviluppo guidato dalle verifiche. Suggeriamo, perciò, di considerare di prenderli insieme.