Ho scritto qui alcune riflessioni nate dall'ennesima rilettura di DDD: se qualcuno avesse voglia di discuterne...
Argomento complesso.
In primis mi verrebbe da dire forse il titolo che hai dato al post è un po' fuorviante nel senso che non mi sembra che nel contenuto si parli di architettura, bensì di contrapposizione fra tecnologia e principi e patterns, intendendo con la prima l'implementazione idiomatica dei secondi.
Più in generale mi verrebbe da dire che quando parli di cosa ti chiedono per l'erogazione dei corsi, in realtà non c'è niente di strano e nemmeno niente che sia solo tipico del mondo dell'informatica: è abbastanza diffuso l'atteggiamento mentale per cui è assume maggiore importanza il come piuttosto che il perchè di fronte alla necessità di raggiungere un "cosa".
un po' come un geometra che usa l'ultimissimo e figosissimo programma per il calcolo strutturale, cemento armato precompresso compreso, magari con tanto di certificazione della casa produttrice, vero mago del CAD, senza in verità sapere perchè quel programma offre quei risultati, senza sapere i principi della statica e della dinamica, o della chimica/fisica dei materiali non avendo nemmeno mai visto un diagramma di resistenza alla trazione del cemento o dell'acciaio.
Così il giorno che metterà dentro per puro caso un valore errato di input, un vincolo sbagliato, una misura sballata, non avrà minimamente sentore che il risultato finale sarà necessriamente una vaccata sesquipedale, nessun senso critico, e come potrebbe.
Così allo stesso modo MVVM al massimo diventa un modo furbo per sfruttare al massimo il motore di databinding di WPF/Silverlight, piuttosto che un modo ragionato di indirizzare la SoC e dare una strizzatina d'occhio alla testabilità e alla manutenibilità (resilienza) di un sistema, e quando dico ragionato, dico _profondamente_ ragionato.
In altre parole direi che forse un titolo più adatto al post sarebbe "Tecnologia contro tutti", nel senso che la tecnologia in quanto tale possiede una qualità attrattiva fenomenale, una sorta di Re Sole in un sistema in cui in realtà sono presenti moltissimi altri "dignitari di corte" che però non sono altrettanto affascinanti.
Personalmente ho smesso di definirmi "Software Architect" e ho cominciato a definirmi "Software Engineer" per un preciso motivo: posso pensare al mio lavoro come un'opera di ignegno legata ad aspetti tecnici e metodologici (occhio che non ho detto tecnologici, perchè la tecnologia è solo un aspetto della tecnica informatica), e fin qui siamo tutti d'accordo, ma per definirsi anche un architetto è necessario avere una comprensione approfondita anche di questioni che vanno al di là della tecnica, come l'interazione con gli stackeholders del sistema, il padroneggiare puntuali conoscenze di principi e pattern per poter coscienzosamente prendere decisioni corrette nell'interesse dei requisiti funzionali e non (e quindi in ultima analisi nell'interesse del committente).
L'architetto dunque è uno studioso dell'informatica, e necessariamente il suo è un percorso lungo, che se si limita alla tecnologia non può in alcun modo definirsi tale.
Come sottolineato dallo standard ISO l'architettura _NON_ è la descrizione della struttura componentistica di un sistema software e quindi chi esercita il lavoro di progettare e disegnare quest'ultima non può definirsi un architetto, bensì un tecnico progettista (e il cielo solo sa quanto c'è ancora bisogno di buoni tecnici progettisti ancor prima che buoni architetti...).
In definitiva è necessario chiamare le cose con il loro nome, perchè non c'è niente di peggio della confusione sui glossari. Purtroppo su questo fronte, in Italia almeno, intravedo (eufemismo) un malcostume che parte dal presupposto che le figure professionali si pesino dall'altisonanza del titolo e che quindi Architetto sia bene, aureo, scintillante e tecnico progettista sia male, scarso, disdicevole.
Con il risultato che fu mio zio, tecnico elettricista in una raffineria, anni fa a far notare all'ingegnere elettronico capo progetto, che se appena avessero avviato il nuovissimo impianto di telecontrollo dei vapori di raffinazione, sarebbe saltato tutto (senza che ovviamente nessuno glielo avesse chiesto in qualità di esperto tecnico, una delle n figure che avrebbe necessitato una installazione di quel tipo).
Per concludere, personalmente credo che i compiti che dovrebbe assolvere un Architetto sono tali e tanti che non possono realisticamente essere incarnati da un'unica persona, ma che purtroppo anche si volesse realizzare una task-force architetturale in un progetto ci troveremmo di fronte a troppi tecnologi e troppi pochi "scienziati" dell'informatica, con i primi che a torto si credono i secondi.
trovo in generale temibile un mondo dove si tende a pensare che il "come" porti con se in fondo anche il "perchè".
Andrea, non è un argomento, è un vaso di Pandora!!! :-D
Battuta a parte, ti riporto le mie considerazioni personali, non tanto sulle mie scelte personali (considerato che da 3-4 anni ho sbattuto la testa praticamente solo negli schemi architetturali e nella nostra SW factory, dovendo per forza tralasciare la formazione su molte delle nuove tecnologie emerse nel frattempo), quanto piuttosto su ciò che percepisco nelle realtà con cui ho a che fare.
Capire come funziona una tecnologia è fondamentale per poter utilizzare in modo evoluto (che poi spesso è ciò che fa la differenza nel risultato) tale tecnologia.In un team di sviluppo IMVHO ci dovrebbe essere almeno una persona che conosca a sufficienza almeno i "background" essenziali di ogni tecnologia adottata, in modo da avere la serenità di "spingere" in una direzione e, soprattutto, di poter capire cosa sta succedendo se le cose vanno male.
All'atto pratico, le tecnologie disponibili stanno vertiginosamente aumentando in quantità e complessità (essendo spesso l'ennesima evoluzione di una o più tecnologie di base) e l'approfondimento richiede sempre più tempo, che va "ammortizzato". Nonostante, come penso tu sappia, concordo pienamente sull'enorme vantaggio portato da un know-how approfondito, sappiamo bene che in questo periodo in genere il tempo disponibile è molto poco, tendente al 24x7 di lavoro :-), il bugdet, sia economico che in termini di disponibilità di tecnici... ah, ah! E quindi si finisce per rincorrere, cercando di spremere, nel minor tempo possibile, il più possibile da una tecnologia col minor investimento possibile. E "possibile" a volte assume una forma pericolosa.
Insomma, l'approccio non è più quello di approcciare una soluzione architetturale, fare delle prove per capire, cercare tecnologie ed esperienze che adottino quella soluzione, far crescere la relativa conoscenza con workshop e corsi per poi finalmente applicare con un alto livello di qualità quella soluzione, ma diventa un "F5-First" :-) per riuscire a buttare la palla in campo (con spettatori paganti) il prima possibile e poi rincorrere la palla cercando di risolvere i problemi derivanti dalle lacune di conoscenza. Non è retorica, non sto (direttamente) criticando: la crisi c'è, un (bel) po' ce la siamo (intendendo il settore IT) anche cercata, ed adesso "tutti dietro ad un pallone in uno sciame" cercando di battere il fattore soldi/tempo.
Software factories...
Purtroppo non ho ben compreso la tua citazione delle SW factories, ma anche su questo argomento mi sto sempre più rendendo conto di quanto molta gente adori con ostinazione farsi le del male per poi sentirle piangere.Le (automated) SW factories sono IMVHO lo strumento che potrebbe traghettare l'IT "occidentale" fuori dalla crisi, perché é know-how applicato allo stato puro, difficilmente "copiabile" a basso costo.
Una factory, per essere veramente "potente", richiede un modello architetturale estremamente "pulito", ogni "furbata", ogni workaround che si tenta di inserire viene risputato sui denti al triplo della velocità, ergo la struttura architetturale di codice prodotto da una factory progettata IMHO "bene" è molto pulita.
Il codice generato da una factory, molto difficilmente contiene bugs e se li contiene, significa che li conterrebbe anche se non si fosse adottata la factory (spero sia evidente il motivo).
Il codice generato da una factory ha costo di produzione (non di progettazione) pressoché nullo.
Ad ogni cambio di tecnologia su una specifica soluzione architetturale, l'impatto su tutti i prodotti creati con la factory è enormente ridotto, perché, grazie alla corretta separazione delle responsabilità che ho imparato ad apprezzare da te, è quasi sufficiente modificare la factory e rigenerare quelle parti di codice.
Le software factories sono ciò che permetterebbe in modo naturale di riportare il centro dell'attenzione sull'architettura, relegando "l'implementazione" in un secondo piano, ma, ahimè, mi rendo conto sempre di più che probabilmente non decolleranno mai, con grave danno per il nostro settore, per diversi motivi tra cui:
Ma forse sto solo prendendo un abbaglio... :-)
Hai perfettamente ragione quando affermi che "siamo un settore artigianale", e ciò dipende a mio avviso dal fatto che non tutti sono disposti a migliorarsi professionalmente per comprendere "il perchè" piuttosto del "come".
Molti sanno come impiantare un sito Web MVC; pochi conoscono però il pattern, ancora meno sanno che quel pattern si chiama "Model 2" e non MVC; qualcuno addirittura non conosce nemmeno il significato dell'acronimo, ma tutti però ci spacciamo come architetti poichè, come affermi giustamente, "architetto" è una buzzworld figa da mettere sul bigliettino da visita o nella firma elettronica della mail.
Questo è solo un esempio, ma ne potrei citare molti altri.Come sicuramente ben sai, esistono realtà IT dove ad una applicazione è richiesto solo che funzioni; non è minimamente richiesto e non si ha nemmeno la consapevolezza dell'importanza di avere software modulare che evolve nel tempo con il minimo impatto sulle funzionalità esistenti.
La qualità del prodotto software è una caratteristica scarsamente apprezzata, anche dagli stessi addetti ai lavori; ciò che conta è consegnare la versione 1 funzionante, per poter fatturare, non importa come viene sviluppata.
Qesto è un settore dove "i fiorellini" non sono richiesti.
Quindi, altro che TDD e sviluppo incrementale...
Vorrei puntualizzare una cosa però: non diamoci addosso di cilicio puntando il dito sul fatto che il nostro settore è pieno di gente approssimativa come se fossimo l'unica pecora nera del panorama professionale.
è così d'appertutto, con un'unica differenza, essendo il nostro settore molto più giovane, non si è ancora dotato degli anticorpi che non possono essere altro che la normativa.
io conosco i settori dell'ingegneria, e posso affermare che gli standard internazionali sono prsi in seria considerazione, tanto che le leggi in materia fanno proprio riferimento a loro. non si può verniciare un mobile tanto per verniciarlo, è necessario seguire delle regole precise che assicurino la non tossicità, la durabilità, senza contare tutte le operazioni accessorie al processo di verniciatura in termini di materiali e macchinari (manutenzione, stoccaggio, ecc.).
nel nostro caso la normativa quasi non esiste e se esiste (come nel caso del trattamento dei dati), molto spesso non è conosciuta dai committenti ed i fornitori si guardano bene dal ricordarla (meno cose ci sono in ballo in un contratto, più competitiva è l'offerta e meno cazzi ci sono da smazzarsi).
perchè le software factory non sono ancora decollate come standard strumentale? perchè non c'è alcun vantaggio tangibile ad averle, vantaggio globale intendo, non solo quello tecnico.
a mio avviso l'unico modo che vedo perchè certe metodologie di approccio alle soluzioni software e al riconoscimento delle figure professionali dell'ICT è che le esigenze dei committenti comincino ad "elevarsi" ad un altro livello di coscienza. i committenti dovrebbero cominciare a richiedere come requisiti minimi tutta una serie di aspetti che oggi non sanno nemmeno che potrebbero chiedere. ad esempio se fossi un committente non farei mai un contratto in cui si parla solo di sviluppo, ma al fornitore imporrei anche di default una politica "tutto compreso" per minimo 3 anni sulla manutenzione della soluzione stessa. allora la manutenibilità (a basso costo per il fornitore) diverrebbe un requisito fondamentale all'interno dell'ALM (e quindi di rimando anche la testabilità perchè è mio interesse fornire un prodotto che abbia bassa probabilità di fallimento, perchè sono io che ci devo mettere le mani).
insomma, è brutto da dire, ma è necessario costringere il fornitore ad ingegnarsi per mantenere gli stessi margini di guadagno al crescere delle esigenze rimanendo competitivi sul mercato. ad oggi la stragrande maggioranza dei committenti non ha le basi per poter imporre certi paletti contrattuali ai fornitori.
quindi o si fa cultura verso i committenti o si prova a introdurre una normativa basata sugli standard internazionali che specifichi i requisiti minimi di legge di una soluzione software.
il vero problema è che non scorgo alcun serio movimento di unificazione metodologica e "filosofica" che provenga dal nostro settore in questo senso. come se in fondo alla maggior parte di coloro che vivono di IT tutto questo non importi.
Come già detto da Mario l'argomento è veramente vasto.
Se non ricordo male (ma non trovo il link) Martin Fowler ne aveva parlato in un suo post, evidenziando quanto è più importante conoscere i principi e i pattern piuttosto che la tecnologia con cui applicarli (linguaggi, framework ecc...). I framework passano i principi restano. (se qualcuno trova il link me lo può inviare? thx)
Voglio aggiungere due opinioni personali alla discussione:
1) Le aziende non chiedono corsi sulle metodologie perchè puntano al profitto a breve termine, "chissenefrega se non so cosa significa MVC a me interessa usarlo per finire presto l'applicazione e fatturare". Questo punto però mi ha stufato. IMHO è ora di smetterla di piangerci addosso, se noi siamo maniaci delle "cose fatte bene" facciamole senza lamentarci di chi le fa male....anche se chi le fa male fa molti più soldi noi :-)
2) La mia impressione è che questo problema sia più evidente tra gli sviluppatori Microsoft. Nel mondo OpenSource è molto più facile trovare sviluppatori che sono meno legati al linguaggio/framework e sono più abituati a cambiare a seconda delle esigenze avendo però saldi i concetti base di cui sopra.
Sarebbe bello parlarne intorno ad un tavolo...
"Sarebbe bello parlarne intorno ad un tavolo..."
Verissimo, la problematica sollevata da Andrea é di quelle che mi farebbe molto piacere vedere in evidenza in questa "epoca" del mercato IT, ma anche solo il numero di partecipanti a questo 3D fa capire che basterebbe un tavolino da bar, ed i vari impegni ridurrebbero inevitabilmente il numero dei partecipanti. :-(
Certo magari una LiveMettingata "open"... ;-)
La butto lì (anche se mi sa che lì rimarrà:-D):
Serve però qualcuno con un account LiveMeeting, che io ovviamente non ho, oppure dovremmo optare per qualche altro strumento simile.
sorry, lunedi e martedi prox io non potrei: c'è il concerto degli Afterhours :-) Più in generale, temo che un preavviso di meno di 2 settimana sia "killer" per una "audience potenziale" composta da persone che fanno del proprio "overbooking" una sciagurata strategia professionale :-/
Analogamente a quanto avvenuto per l'Elicitando Camp, io potrei mettere a disposizione la sede MD per una combo "chiacchiere&pizzata": non è grande, ma se non dovessimo essere più di una dozzina potrebbe essere sufficiente. Eventualmente, potremmo cercare di allestire anche un accesso LiveMeeting (o similare) per chi non potesse essere presente fisicamente anche se, memore proprio del succitato camp, la pizzata è tra le parti migliori della discussione
ema, in sintesi:
ciò premesso, trovo indicativo del livello del nostro settore il fatto che:
potrei continuare. Come definire tutto ciò? Beh, io la mia definizione l'ho data: "artigianato, con un rifiuto *totale* di ciò che invece l'ingegneria sta provando a distillare, definire, formalizzare, condividere". E trovo *ri-di-co-lo* che questo rifiuto venga tipicamente da individui che questa ingegneria non la conoscono perché non hanno nemmeno provato a studiarla prima di criticarla: quante persone conosci che abbiano studiato e provato ad applicare ISO42010? E/o approcciare una analisi seguendo ISO9126? E perché non lo hanno fatto?
'nzomma, IMHO c'è un rifiuto aprioristico, e mi chiedo: può definirsi "tecnico" un individuo che nega o afferma tesi senza conoscere sperimentalmente il soggetto della propria negazione/affermazione? Chiamo a testimoniare il Sig. Galileo :-)
"composta da persone che fanno del proprio "overbooking" una sciagurata strategia professionale"
In effetti ho anche dato per scontato che fosse purtroppo così, ma in effetti magari poi non lo è... (altro argomeno MOLTO caldo su cui sarebbe il caso di darci, noi "itagliani", una "regolata").Io preferirei decisamente un incontro (fisico o virtuale) in orario lavorativo.
Io mi ero trovato bene creando un sondaggio in cui ognuno doveva indicare le proposte data/ora NON disponibili per l'incontro. E' emerso automaticamente il primo spazio disponibile per tutti (o quantomeno per il maggior numero di possibili partecipanti).
"io potrei mettere a disposizione la sede MD"
Ottimo. Per quel che riguarda il me medesimo, organizzandolo nella sede MD di sera potrei partecipare solo da remoto (che va cmq benissimo), mentre in orario d'ufficio, impegni permettendo, magari anche di persona.
Ciao a tutti, mi "intrufolo" in una discussione mooolto interessante :)
Come già anticipato da tutti è un argomento davvero molto vasto e se ne potrebbe parlare per ore ed ore....
Vorrei partire con due righe di quella che è stata la mia esperienza personale e di come ho vissuto questo "conflitto". Nascendo principalmente come tecnico (partito post-diploma) ho sempre dato per scontato che la parte tecnica fosse la più rilevante, quindi mi sono sempre buttato a capofitto (ai tempo del buon e vecchio ASP3.0 eh eh eh). Poi cambiando lavoro (e iniziando a lavorare con .Net) ho incontrato persone veramente molto in gamba che avevano sempre una marcia in più.... Un giorno mentre lottavo, come facevo ormai da un paio di anni, contro la "persistenza di oggetti" (all'epoca anche la mia terminologia era davvero molto povera) qualcuno mi ha messo di fronte uno strumenti che da lì in poi sarebbe diventato il mio pane quotidiano : NHibernate. Lì si è aperto un mondo ed ho inziato a navigare per la rete non solo alla ricerca di esempi di codice...ma volevo capire un tutto quello che ci stava dietro. Mi sono così imbattuto in due cose che hanno segnato il mio processo di apprendimento in maniera molto forte : Ugidotnet e NSK :).
Da lì ho iniziato a studiare da solo (vedi "Domain Design Driven" ddi Evans, "POEEA" di Fowler, "Architecting Applications for the Enterprise" di Andrea e Dino...etc etc) frequentare diversi corsi e personalmente ho rivalutato decisamente il mio approccio al lavoro.
Dal mio punto di vista (premetto che mi reputo ancora un vero inesperto in materia di architetture, ma ci sto lavorando :)) quello che è difficile conciliare l'attività di training e l'operatività di tutti i giorni. Secondo me è molto più semplice ritagliarsi del tempo per vedere una tecnologia (a livello superficiale ovviamente) rispetto a comprendere pattern come IoC, MVC, MVP, Unit Of Work etc etc....o il funzionamento completo di un ORM (come accennavate anche sopra, colpa forse i questo del potere del "drag&drop").
Inoltre è davvero complicato trovare qualcuno con cui condividere queste problematiche. Anche quello di cui parlava Andrea, ovvero standard ISO per definizione di architetto etc etc, mi sono imbattuto la prima volta con tutto questo proprio in una sua sessione e poi leggendo il suo libro...ma per quanto riguarda i confronti con altre figure professionali nel quotidiano....zero assoluto! Quindi a volte è difficile per uno che magari non conosce i canali "giusti" riuscire a trovare spunti interessanti (diverse volte ho avuto a che fare con tecnici che non fanno approfondimento tramite communities, forum etc etc ma si limitano a stare nel loro contesto e a cercare qua e là giusto le due righe di codice che servono per far partire "a calci" un applicazione che si deve consegnare al volo)
Nella mia esperienza quotidiana è davvero difficile fare capire a chi di dovere (in pratica il proprio capo :)) l'importanza di software ben scritto e progettato...ma penso che questo sia noto a tutti.
Cito una sessione di Andrea al WPC di quest'anno : "l'importanza di conoscere è senza pari, perchè probabilmente non ha senso usare DDD in ogni caso, ma bisogna conoscere le alternative per poter decidere la strategia migliore per il cliente in quella circostanza, in quanto noi siamo qui per dare un servizio e deve essere il migliore possibile al netto di elucubrazioni mentali da tenico" (non ricordo le parole esatte ma il senso dovrebbe essere questo...Andrea perdonami e correggimi se mi sono sbagliato!!!).
Mi piacerebbe moltissimo partecipare a questo confronto (ed ad altre attività di questo tipo), perchè personalmente sono un pò stufo di queste metodologie artigianali (ammetto che in questo periodo la mia vita lavorativa lascia un pò a desiderare e questo influenza sicuramente la visione negativa che ho in questi giorni eh eh eh) e mi piacerebbe poter lavorare con un ottica molto più "professionale".
Danghiu e ciao a tutti, Andrea!
PS: scusate il tono "fiabesco da racconto intorno al fuoco" della mia esperienza personale...ma ho questo vizio di "forma" :)