Sono ormai da qualche settimana alle prese con la preparazione dell'esame 70-300.
Chiedendo informazioni in giro, magari a colleghi o amici che lo hanno provato (o che hanno provato il suo predecessore, prima della rivoluzione .NET), i consigli che ho ricevuto si riassumono per la maggior parte in:
"C'è poco da studiare, devi andare a buon senso".
Questa affermazione, insieme a qualche lettura degli utlimi giorni, mi ha fatto riflettere.
In particolare è la locuzione buon senso che va interpretata.
In primo luogo, il buon senso comune, a prescindere dall'esperienza o dalle conoscenze, non credo porti molto lontano: se mio nonno andasse a provare l'esame, senza esperienza e senza conoscenze specifiche, ma con tutto il buon senso che si porta dietro con l'età ... beh, probabilmente non lo passerebbe (almeno spero, volete mettere che figura se poi io invece lo canno 
).
Buon senso, allora, sta per "buon senso, supportato dall'esperienza".
E qui sta il punto. Perchè questa è un'affernazione pericolosa, oltre che sbagliata in assoluto.
Provo ad estremizzarla, per spiegarmi meglio.
Immaginate di aver sviluppato software per dieci anni.
Con un po' di fortuna siete riusciti ad avere una visione al di là del marginale. Se proprio vi è andata bene, magari perchè avete fatto carriera o semplicemente perchè avete lavorato in una realtà medio-piccola, avete avuto la visione globale sull'intero progetto.
Sul biglietto da visita avete scritto "Software Architect" - che in inglese fa sempre più professionale - e ovviamente vi ritenete tale. E forse lo siete anche, almeno in termini relativi.
La mattina dell'esame vi recate al CTEC di vostra scelta, armati di valigetta e con l'assoluta convinzione di poterlo passare in mezz'ora, sfruttando le due ore di libertà per un caffè ed un giro in centro.
La mezz'ora diventa un'ora e mezza (accidenti, che robe che chiedono, ma chi le usa ?!).
Il caffè vi va di traverso perchè avete miseramente fallito la prova.
Com'è possibile ?
La mia risposta è lapidaria: la vostra esperienza è sbagliata (vedi nota in fondo al post)!
Ieri stavo leggendo alcuni paragrafi di un volume di preparazione per l'esame in questione.
Si parlava di Microsoft Solutions Frameworks (per chi non ne ha mai sentito parlare, è un insieme modelli e di linee guida utili nel corso dell'analisi di un progetto software, che coprono tutte le fasi del progetto, dai preliminari a sviluppo/test/deploy).
In particolare, veniva descritto il "Team Model": come dovrebbe essere composto un team di sviluppo, con la focalizzazione sui ruoli dei singoli componenti e sulla loro reciproca compatibilità).
Io ho semplicemente cercato di retro-applicare quelle linee guida ai team nei quali sono stato coinvolto, o di cui ho sentito parlare sufficientemente per poterne dare un giudizio.
E il 90% dei campioni era nettamente contro il modello.
Il più frequente motivo di collisione che ho riscontrato è che, molto spesso, chi sviluppa fa i test sul proprio codice. E non parlo di un giro in debug perchè c'è un'access violation, ma di test un po' più ad alto livello (li chiamerei unit testing, se non fosse che quando leggerò il capitolo relativo probabilmente non saranno definibili in quel modo ...).
I motivi possono essere diversi: dalla disorganizzazione interna (ma questo, almeno nei casi che ho valutato, era il fattore meno frequente), al sottodimensionamento del personale (che è una forma, spesso subita, di disorganizzazione).
Chi osserva i modelli di analisi e sviluppo in questi contesti, e si basa su quelli per definire i concetti chiave del progetto software ideale, ha una visione che, sbagliata o meno che sia, è opposta a quella di MSF.
E le crocette le mette nel posto sbagliato.
nota in fondo al post
Non è tanto questione di giusto o sbagliato in assoluto.
MSF, come, credo, ogni altro modello, di qualsiasi tipo esso sia, va preso con le pinze ed applicato nelle realtà specifiche.
Se si potesse progettare (o programmare) istanziando un pattern, noi sviluppatori avremmo perso il lavoro !
Ciò nonostante, è un modello che va preso in considerazione seriamente, magari solo come oggetto di paragone.
E questo perchè è stato pensato, non dedotto dal singolo contesto applicativo, come invece è per chi si fa un'idea del processo di progettazione estraendola dalla propria esperienza.
La mia opinione è che seguire un modello alla lettera porti quasi sempre alla morte di un progetto. Però quel modello sarebbe bello averlo sempre in mente, per valutare quali sono i punti in cui si scende a compromessi o ci si discosta per questioni di tempo o risorse.
update:
Dimenticavo ... sono graditisssssssssimi consigli / suggerimenti per l'esame, soprattutto riguardo testi e risorse per una buona preparazione !