Pensieri

Mini rivisitazione dei progetti a cui ho partecipato

Maurizio — Tue, 20 Jul 2010 10:16:00 GMT

Avendo visto negli ultimi anni un bel pò di applicazioni .Net di ogni tipo, avendo partecipato ad un bel pò di progetti e conseguentemente visto una quantità considerevole di righe di codice, di seguito elenco (in ordine sparso) le mie considerazioni sulla qualità media del codice sorgente da me visionato e su cui spesso e volentieri sono intervenuto in prima persona per correzioni e/o nuove funzionalità (leggasi elenco di brutture e/o coding horror):

- La visibilità delle classi è una questione non tenuta nella giusta considerazione. Quando si crea una classe la si marca come "public", e tale resta per sempre, anche se la classe potrebbe essere "internal";

- il paradigma "Object Oriented Programming" è scarsamente applicato, ed anche scarsamente conosciuto, e cosi si finisce spesso per avere, solo a titolò di esempio, codice duplicato, scarsamente coeso e altamente accoppiato;

- Boxing e unboxing: concetto non conosciuto dai più, e cosi accade che il tipo "object" è usato a sproposito, e la tipizzazione dei dati diventa una rarità;

- Concatenazioni di stringhe a go-gò, anche se è arcinoto che questa operazione non è performante a causa dell'immutabilità dell'oggetto stringa che "stressa" parecchio il garbage collector;

- Utilizzo delle eccezioni nella logica di business dell'applicazione per notificare situazioni particolari;

- Utilizzo indiscriminato di Dataset/Datatable in ogni layer applicativo (front-end compreso), al posto di oggetti di dominio non anemici, cioè dotati di attributi e di comportamento (sì lo so, chiedo forse troppo, questo è Domain Driven Design...), con conseguente profilerazione di classi per la gestione delle entità trattate dalla applicazione, es. CustomerManager, OrderManager, ecc.
Su questo argomento potrei aprire una lunga discussione, circa colui che io definisco "il programmatore del dataset";

- La modularità di una applicazione e il concetto di "Separation of Concern" (Soc) non attira l'interesse della maggior parte degli addetti ai lavori. Come già discusso qui, è più importante rispettare i termini di consegna puttosto che creare software di qualità, ed ecco che si finiisce per scrivere software quasi monolitici, dove le responsabilità si "accavallano" in modo netto ed evidente tra i vari moduli. In applicazioni ASP .Net il code-behind si è spesso rivelato una trappola, nel senso che la classe "pagina" contiene una quantità spropositata di codice, ad esempio negli event handlers, alla faccia del concetto di basso accoppiamento;

- Assenza di Unit Test, non nel senso che nessuno li scrive ma nel senso che il Test Driven Development per molti è una sigla non pienamente compresa; in quei pochi scenari in cui ho visto scrivere Unit Tests questi non erano mai strutturati nel modo corretto secondo lo schema arrange-act-assert ma erano per lo più invocazioni di metodi a scopo di debugging. In pratica, più che "Sviluppo guidato dal test" ho visto l'esatto opposto

Fortunatamente ho anche visto codice scritto benissimo, bene, o almeno in modo decente

Settore ingegneristico o artigianale ?

Maurizio — Fri, 09 Jul 2010 13:06:14 GMT

Poichè mi piace tenere insieme i miei pensieri su questo blog, riporto la mia risposta all'amico Andrea Saltarello sullo spinoso tema da lui sollevato in un thread sul forum di GUISA, ovvero "ma siamo solo artigiani ?"

"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... "

Quando applicare una metodologia alla cieca è controproducente...

Maurizio — Tue, 29 Jun 2010 14:54:13 GMT

Spesso applicare una metodologia per il gusto di farlo, oppure solo perchè si è un profondo sostenitore di una certa tecnica ignorando completamente il contesto in cui si sta operando, può essere più deleterio che non applicarla proprio, e si finisce per avere una attenzione maniacale ai dettagli (che di norma costtuiscono il dogma della metodologia / tecnica che si sostiene), anche ai più insignificanti e più difficili anche solo da notare, e contemporaneamente una completa disattenzione per aspetti molto più evidenti che emergono giorno per giorno, ai quali si finisce poi per non dare il giusto peso.

L'argomento di questo post sono le metodologie di gestione di un progetto software con elevata complessità e criticità, ed il post è volutamente ermetico, ma sicuramente, rileggendolo a distanza di tempo, mi ricorderò molto bene del contesto che mi ha portato a sfogarmi con un post come questo.

Considerazioni molto personali sul lavoro nel mondo IT

Maurizio — Fri, 23 Apr 2010 10:57:32 GMT

Negli ultimi tempi sono stato coinvolto in una attività di recruitment mirata a reperire figure professionali nel mondo IT con skill particolarmente elevato, diciamo una figura di senior developer con conoscenze anche in ambito architetturale. Ho accettato con entusiasmo questa attività poichè ero curioso di capire se la preparazione universitaria in ambito informatico fosse sufficientemente in grado di reggere l'impatto con il mondo del lavoro e con la realtà di tutti i giorni (questo ovviamente per i laureati, ma lo stesso discorso può essere applicato anche per chi laureato non è).

E le sorprese non sono mancate.

Ecco, in sintesi, le mie considerazioni:

- Una laurea non è assolutamente garanzia di preparazione e competenza. Spesso i neolaureati, si "adagiano sugli allori", pensando che il loro titolo di studio basti e avanzi, ma in realtà non è così, poichè i ritmi con cui si evolve la tecnologia sono talmente elevati che solo con una spiccata dose di passione e/o sacrificio è possibile essere aggiornati in modo almeno sufficiente;

- L'attività di senior developer o comunque qualsiasi attività prettamente tecnica spesso sono viste come attività "rognose" e molto impegnative, per cui le ambizioni dei candidati a volte si spostano verso ruoli di più alto livello, o comunque non a stretto contatto con la tecnologia (es. coordinatore di risorse o addirittura analista funzionale);

- I cv sono spesso gonfiati a sproposito. Per un appassionato non c'è nulla di male nell'inserire "ottima conoscenza teorica di ....." senza aver avuto la possibilità di mettere in pratica questa conoscenza. Diverso è inserire esperienze anche pluriennali senza alcuna valenza. Non è possibie sentirsi dire che non si sono mai utilizzate le caratteristiche più elementari del polimorfismo quando sul cv è scritto "pluriennale esperienza nella programmazione ad oggetti", oppure "ottima conoscenza di ASP. NET" e poi non si sa a cosa serve il ViewState;

- L'atteggiamento del candidato durante una intervista non è spesso quello giusto da tenere in situazioni del genere, dove, a mio avviso, occorre mostrare soprattutto umiltà di fronte a ciò che si conosce e soprattutto di fronte a ciò che non si conosce;

Fortunatamente si incontrano anche persone appassionate di questo lavoro e competenti, che ripagano ampiamente gli sforzi effettuati.

Visual Basic Tips & Tricks Community Day a Milano

Maurizio — Fri, 19 Mar 2010 11:04:00 GMT

Ieri pomeriggio ho partecipato al Visual Basic Tips & Tricks Community Day tenutosi a Milano.

Devo dire che è stato un pomeriggio decisamente interessante dal punto di vista tecnologico, permettendomi di focalizzare alcuni concetti su tecnologie che uso o che vorrei usare, e mi riferisco a TFS 2010 ed Entity Framework 4.0

L’evento si apre con una sessione di Lorenzo Barbieri che parla delle varie versioni di Visual Studio 2010 che saranno disponibili a breve e delle novità, veramente tante, della nuova versione dell’IDE.

In ordine sparso:

Possibilità di effettuare ricerche parziali con l’Intellisense;
Intellisense nei file Javascript migliorato, ora vengono risolti anche i simboli presenti nei files inclusi, e non solo quelli del file in debugging;
Funzionalità di “search a you type”, per intenderci tipo Google quando ci presenta i risultati della ricerca mano a mano che scriviamo il testo da ricercare;
Funzionalità di “Call Hierarchy”, per il momento presente solo con il linguaggio C#, ovvero la possibilità di navigare a partire da un metodo / proprietà / costruttore verso il codice chiamante / chiamato a partire dal punto di navigazione scelto;
Modalità “Web only” dell’IDE, ovvero la possibilità di utilizzare un IDE con il solo codice in primo piano e tutte le finestre di dialogo minimizzate;
Selezione del testo per colonne;
Gestione degli add-in con un apposito Extention Manager dedicato;
Intellitrace (feature molto molto utile ed interessante per troubleshooting), ovvero un componente capace di registrare tutto quello che avviene nel codice quando questo è in esecuzione, una specie di scatola nera dell’applicazione, utilizzabile su applicazioni scritte con la versione 2.0 del Framework in poi ;
Test di automazione della UI;

Poi è stata la volta di Alessandro Del Sole, che ha mostrato le novità di Team Foundation Server 2010 in ottica singolo sviluppatore o piccoli gruppi di lavoro.

Successivamente Antonio Catucci ha mostrato le novità di Entity Framework 4.0, ovvero:

Possibilità di gestione della Foreign Key nel modello dati, senza che la stessa sia nascosta (come è noto nel mondo dei database relazionali una relazione tra 2 tabelle si traduce con la presenza di una colonna in comune tra le due tabelle, che costituisce appunto la relazione, nel mondo OOP una relazione di questo tipo si traduce con la presenza di una proprietà tipizzata nell’oggetto “padre”);
“Lazy Loading” attivo sempre di default;
“Pluralization” dell’Entity Set basato sulla grammatica inglese. Con Entity Framework 1.0 questa mancanza mi ha provocato qualche problema, in quanto va gestito a manina;
“Model-First Design”, feature decisamente interessante che consente di creare un domain model senza che sia necessariamente presente un database da cui partire. Con la versione 1.0 il domain model è forzatamente creato a partire da una base dati esistente;
“T4 Code Generation”. Con questa feature il codice generato da Entity Framework può essere basato su template, fornendo quindi la possibilità di generazione personalizzata dello stesso.
“POCO Entity (Plain Old CLR Objects)”, anche questa è una feature molto interessante, ovvero la possibilità di usare nel Domain Model della classi “pulite”, magari già esistenti senza che debbano per forza di cose ereditare da una classe specifica di Entity Framework;
Gestiona automatica delle relazioni molti a molti, senza la visualizzazione della terza tabella di legame tra le due relazionate;
Nuovo controllo EntityDataSource per il binding dei dati in ASP .NET.
Metodo “ApplyCurrentValues”. Permette di gestire le modifiche apportate su oggetti “detached”, ovvero al di fuori dell’ObjectContext attivo, e di propagare le stesse modifiche sull’oggetto avente la stessa chiave presente nell’ObjectContext (oggetto “attached”).

Come è evidente la versione 4.0 di Entity Framework contiene una pletora di novità, che sicuramente consentiranno a questo ORM made in Microsoft di superare alcuni limiti di “gioventù” della precedente versione.

Anobii, la mia libreria virtuale

Maurizio — Sun, 07 Feb 2010 23:09:00 GMT

Finalmente ho modo di mettere un pò in ordine la mia libreria, non fisicamente ma almeno virtualmente. Ho infatti creato su Anobii, un social network incentrato totalmente sui libri, la mia libreria virtuale dove piano piano organizzerò per argomento i numerosissimi libri in mio possesso, tecnici e non, onde consentire anche ai più curiosi di darci una sbirciatina per curiosare cosa conservo gelosamente sui miei scaffali.

Qui è accessibile il mio scaffale virtuale, per il momento ancora molto limitato.

Visit my shelf

www.anobii.com

Java meglio di .NET ?

Maurizio — Mon, 25 Jan 2010 21:28:50 GMT

Il titolo di questo post è volutamente ironico, ed affronta un argomento all'ordine del giorno in ogni ambiente di lavoro e/o community in cui si ha a che fare con le tecnologia legate al mondo del software.
In questi ambienti capita spesso infatti di sentire o di partecipare a discussioni circa il fatto che quella o quell'altra tecnologia prevale a parità di contesto di utilizzo, es. Java è meglio di .NET, Oracle è meglio di Sql Server, o viceversa.
Questi dibattiti, per quello che è la mia esperienza sul campo, sono spesso e volentieri condizionati dalla unilaterale conoscenza di una particolare tecnologia, e raramente colui che l'appoggia ha una consolidata esperienza su entrambe le piattaforme.
Ho assistito molto spesso a discorsi tipo:

"questo pezzo di codice se fosse scritto in Java non avrebbe quel bug...",

oppure

"se questa query fosse in PL-SQL le prestazioni sarebbero sen'altro migliori".

In questo interessantissimo post di Scott Guthrie in merito all'ultimo dibattito tecnologico in essere tra gli sviluppatori web (meglio ASP .NET Web Forms o ASP .NET MVC ?), è sintetizzato il mio pensiero sull'argomento:

"Great developers using bad tools/frameworks can make great apps. Bad developers using great tools/frameworks can make bad apps. Be very careful about making broad assumptions (good or bad) about the quality of the app you are building based on the tools/frameworks used".

Sono le persone che partecipano allo sviluppo a rendere vincente o perdente un software, a prescindere dalla particolare tecnologia applicata, ed è un grave errore pensare che solo perchè si è scelto di utilizzare l'ultima moda tecnologica un progetto software debba per forza essere vincente.

Piccolo sfogo...

maurizio — Wed, 15 Jul 2009 00:56:00 GMT

Una pensiero che spesso mi viene in mente guardando il codice sorgente è: ma perchè scrivere in 10 righe di codice quello che potrebbe essere scritto in una o due righe ?

Le direttive using devono essere poste all'interno del namespace

maurizio — Tue, 22 Jul 2008 02:59:42 GMT

Questo post inizia con una frase tratta da un post di Scott Hanselmann con cui mi trovo completamente d'accordo:

Don't believe everything you read, even on a Microsoft Blog. Don't believe this blog, either! Decide for yourself with experiments if you need a tiebreaker!

Credo sia proprio vero, mai fidarsi ciecamente di quello che si legge in giro, soprattutto quando seri dubbi farebbero pensare il contrario.

Il motivo è presto detto: utilizzo normalmente FxCop come strumento di analisi del codice sorgente, lo trovo molto completo e ben fatto. Spinto dalla curiosità ho voluto utilizzare Source Analysis, un tool gratuito fornito da Microsoft ed integrato nell'IDE di Visual Studio. Dopo la primissima prova fatta mi ha incuriosito una sua segnalazione:

SA1200 - All using directives must be placed inside of the namaspace.

Per farla breve, tutti i files sorgenti del mio progetto provocavano una segnalazione di questo tipo poichè le direttive using erano poste esternamente alla definizione del namespace, così come automaticamente viene creato uno scheletro di una classe all'interno dell'IDE. La segnalazione in questione invita invece ad includere le direttive using all'interno della definizione del namespace, semprecchè sia presente. Facendo qualche ricerca in giro ho scoperto che in questo modo il compilatore segnala immediatamente una eventuale ambiguità tra i nomi dei tipi creati all'interno del proprio namespace e i tipi presenti nei vari namespace del .NET Framework. E fin qui nulla di strano.

Ho scoperto inoltre che questa guideline servirebbe anche ad aumentare le prestazioni, almeno nei casi specifici, in quanto forzarebbe il "lazy loading" degli assembly e non il caricamento immediato. In altre parole, quando il viene invocato un metodo di una classe e viene compilato il codice "just in time" (JITTED) il lazy loading permette di caricare in memoria solo gli assembly referenziati che servono all'invocazione del metodo stesso, e non tutti gli assembly referenziati da una classe, a prescindere se utilizzati o no da una specifica invocazione di un metodo. Questo permette di caricare solo lo stretto necessario anche se una classe referenzia un assemby non utilizzato da un metodo.

Sinceramente non mi è venuto in mente un solo valido motivo per cui una direttiva using posta in un certo modo potesse influenzare l'attività del CRL a runtime, e sono rimasto alquanto dubbioso sulla effettiva validità. Prima che potessi avere il tempo di fare una prova specifica mi son trovato questo post di Scott Hanselmann, al quale rimando per una esauriente spiegazione, che dimostra come purtroppo ciò non sia affatto vero, cioè gli assembly referenziati vengono caricati tutti i memoria immediatamente, a prescindere se il metodo in questione li usa oppure no, ed a prescindere se le direttive using vengono poste all'interno o all'esterno della definizione di namespace.

Quindi la morale è: non credere mai a quello che leggi, neanche se lo leggi da questo blog :), ma sperimenta sempre.

Tecnologia in evoluzione ed il suo utilizzo

maurizio — Mon, 31 Mar 2008 22:27:51 GMT

In questi giorni mi è capitato frequentemente di leggere su blogs e forum vari commenti entusiastici sull'adozione delle ultime tecnologie appena sfornate - parlo di Silverlight, Ajax e LINQ, le quali hanno ormai preso prepotentemente piede nello sviluppo di applicazioni. Premesso che utilizzo anch'io sia Ajax che LINQ, ritengo che il tutto debba essere calato nel contesto opportuno di utilizzo, senza lasciarsi prendere troppo dall'entusiasmo come invece vedo che accade. Può sembrare scontato ma la realtà è ben diversa. Comprendo perfettamente che lo sviluppatore esperto e soprattutto appassionato affronti le sfide tecnologiche che molto frequentemente il nostro mestiere ci offre, con l'entusiasmo di un ragazzino, ma credo che ultimamente si stia un po' esagerando. Sembra quasi che oggiogiorno ogni applicazione web debba essere necessariamente Ajax-enabled e sembra che LINQ to SQL, o meglio gli ORM in generale, abbiano sostituito di colpo l'utilizzo di strumenti per così dire tradizionali quali le store procedure, diventate improvvisamente uno strumento superato. Riflettendo un attimo, questo entusiasmo non è certo una novità nel mondo delle tecnologie software: come esempio non isolato, ricordo che successivamente all'introduzione dei web services tutti gli utilizzatori di software hanno adottato incondizionatamente questa tecnologia anche se le loro applicazioni non erano affatto interoperanti se non con sè stesse...L'unificazione del paradigma di sviluppo in funzione dei diversi contesti di utilizzo si è verificata solo con l'avvento di WCF. Accadrà lo stesso con le attuali tecnologie ?