MesBlog

Thinking in sharp architectures
posts - 179, comments - 436, trackbacks - 150

Best practices and real world

Stamattina mi sono trovato di fronte ad una situazione che ultimamente affronto un po' troppo spesso, impiegando circa un'ora di letture fra blog e articoli. In particolare ho voluto affrontare (per l'ennesima volta) una questione "teorica" riguardo lo unit testing: l'utilizzo di un framework di mock.

Non voglio in questa sede dilungarmi sul fatto che esistano diversi tipi di oggetti simulati secondo la tradizionale definizione di Fowler (dummy, fake, stub, mock), bensì esprimere tutto il mio personale rammarico circa alcuni mie atteggiamenti da ingegnere riguardo lo sviluppo software.

In pratica mi sto rendendo conto che la mia produttività sta scemando nel tempo perchè a rischio perfezionismo. La mia forma mentis è quella dell'ingegneria, e fino a qualche mese fa non mi rendevo conto di quanto questa sia pervasiva nella mia vita professionale. Non che sia un male intendiamoci, però credo che ci debba essere anche un limite.

Il problema che comincio a intravedere è che tendo troppo spesso a ritrovarmi insoddisfatto di fronte ad alcune soluzioni implementative che realizzo, eccedendo nel refactoring o addirittura nella sovraingegnerizzazione progettuale.

L'esempio lampante di quanto sto dicendo lo sto vivendo proprio in questo ultimo periodo, lavorando su un progetto che fa uso dell'Entity Framework. Quest'ultimo soffre di errori di progettazione abbastanza evidenti a livello architetturale per essere un ORM, il suo lavoro lo fa per carità, ma a costo di alcune magagne fra cui l'ormai famigerata Persistence Ignorance per quanto riguarda le classi che fanno parte del Domain Model.

Ebbene, ho provato per diversi giorni ad analizzare da ogni punto di vista la questione cercando in tutti i modi di trovare una soluzione elegante che facesse il paio con alcune pratiche di buona implementazione architetturale che sto cercando di raggiungere, con risultati del tutto deludenti (insomma la cosa per come è fatto l'EF è impossibile, punto).

Ma quello che a prima vista poteva essere scambiato come il cercare di combattere contro un framework nato e pensato male, battaglia se vogliamo del tutto legittima, stamattina ho capito essere altro.

Nel mondo reale le soluzioni software devono essere rilasciate nei tempi e nei costi progettati, devono aderire a precisi requisiti (funzionali e non), fine del discorso.

Impiegare per l'ennesima volta un'ora del mio tempo per derimere un dubbio stucchevole circa la differenza di utilizzo fra mock e stub in uno unit test, non va in alcun modo in questa direzione.

Non voglio essere frainteso: non sto dicendo che non sia importante capire la differenza fra testare lo stato (con uno stub) o testare il comportamento/interazione (con un mock). Sto affermando che esiste una netta differenza fra me e Martin Fowler (maddai...), esattamente come esiste la differenza fra un premio nobel per la fisica ed un ingegnere che deve progettare e costruire un ponte strallato.

Detto in termini meno metaforici, non devo perdere di vista che l'obiettivo è quello di dotare la mia soluzione software di una suite di test robusta, ma che in nessun caso debba essere causa, di una inutile ricerca della perfezione semantico-semiotica circa l'arte teoretica dello unit testing.

Questo al momento è il maggiore limite che sto notando nella mia formazione unievrsitaria, che se da una parte mi ha dato la capacità di affrontare le questioni professionali con metodo, dall'altra, non mi ha affatto insegnato la differenza che c'è fra la teoria e la pratica, e questo per colpa della natura stessa dell'università italiana, che anche ad ingegneria difetta pesantemente di pragmatismo.

In definitiva sto facedo training autogeno, per combattere l'"ansia da prestazione" circa il confronto fra ciò che sto producendo e l'empireo degli archetipi dello sviluppo software.

Print | posted on Friday, August 15, 2008 10:48 AM |

Feedback

Gravatar

# re: Best practices and real world

>Nel mondo reale le soluzioni software devono essere rilasciate nei tempi e nei costi progettati,
>devono aderire a precisi requisiti (funzionali e non), fine del discorso

Applausi! :)
8/15/2008 12:44 PM | Raffaele Rialdi
Gravatar

# Re: Best practices and real world

Luca, non è esattamente quello che intendevo nel mio post.<br />Volevo focalizzare l'attenzione sulla netta differenza che esiste fra un'approccio teoretico ed un approccio di produzione.<br />Nessuno si sognerebbe mai di confrontare il lavoro di Rubbia con quello di un capo ingegnere in una qualsiasi centrale nucleare, ma in effetti lavorano nello stesso identico campo.<br />Lo stesso credo sebba essere fatto nel mondo dell'informatica, ovvero capire la natura teoretica dei lavori di Fowler ed Evans (per fare due esempi riconosciuti), senza perdere di vista la professione che esercitiamo. <br />Scegliere l'EF al posto di un altro ORM non è una questione che può essere discussa in termini di teoria delle architetture sw, altrimenti non si porrebbe nemmeno il problema: la versione 1.0 di EF non andrebbe utilizzata, sarebbe tecnicamente molto meglio lavorare con NHibernate. Ma non è questo il punto. Il punto è che intorno ad un qualsiasi _prodotto_ software ci sono delle dinamiche che vanno al di là del solo studio e della sola ricerca. Ci sono alcuni vincoli funzionali e non (i famosi requisiti) che _non_ dipendono in alcun modo dalle best practices, ma derivano da considerazioni di tutt'altro tipo (e per fortuna che è così, sarebbe deleterio ricondurre tutto solo a questioni di tipo tecnico).<br />Utilizzare l'EF può risultare strategico in un'ottica di medio-lungo periodo da un punto di vista commerciale, considerazione del tutto legittima (siamo aziende in ultima istanza) e che nulla ha a che fare con le questioni tecniche.<br />In questo scenario ostinarsi come a volte faccio io, nella ricerca e nello studio, (attenzione ho scritto "ostinarsi", che ha un ben preciso significato nella nostra lingua), è controproducente rispetto al lavoro che svolgo, anzi va contro alcune funzioni specifiche del mio lavoro, che sono tutte volte al completamento copn successo del progetto che mi è stato assegnato.<br />Il fulcro di tutto sta proprio nel termine "successo" che non può rimanere a livello professionale un'accezione soggettiva, bensì deve essere misurabile oggettivamente. la misura del successo è dato da parametri come il rispetto dei budget di tempi e costi, l'aderenza a determinati SLA, ecc., ecc.. Queste metriche sono legate anche se vogliamo a parametri quali la manutenibilità, la scalabilità, ecc., tutti legati all'architettura della soluzione e alle sue implementazioni tecniche, ma non sono gli unici parametri.<br />nel nostro lavoro si ha maggior successo a mio avviso se rispetto i budget e il livello di manutenibilità e scalaibilità si aggira circa all'80% dell'ideale, piuttosto che raggiungere obiettivi tecnici al 100% del loro potenziale e sforare i suddetti budget. Ovviamente il tutto a parità di funzionalità realizzate.<br />Quindi se con EF vi sono delle limitazioni. la decisione conseguente deve essere quella secondo la quale il Domain Model (che sta al centro dell'architettura) _è_ System.Data.Objects, senza ostinarsi a cercare una sovraingegnerizzazione che porti ad avere un DM POCO perchè così riportano alcuni testi di teoria dell'ingegneria del sw.<br />saluti<br />Roberto
Gravatar

# re: Best practices and real world

>senza ostinarsi a cercare una sovraingegnerizzazione che porti ad avere un DM POCO
>perchè così riportano alcuni testi di teoria dell'ingegneria del sw

Mi sento un po' meno solo :-D
8/15/2008 5:24 PM | Raffaele Rialdi
Gravatar

# re: Best practices and real world

> Non sarei così fiscale.

Sono d'accordo, visto che appunto il problema e' che leggibilita', come eleganza (e per me sono sinonimi se eleganza e' riferita a codice), sono proprieta' "qualitative" che mettere giu' in termini di metriche e' piuttosto "complicato".

In generale, il fatto e' che o siamo ingegneri (tecnici, professionisti, come vi pare) o non lo siamo. Se dici "misurare" non e' lo stesso di "chiedo un parere" o "mi dice lui quello che non ha capito".

Il punto interessante, qui, e' proprio che individuare misure, metriche e indici, soprattutto quelli di natura piu' qualititativi, e' di per se' un intero capitolo dell'ingegneria del software: pianificazione e stime.

-LV
8/17/2008 5:23 PM | LudovicoVan
Gravatar

# Re: Best practices and real world

Luca:
"lo stesso Entity Framework, NHibernate, POCO ... sono argomenti tecnologici , il fatto è che _disegno_ della applicazione parte dal basso, dai dettagli del codice che si scrive e si modifica tutti i giorni e sono questi secondi ad avere impatto sul successo di cui parli e non i primi"

sono in totale disaccordo. e qui secondo me sta il fulcro di quello che intendo io della nostra professione nell'ambito di una accezione "aziendale". requisiti funzionali (da cui scturiscono use case/user story e quindi dominio applicativo, e quindi ecc. ecc.) e requisiti non funzionali (scelte tecnologoche, scelte commerciali, ecc. ecc.) per come la vedo io, hanno assolutamente egual peso per il successo di un progetto.
continuo sempre di più a pensare che nel nostro mondo soffriamo troppo di una deriva fuorviante che è quella del giusto compromesso. il disegno di un applicazione non può essere in alcun modo, secondo me, prioritario a confronto di altri vincoli/scelte. Viviamo e lavoriamo in un universo interconnesso, dove il nostro lavoro, a mio modo di vedere, è quello di raggiungere il miglior risultato di gestione progettuale (non solo di produzione di codice, che almeno per quanto mi riguarda, è solo una parte del mio lavoro). e questo spesso significa anche che le best practices di cui parli per quanto riguarda il rapporto commerciale con il cliente, non sono percorribili, per limiti tutti interni al cliente stesso, limiti che diventano vincoli esogeni per noi e che vanno affrontati.
ma lo stesso discorso te lo potrei fare per le scelte tecnologiche, che in nessun modo secondo me possono essere subalterne alle scelte di disegno della tecnologia, perchè, a seconda dello scenario, possono essere vincoli (anche di carattere strategico/commerciale) alla progettazione dell'applicazione stessa.
Le best practices sono una linea guida verso il successo architetturale dell'applicazione, ma secondo me
applicazione != progetto
troppo spesso pensiamo all'applicazione e troppo poco, maledettamente troppo poco al progetto. in questo senso, per riequilibrare i piatti della bilancia, le linee guida sono una traccia ben precisa a cui però è possibile derogare per raggiungere il punto di ottimo (un ottimo algoritmico/matematico) del progetto nel suo complesso. in questo senso, l'ottimo dell'applicazione è una delle n variabili pesate e non è detto che raggiunto quello, si raggiunga in automatico l'ottimo del progetto nel suo complesso.

saluti
Roberto
Gravatar

# re: Best practices and real world

@Luca. L'approccio dal basso è una soluzione in *tantissimi* scenari, concordo. Non è detto che sia la strada vincente per *tutti* gli scenari.
8/19/2008 9:14 AM | Raffaele Rialdi
Gravatar

#  Architettura e mondo reale

Architettura e mondo reale
3/24/2012 7:45 AM | Pingback/TrackBack
Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET