Da un corso recentemente è saltata fuori una domanda, quasi un'obiezione per la verità, sull'uso promiscuo da me fatto dei termini sviluppatore e architetto. La domanda diceva più o meno “Ma sviluppatore e architetto sono la stessa cosa? Chi fa cosa?”.
Sviluppatore e architetto non sono chiaramente la stessa cosa, ma hanno radici comuni. Eccome se ce l’hanno. Un po' come classe derivata e classe base. Chi è la base e chi il derivato? Booh, dipende se vedete il mondo bottom-up o top-down o al più se credete che sia nato prima l’uovo o la gallina.
In genere, almeno nei mondi di questa dimensione, si nasce sviluppatori e si diventa architetti man mano che l’esperienza cresce e con essa le esigenze della società/scenario in cui si lavora. Per fortuna non hanno ancora inventato corsi di laurea brevi in architettura del software. [N.d.A:: se ne conoscete, vi prego lasciatemi vivere nella mia falsa certezza.]
Io non passo per uno che abbia una gran simpatia per i puristi dell’architettura che ragionano solo se c’è un pattern o un modello ufficialmente censito da qualche riconosciuta autorità morale. Nemmeno sono uno che si vergogna di una soluzione se questa soddisfa, funziona come si vuole, ma non è architetturalmente pura e non ha un framework auto-generante di dietro.
Ma non proprio non riesco ad immaginarmi un architetto software che non sia stato sviluppatore almeno in una qualche vita precedente.
Dunque, gli architetti scrivono codice? Talvolta sì. Certo l’architetto non sarà mai capace di trovare il trucchetto che risolve un problema JavaScript che si manifesta nelle notti di luna piena sui browser Safari. E capisco che non sia interessato ai dettagli dell’implementazione di un serializzatore .NET/JSON. Ma un architetto è in grado di percepire l’importanza di usare JSON nello scambio dati tra client e server AJAX.
Nella fattispecie [chiedo scusa ai non-AJAX ma dato il mio focus del momento è il solo esempio che mi viene in un tempo ragionevole], sul client serve un oggetto JavaScript per una veloce manipolazione dei dati. Sul server si hanno oggetti .NET. Perché diavolo dovrei usare, che so, XML? Portato XML sul client dovrei comunque crearmi un oggetto JavaScript e visto che i browser hanno un supporto nativo (da una vita) per JSON e che sul server serializzare su XML o su JSON non mi cambia la vita, opto per JSON.
Che tipo di ragionamento vi pare questo? Da sviluppatore o da architetto?
Uno sviluppatore sarà ragionevolmente influenzato dai suoi precedenti e vi dirà magari che in fondo XML va bene, che un parser JavaScript si può creare, che ne esistono di gratuiti, che in fondo non cambia niente, che si può aggiustare tutto.
Un’architetto avrà una visione più ampia del problema e delle soluzioni. E magari ignorando le librerie free/open-source o gli ultimi ritrovati della scienza del Tip&Trick vedrà il problema nella sua essenza—come mamma lo ha fatto.
Ora il punto chiave. Dunque, se il ragionamento su JSON e XML è da architetto, un architetto ne sa di codice? Capperi se ne sa.
Per esempio, un architetto che ragiona come sopra sa cose-di-codice come:
-
I browser hanno un supporto nativo per JSON tramite la storica funzione eval;
-
La serializzazione di un oggetto .NET è personalizzabile oltre ogni limite;
-
In JavaScript, si programma con oggetti;
-
In JavaScript, non c’è un parser XML;
In più un architetto riesce a vedere (meglio di uno sviluppatore) che avere oggetti gemelli sul server e sul client è una bella cosa—non solo elegante. Che non ci sono colli di bottiglia. Che il disegno complessivo appare logico e ben bilanciato.
-
Non significa necessariamente che un architetto debba necessariamente essere stato uno sviluppatore;
-
Non significa necessariamente che tutti gli sviluppatori diventeranno architetti con uno scatto automatico di carriera al compimento del 40.mo genetliaco;
-
Non significa necessariamente che architetti e sviluppatori debbano essere entità fisiche disgiunte; possono essere la stessa persona;
-
Non significa necessariamente che anche quando sono persone diverse debbano lavorare in ali distinte del castello;
-
Non significa che l’architetto è l’intellighenzia e la classe dirigente e lo sviluppatore solo manovalanza più o meno specializzata;
Architetto e sviluppatore sono due facce della stessa medaglia. L’architetto disegna il codice ma i suoi disegni sono progetti, non schizzi di blocchi UML. Altrimenti sarebbe un designer di interni software. Un progetto ha in sé calcoli, scelte, numeri, modelli, conoscenza applicata, e ovviamente idee.
PS1:: I migliori architetti software che conosco (compresa una software legend), migliori perché riconosciuti dai clienti e da Microsoft, sono stati sviluppatori e non in una vita precedente, ma almeno fino a cinque/sei anni fa. Poi hanno seguito il loro istinto e si sono specializzati in ruoli dove il livello di astrazione richiesto è un po’ più alto del tip&trick ma ugualmente e inevitabilmente permeato di software scritto, testato, eseguito, ed ottimizzato.
Per finire, qualche citazione su cosa fanno gli architetti di alcuni dei prodotti che usiamo tutti i giorni:
PS2:: non ho mai visto architetti software nell'esercizio delle loro funzioni primarie dilettarsi con scadenze di progetti, gestione risorse umane, tempistica, milestone. Il project manager è altro da un architetto software. E beate le aziende che riescono a creare punti di incontro tra le due figure.
posted @ martedì 24 aprile 2007 10.35