Ad una settimana dal Real Code Day credo di essere un po' in ritardo per parlare dell'evento in sè...
Mi limito a condividere le impressioni del mio compagno di viaggio Alessandro e a rinnovare i miei complimenti a tutti gli speaker.

Traggo invece spunto dalla giornata di Firenze per fare alcune considerazioni circa lo sviluppo su piattaforma Microsoft, riprendendo quanto già accennato qualche giorno fa.
Non so quanto possa essere attendibile considerare come campione rappresentativo dei developers .NET i 418 convenuti al RCD, però i risultati sono stati (per me) sconcertanti: solo una minoranza - quasi trascurabile - utilizza design patterns, architetture n-tier e modelli di sviluppo "standard"; ne consegue che per la maggior parte il codice è "data-centric", con dataset - si spera almeno tipizzati - portati a livello di UI.

Facciamo un passo indietro e vediamo da dove siamo partiti: ormai alcuni anni fa, Microsoft ha lanciato la piattaforma .NET, con lo scopo - più o meno dichiarato - di aggredire il mercato enterprise (grandi gruppi industriali, banche, assicurazioni, tlc, ecc.) cercando così di sottrarre una preziosa fetta di mercato al più diretto concorrente: J2EE.

Ad oggi Java e .NET sono due piattaforme pressoché equivalenti sotto molto punti di vista e destinate a crescere in modo parallelo (basti considerare le forti analogie tra la versione 5 di Java e la 2 di .NET). Certo, restano delle differenze, ma si tratta di cose veniali o legate al gusto personale (ad esempio i generics sono implementati meglio in C# ma, di Java, invidio la dichiarazione delle eccezioni nella firma dei metodi)
In questa corsa Microsoft ha però dovuto "fare i conti" con gli utenti provenienti da VB6 e ASP, cercando il modo di ridurre il più possibile la curva di apprendimento della nuova tecnologia, consentendo a tutti di essere da subito produttivi. Il risultato è stato (aimé!) l'introduzioni di wizard e strutture che semplificassero e riducessero la stesura del codice.

Se fino ad oggi poteva anche essere accettato un uso "poco formale" della piattaforma, ora credo sia giunto il momento di fare tutti un piccolo sforzo per migliorare il nostro modo di scrivere il codice e di gestirne meglio il ciclo di vita (senza pensare a Team System... credo basti ricordare i costi di manutenzione e quanto detto da Riccardo nella sua sessione)... Se poi consideriamo che ormai il concetto di Object Oriented Programming sembra essere superato, l'esigenza si fa ancor più pressante.

Indubbiamente ci viene richiesto, almeno inizialmente, di scrivere più codice ma, se il risultato è quello di produrre codice di maggior qualità, credo ne valga la pena! I design patterns, il modello 3 tier, l'uso di DAO e DTO, ecc. possono essere visti come delle "noie" (un po' come alcuni formalismi richiesti da C# rispetto a VB) ma credo che in breve tempo possano essere apprezzati anche i grandi vantaggi che comportano.

Mi dispiace vedere che alcuni tra i migliori framework disponibili per .NET siano un semplice porting di qualcosa nato per il mondo J2EE (penso ad esempio a Lucene, Log4net o NHibernate) ma spero che la community .NET cresca fino a far registrare un'inversione di tendenza, costringendo il mondo Java a riconoscere l'esistenza di buoni prodotti da copiare da noi, magari adottandoli semplicemente con una "J" come prefisso!

Un buon punto di partenza per arrivare alla qualità è il "codice reale" visto a Firenze: scarichiamolo, analizziamolo, facciamo domande e cerchiamo di farlo nostro, usando le stesse metodologie nel nostro codice di tutti i giorni.

Happy programming a tutti.

P.S.: tutte le considerazioni di cui sopra sono IMHO, quindi condivisibili o contestabili a vostra discrezione :-)