Alkampfer's Place

Il blog di Gian Maria Ricci
posts - 659, comments - 871, trackbacks - 80

My Links

News

Gian Maria Ricci Mvp Logo CCSVI in Multiple Sclerosis

English Blog

Tag Cloud

Article Categories

Archives

Post Categories

Image Galleries

I miei siti

Siti utili

Architettura e mondo reale

Ho appena letto un bellissimo post di Roberto Messora, nel quale Roberto evidenzia come cercare la perfezione lo porta spesso ad essere meno produttivo e da li si parte su un discorso più ampio.

Con l'uscita di EF infatti MS ha "Sdoganato" gli orm, ora che si ha un ORM di casa Microsoft tutti si interrogano sul: è utile? può aiutarmi nel mio lavoro di tutti i giorni? etc, etc e contemporaneamente sempre più si parla di pattern, progettazione OO, e chi più ne ha più ne metta.

Il problema di questo interesse verso le nuove tecnologie è che si perdano di vista le necessità degli stakeholder, siano essi i committenti del progetto, ma più spesso anche gli utenti che andranno ad utilizzare il software stesso, con il rischio che il prodotto completo alla fine non soddifi le reali esigenze.

La domanda fondamentale che ogni sviluppatore/architetto/modellista software deve porsi, prima di decidere quale metologie adottare, è: "l'adozione delle tecnologie/pattern/principi  X Y Z può aiutarmi a scrivere software che soddisfi maggiormente gli stakeholder?". Il problema nasce quando la domanda in realtà è: "Usare le tecnologie/pattern/principi X Y Z mi fa scrivere software che soddisfi maggiormente me stesso che lo scrivo o altri sviluppatori che poi ci lavoreranno?".

Sarà che ho letto recentemente "Why software sucks", ma la sostanza è che noi sviluppatori/architetti/modellisti diamo al software pesi pesi differenti dai nostri stakeholder e tendiamo a dare maggiore enfasi a caratteristiche del codice che a conti fatti, non portano nessun beneficio osservabile per chi poi il software lo usa veramente. Il problema quindi è adottare una tecnologia solo quando ci aiuta a scrivere software migliore (per gli altri, non per noi stessi) e non invece solo perchè ci piace o perchè è di moda.

Un esempio classico è il Testing, argomento controverso e molto attuale. Il rischio è che si passi da una situazione in cui i progetti non hanno nemmeno un test automatizzato, ad una in cui si perde tempo solo per raggiungere 100% code coverage, oppure ancora peggio, si adottano architetture particolari con la sola ragione di rendere il software Testabile. Alla fine dei conti al cliente non importa nulla se gli facciamo vedere una schermata di NCover che mostra come ogni linea di codice sia stata testata. ;)

Alla fine tutto questo discorso può comunque essere riassunto da una bellissima frase di Raf a commento del post di Roberto.

"La conoscenza è "obbligatoria" per fare il mestiere, saper scegliere è quello che fa la differenza."

Da qui ne discende che è sempre bene cercare di aumentare sempre il più possibile le proprie conoscenze, ma cercare nel contempo di capire a fondo dove realmente applicarle e dove no.

Alk.

Print | posted on Monday, August 18, 2008 1:01 PM | Filed Under [ Generale ]

Feedback

Gravatar

# Re: Architettura e mondo reale

Devo dire che hai colto esattamente il senso del mio post (nato da un momento di frustrazione personale).
Ovvero hai posto l'accento al fatto _fondamentale_ che noi viviamo in universo interconnesso in cui sono spesso determinanti gli stakeholders (siano essi persone fisiche o vincoli di altro tipo).
l'esempio che citi, del lavoro in team in cui uno degli stakeholder è il team stesso e la facilità di utilizzo di un tool/tecnologia, calza a pennello.

saluti
Roberto
Gravatar

# re: Architettura e mondo reale

La maggiore enfasi alle caratteristiche del codice va data soprattutto per rendere lo stesso applicativo flessibile e mutabile per le future esigenze degli stakeholders: è un piccolo investimento.

Comunque condivido le vostre vedute: il saper scegliere è difficile e articolato specie in aziende in continua evoluzione come quelle attuali.

Saluti
Alfonso
8/18/2008 3:50 PM | Alfonso
Gravatar

# re: Architettura e mondo reale

Ma infatti le caratteristiche del codice sono importantissime. Il problema sorge quando si da troppa enfasi al codice, come ad esempio quando si cercano oggetti POCO ad ogni costo. L'importante è chiedersi onestamente se lo stakeholder ha veramente bisogno di una particolare tecnologia/pattern/etc, ma soprattutto è fondamentale cercare di prendere le scelte facendo un accurato peso tra le varie scelte e non scartare o adottare una soluzione solo per uno dei suoi aspetti.

alk.
8/18/2008 6:16 PM | Gian Maria
Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET