E’ passato un bel po’ di tempo da quando ho iniziato a fare questo lavoro, e ancora di più da quando ho iniziato a smanettare con i computer. Ho lavorato negli anni a tanti progetti, molti non me li ricordo nemmeno, ricoprendo quasi tutti i ruoli possibili, e in molti contesti, sia italiani che internazionali.
Quindi quando Giovanni mi ha chiesto di scrivere un articolo per i 20 anni di MokaByte, ne ho approfittato per fare un po’ il “punto” e mettere nero su bianco qualche considerazione che mi girava nella testa già da un po’.
Mi definisco un Software Architect per specificare che, oltre ad essere un sviluppatore, possiedo una visione architetturale del software, cosa che in realtà ho avuto sin dall’inizio. Anzi mi sono sempre trovato molto a disagio quando ho dovuto lavorare in situazioni in cui tutta l’architettura non mi era perfettamente chiara. In ogni caso ovviamente, come tutti, ho dovuto fare i miei bravi errori per capire un bel po’ di cose.
In effetti, è difficile “imparare” ad essere un architetto, anzi non è semplice nemmeno definire cosa sia una “architettura”. Una definizione che mi piace è [1]:
“The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both”
Ovvero, con un buon grado di approssimazione, potremmo definire un Software Architect come qualcuno che è in grado di pensare ad un sistema software in termini di componenti che hanno relazioni tra di loro e delle loro proprietà.
Chiaramente, oltre alla comprensione, ad un architetto è richiesta la progettazione di tali sistemi, una skill che, nonostante i job title, non sono in tanti a possedere. Per questo in passato l’uso di alcune tecnologie si è posto in modo esplicito il fatto di limitare le possibilità di disegno dei sistemi, principalmente per evitare errori (promuovendo best-practices) e portare a standardizzazione degli artefatti prodotti, con evidenti vantaggi in termini di gestione (e per i vendor di software). Un esempio che conosco molto bene di questo approccio è JEE (Java Enterprise Edition).
Credo che sia ormai universalmente riconosciuto che le prime versioni delle specifiche JEE fossero decisamente sovra-ingegnerizzate, cosa che ha portato infatti allo sviluppo di framework alternativi (per esempio Spring, Hibernate) che a loro volta hanno influenzato versioni successive delle specifiche. Questo tipo di approccio presenta comunque degli innegabili vantaggi ma impone, in modo più o meno esplicito, dei precisi paradigmi architetturali che non sono necessariamente adatti ad ogni contesto (si pensi alla difficoltà di usare JEE per applicazioni massicciamente scalabili).
Negli ultimi anni per queste (e altre) ragioni, dopo avere lavorato per qualche lustro quasi sempre su JEE, mi sono spostato su tecnologie JavaScript, in particolare NodeJS.
La cosa che mi ha attirato, non è tanto il linguaggio (già conoscevo JavaScript, anche se, come molti, lo valutavo principalmente un “linguaggio per fare i casini sul browser”[2]) quanto la filosofia che sta sotto, che altro non è che l’unica cosa che è rimasta veramente costante nel mio lavoro dai tempi dell’università, cioè Unix[3].
E’ strano come qualcosa che, potremmo dire, “va di moda” o è addirittura considerato “hipster” (qualunque cosa voglia dire) affondi le radici concettuali in un passato remoto. Molto remoto, considerando i tempi dell’IT.
In sintesi, la Unix Philosophy dice [2]:
- “Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.”
- Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
- Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
Tutto questo ha decretato negli anni il successo di Unix che ora troviamo, in varie forme, oltre che nella stragrande maggiorana dei server, anche in molti dispositivi embedded e in molti smartphone. Probabilmente, anche se non lo sapete o non sembra, pure nel vostro mediaplayer, nel vostro NAS, nella vostra TV, nel vostro router, nella vostra macchinetta del caffè [3]
Notate che la Unix Philosophy esprime dei principi architetturali generali, che NodeJS fa propri con l’implementazione del sistema dei moduli e con gli stream, una feature potentissima (presente per la verità anche in altri runtime e linguaggi) che permette di creare delle pipeline, stile appunto “pipe” unix. In pratica è possibile scrivere software sotto forma di moduli node e comporli alla necessità come se fossero comandi di una shell.
Un’altra cosa che oggi va molto in auge, è la programmazione funzionale. Anche qui, non esattamente un’idea nuova[4], ricordo benissimo quanto mi colpì il LISP quando lo studiai all’esame di linguaggi (erano gli anni 90). Qualche anno fa notai l’entusiasmo sulla programmazione funzionale proprio perché mi resi conto che in realtà non c’era nulla di nuovo. Incontravo persone che mi parlavano di “closure” come se fosse una nuova magia informatica, mentre è qualcosa che è stato pensato e implementato quasi 50 anni fa.
Per non parlare poi di MVC, oggi utilizzato come base concettuale di decine di framework JS, il cui paper originale risale al 1978 [4].
Quindi in pratica, dopo più di 3 lustri che faccio questo mestiere, la cosa di cui mi rendo conto è che…più o meno non ho imparato nulla. O meglio, ho capito che le cose che pensavo e conoscevo sin dall’inizio erano corrette, solo che non avevo l’esperienza e la sicurezza per esserne sicuro fino in fondo. Alla fine in sintesi sono arrivato a tecnologie “nuove” che però si basano su idee “vecchie”…ma giuste. Per questo, oggi mi diverto ancora a programmare come quando avevo 15 anni, e ancora oggi programmare è una delle cose che riesco a fare per ore senza stancarmi.
Poi ho vissuto abbastanza per vedere Microsoft mettere bash su Windows, e mi basta.
“Siediti lungo la riva del fiume e aspetta, prima o poi vedrai passare il cadavere del tuo nemico.” (proverbio cinese)
[1] Il titolo è estratto da “Il Gattopardo”, Giuseppe Tomasi di Lampedusa
[2] Cosa comunque vera, però oggi si possono fare casini molto più complicati.
[3] Una delle prime cose che ho dovuto fare per lavoro è cambiare la configurazione di un server usando ssh + vi
[4] LISP è del 1958
Marco Piraccini è nato a Cesena il 09/10/1975. E‘ laureato in Ingegneria Informatica presso la facoltà di Bologna con una tesi sull‘assessment della maturità del processo di testing e
in Fisica Computazionale presso la facoltà di Udine con una tesi sull‘uso di GRID per le simulazioni Monte Carlo (nell‘ambito di un esperimento di astrofisica).
Attualmente lavora come Software Architect per una società di consulenza. Il suo Blog è disponibile al seguente indirizzo: http://darkav.blogspot.com/