Come anticipato ieri, eccomi a scrivere un po' di
commenti sull'esame 70-300 (Analyzing Requirements and Defining Microsoft .NET Solution
Architectures), che ho sostenuto venerdì.
Ho passato la scorsa settimana a tempo pieno (e le due
precedenti a spizzichi) dedicandomi alla preparazione. Seguendo, anche, i consigli che mi sono stati dati, ho finito di leggere il
volume di preparazione (questo) e ho ordinato e letto quest'altro
da Amazon.
Alla fine della fiera, il commento breve è: "Potevo leggermi Topolino, e il
risultato non sarebbe cambiato di molto".
Il commento lungo, invece, recita: "Sono state letture molto utili per la mia
preparazione."
La disparità è presto spiegata.
Al solo scopo di superare l'esame, sono state ben poche le informazioni che
ho ricavato dalla studio.
In un paio di domande ho risposto con maggior sicurezza (non chiedetemi quali
... ho sottoscritto un NDA !), e nulla più. Non posso che confermare quello
che mi era stato detto: esperienza e buon senso sono la chiave per
passarlo.
Intendendo la preparazione in senso un po' più generale, invece, cioè come
attività non esclusivamente finalizzata al superamento di un test, devo dire che
le cose cambiano, e non di poco.
Esco da tre settimane di studio con un'opinione molto diversa su alcuni
aspetti.
Punto Uno: ho rivalutato UML.
Purtroppo ne avevo (e ne ho tuttora, anche se adesso va un po' meglio)
una conoscenza raffazzonata e decisamente poco organica. Impossibile, quindi,
capirne le potenzialità, al di là di qualche effetto grafico. Lo giudicavo,
evidentemente, in modo non proprio corretto. Non vengo a dire ora che UML è la
soluzione di tutti i mali, ci mancherebbe ! Semplicemente credo che,
adeguatamente studiato e capito, si possa rivelare un ottimo compagno nella fase
di analisi e di progettazione.
Personalmente, sono un
po' meno convinto riguardo alle funzionalità di forward-engineering da un diagramma
UML. Una volta preparato lo schema di un'applicazione (o di un componente ...)
non credo sia molto il risparmio di tempo (almeno
per progetti relativamente piccoli), anche perchè inevitabilmente qualche modifica al codice auto-generato andrà fatta.
Non dò un giudizio definitivo perchè non ho avuto modo di provare questa
funzionalità in prima persona (devo decidermi a passare a MSDN Universal
!), quindi aspetto di essere smentito.
Punto due: ho fatto il mio primo incontro serio con MSF, e non mi è
dispiaciuto per niente.
Il primo approccio è stato un po' difficile, perchè mi aspettavo qualcosa di
molto più concreto. In realtà questa valutazione dipendeva da un mio modo,
errato, di affrontare l'argomento.
Fondamentalmente cercavo qualcosa del tipo: "Usa COM+ se (a), (b) e (c), usa
i WS se (d) o (f), ecc...". O, più in generale, mi aspettavo qualcosa di molto
più vicino alla tecnologia di implementazione.
Invece ho letto con
interesse di problematiche che avevo sempre considerato estranee al processo di
sviluppo. Il che può ancora essere vero, se cambio lo scope che dò al termine
sviluppo ! Detto in altri termini, ho avuto modo di vedere in un'altra ottica le
attività di analisi e progettazione di un sistema software che, anche a
causa dell'esperienza raccolta finora, avevo relegato dentro un calderone
informe.
Punto tre: ho fatto amicizia con Visio, finalmente !
Punto quattro, nonchè somma e riassunto dei punti precedenti: sono ritornato
sulle mie opionioni riguardo la "bellezza" dell'essere architetto.
Lasciamo da parte il fatto che il termine è piuttosto generico ed
infinitamente abusato.
Quello che intendo è che ho intravisto, per quel
che si può fare da alcune (centinaia di) pagine di libro, diversi aspetti legati
all'attività di analisi e progettazione software che mi hanno stimolato parecchio.
Se, poi, questa opinione trovi conferma in qualche caso reale, beh
... non può che essere una speranza. Speranza che, per ora, mi tengo ben
stretta.
Detto questo, mi godo i miei 4/5 di MCSD ... e vi rifaccio ancora una volta
gli auguri di buone feste !