Come consulente vengo spesso chiamato da software house che devono iniziare lo sviluppo di una nuova applicazione per definire con loro devo l'architettura, le linee guida da seguire, il design, ecc…
Non sempre però le cose vanno come ci si aspetta.
Mi sono trovato talvolta a proporre soluzioni architetturali e di design abbastanza complesse, perché a mio avviso i requisiti dell'applicazione lo richiedevano.
Il mio ruolo quindi prevede che io inizi ad abbozzare la soluzione, prepari alcune classi, insegni al team le linee guida da seguire e poi lasciare che siano loro a proseguire nello sviluppo, io mi occupo di controllare ogni tanto che il tutto proceda bene.
Spesso però noto che l'architettura devia (anche di parecchio) da quella proposta, spesso si inizia da un workaround per fare prima, o da un malinteso delle mie spiegazioni o più frequentemente da un livello di conoscenza non sufficientemente elevato del team che realizza l'applicazione.
Con il senno di poi il mio approccio è cambiato e la mia consulenza inizia spesso con un mini corso in cui presento una serie di soluzioni possibili che vanno dalla più semplice alla più complessa. La scelta viene quindi fatta con il team, cercando di capire con loro quale sarebbe quella in cui si trovano meglio, quella in cui si sentono più a loro agio.
Cosi ogni tanto mi capita di optare per un design meno pulito, più procedurale, per far si che il team si trovi bene.
IMHO credo sia comunque meglio un'architettura con qualche pecca che una bella architettura sulla carta ma "spaghetti" nel codice.