Ci sono state molte domande con buone risposte sul ruolo di un Software Architect (SA) su StackOverflow e Programmatori SE . Sto cercando di porre una domanda leggermente più mirata rispetto a quelle. La definizione stessa di una SA è ampia, quindi per questa domanda definiamo una SA come segue:
A Software Architect guides the overall design of a project, gets involved with coding efforts, conducts code reviews, and selects the technologies to be used.
In altre parole, non sto parlando del riposo manageriale e del gilet sulla cresta (ulteriori parole rimate elidate) tipi di SA. Se dovessi perseguire qualsiasi tipo di posizione SA, non voglio stare lontano dalla codifica. Potrei sacrificare un po 'di tempo per interfacciarmi con clienti e analisti aziendali, ecc., Ma sono ancora tecnicamente coinvolto e non sono solo a conoscenza di ciò che accade durante le riunioni.
Con questi punti in mente, che cosa dovrebbe portare una SA al tavolo? Dovrebbero entrare con una mentalità di "dettare legge" (per così dire) e applicare l'uso di determinati strumenti per adattarsi "a modo loro", cioè linee guida per la codifica, controllo del codice sorgente, schemi, documentazione UML, ecc.? Oppure dovrebbero specificare la direzione e la strategia iniziali, quindi essere rilassati e saltare come necessario per correggere la direzione della nave?
A seconda dell'organizzazione potrebbe non funzionare. Una SA che fa affidamento su TFS per far rispettare tutto può faticare a implementare il proprio piano presso un datore di lavoro che utilizza solo StarTeam. Allo stesso modo, una SA deve essere flessibile a seconda della fase del progetto. Se è un progetto nuovo, hanno più scelte, mentre potrebbero avere meno per i progetti esistenti.
Ecco alcune storie di SA che ho vissuto come un modo per condividere un po 'di background nella speranza che le risposte alle mie domande possano gettare luce su questi temi:
-
Ho lavorato con un SA che ha revisionato il codice letteralmente ogni singola riga di codice del team. La SA farebbe questo non solo per il nostro progetto ma anche per altri progetti nell'organizzazione (immagina il tempo trascorso su questo). All'inizio era utile applicare certi standard, ma in seguito divenne paralizzante. FxCop era come la SA avrebbe trovato problemi. Non fraintendetemi, è stato un buon modo per insegnare agli sviluppatori junior e costringerli a pensare alle conseguenze del loro approccio scelto, ma per gli sviluppatori senior è stato considerato piuttosto draconiano.
-
Una particolare SA era contro l'uso di una certa libreria, sostenendo che era lenta. Questo ci ha costretti a scrivere tonnellate di codice per realizzare le cose in modo diverso mentre l'altra biblioteca ci avrebbe risparmiato un sacco di tempo. Avanzamento veloce fino all'ultimo mese del progetto e i clienti si sono lamentati delle prestazioni. L'unica soluzione era cambiare alcune funzionalità per utilizzare l'approccio originariamente ignorato nonostante i primi avvisi degli sviluppatori. A quel punto un sacco di codice è stato buttato fuori e non riutilizzabile, portando a straordinari e stress. Purtroppo le stime utilizzate per il progetto erano basate sul vecchio approccio a cui il mio progetto era vietato di utilizzare, quindi non era un indicatore appropriato per la stima. Sentirei il PM dire "lo abbiamo già fatto prima", quando in realtà non lo avevano visto che stavamo usando una nuova libreria e gli sviluppatori che ci lavoravano non erano gli stessi sviluppatori usati nel vecchio progetto.
-
La SA che imporrebbe l'utilizzo di DTO, DO, BO, livelli di servizio e così via per tutti i progetti. I nuovi sviluppatori hanno dovuto apprendere questa architettura e le linee guida sull'utilizzo imposti da SA. Sono state fatte eccezioni alle linee guida sull'uso quando era assolutamente difficile seguire le linee guida. La SA era radicata nel loro approccio. Le classi per DTO e tutte le operazioni CRUD sono state generate tramite CodeSmith e gli schemi di database erano un'altra sfera di cera simile. Tuttavia, avendo utilizzato questa configurazione ovunque, la SA non era aperta a nuove tecnologie come LINQ to SQL o Entity Framework.
Non sto usando questo post come piattaforma per lo sfogo. C'erano aspetti positivi e negativi alle mie esperienze con le storie di SA menzionate sopra. Le mie domande si riducono a:
- Che cosa dovrebbe portare una SA al tavolo?
- Come possono trovare un equilibrio nel loro processo decisionale?
- Si dovrebbe avvicinarsi a un lavoro SA (come definito in precedenza) con la mentalità che devono applicare determinate regole di base?
- Qualcos'altro da considerare?
Grazie! Sono sicuro che queste attività lavorative sono facilmente estese a persone che sono sviluppatori senior o lead tecnici, quindi sentiti libero di rispondere anche a quella capacità.