Cosa dovresti portare al tavolo come Software Architect? [chiuso]

Ci sono state molte domande con buone risposte sul ruolo di Software Architect (SA) su StackOverflow e Programmers SE . Sto cercando di porre una domanda leggermente più mirata di quelle. La definizione stessa di una SA è ampia, quindi per il bene di questa domanda definiamo una SA come segue:

Un architetto del software guida la progettazione generale di un progetto, viene coinvolto nelle attività di codifica, conduce revisioni del codice e seleziona le tecnologie da utilizzare.

In altre parole, non sto parlando di riposo manageriale e di vestire i tipi di SA cresta (ulteriori parole in rima). Se dovessi perseguire qualsiasi tipo di posizione SA, non vorrei essere lontano dalla programmazione. Potrei sacrificare un po 'di tempo per interfacciarmi con clienti, analisti aziendali, ecc., Ma sono ancora tecnicamente coinvolto e non sono solo consapevole di ciò che accade durante le riunioni.

Con questi punti in mente, cosa dovrebbe portare sul tavolo una SA? Dovrebbero entrare con la mentalità di "stabilire la legge" (per così dire) e imporre l'uso di determinati strumenti per adattarsi "a modo loro", cioè linee guida di codifica, controllo del codice sorgente, schemi, documentazione UML, ecc.? O dovrebbero specificare la direzione e la strategia iniziale, quindi essere rilassati e saltare come necessario per correggere la direzione della nave?

A seconda dell'organizzazione, potrebbe non funzionare. Una SA che si affida a TFS per far valere qualsiasi cosa può avere difficoltà ad attuare 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 si tratta di un nuovo progetto, hanno più scelte, mentre potrebbero avere meno per i progetti esistenti.

Ecco alcune storie di SA che ho sperimentato come un modo per condividere alcuni retroscena nella speranza che le risposte alle mie domande possano anche far luce su questi temi:

• Ho lavorato con una SA che ha revisionato letteralmente ogni singola riga di codice del team. La SA farebbe questo non solo per il nostro progetto ma per altri progetti nell'organizzazione (immaginate il tempo speso per questo). Inizialmente era utile far rispettare determinati 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 visto come un po 'draconiano.

• Una SA in particolare era contraria all'uso di una determinata libreria, sostenendo che era lenta. Questo ci ha costretto a scrivere tonnellate di codice per ottenere risultati diversi mentre l'altra biblioteca ci avrebbe risparmiato un sacco di tempo. Avanzamento rapido verso l'ultimo mese del progetto e i clienti si sono lamentati delle prestazioni. L'unica soluzione era modificare alcune funzionalità per utilizzare l'approccio originariamente ignorato nonostante i primi avvisi degli sviluppatori. A quel punto un sacco di codice è stato espulso e non riutilizzabile, portando a straordinari e stress. Purtroppo le stime utilizzate per il progetto si basavano sul vecchio approccio che il mio progetto era proibito utilizzare, quindi non era un indicatore appropriato per la stima. Vorrei che il Primo Ministro dicesse "l'abbiamo già fatto prima"

• La SA che impone l'uso di DTO, DO, BO, livelli di servizio e così via per tutti i progetti. I nuovi sviluppatori dovevano apprendere questa architettura e le linee guida di utilizzo rigorosamente SA. Sono state fatte eccezioni alle linee guida per l'uso quando era assolutamente difficile seguire le linee guida. La SA era fondata sul 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, dopo aver 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. Ci sono stati aspetti positivi e negativi nelle mie esperienze con le storie di SA sopra menzionate. Le mie domande si riducono a:

1. Cosa dovrebbe portare sul tavolo una SA?
2. Come possono trovare un equilibrio nel loro processo decisionale?
3. Si dovrebbe avvicinarsi a un lavoro di SA (come definito in precedenza) con la mentalità che devono applicare determinate regole di base?
4. Qualcos'altro da considerare?

Grazie! Sono sicuro che queste attività lavorative possono essere facilmente estese a persone che sono sviluppatori senior o lead tecnici, quindi sentiti libero di rispondere anche a quella capacità.

Un architetto di sistemi dovrebbe:

1. Specificare l'architettura di alto livello
2. Partecipa alle revisioni del codice
3. Approvare le tecnologie utilizzate
4. Assistere gli sviluppatori nel loro sforzo di programmazione
5. Mantenere e monitorare il programma di sviluppo
6. Produci artefatti SA, come diagrammi UML, diagrammi di Gantt e simili.

Le SA devono saper codificare e dovrebbero partecipare ad alcune delle attività di codifica, bagnarsi le mani, per così dire. Questo li tiene in contatto con la gestalt dello sforzo di sviluppo. Come ha detto una volta lo zio Bob Martin , l'Architetto dovrebbe fare un po 'della codifica da solo, in modo da poter vedere il dolore che sta infliggendo agli altri con i suoi progetti.

La SA dovrebbe avere l'ultima parola su tutte le decisioni relative a design, tecnologia e stile di codifica. Ma, come tutti i dirigenti, il compito dell'AS è quello di liberare la strada per i suoi dipendenti in modo che possano essere produttivi. Ciò significa, per la maggior parte, che gli sviluppatori possono decidere, al loro livello, come risolvere i problemi. Significa che la SA tiene i boss con i capelli a punta fuori dai cubicoli degli sviluppatori. E significa che la SA si rivolge per aiutare, se necessario.

Come tutti gli esseri umani, i SA possono e commettono errori. I buoni imparano da quegli errori e diventano migliori SA.

Non ho mai incontrato un architetto che fosse utile, principalmente perché non erano pratici.

Per me i maggiori problemi che ho visto sono:

• aderenza cieca al processo per il bene del processo
• parzialità cieca alla tecnologia prima di conoscere il problema
• creazione e applicazione di regole senza una buona giustificazione
• rewrite from scratch mentalità

I migliori "architetti" con cui ho lavorato hanno portato al tavolo:

• Domande che hanno portato a una migliore comprensione del problema e delle potenziali soluzioni.
• Opzioni / tecnologie di progettazione e relativi compromessi.
• Spiegazioni chiare e razionali sia per le condanne che per l'approvazione di progetti e tecnologie.

Il problema per me è che i migliori "Architetti" con cui ho lavorato non avevano "Architetto nel loro titolo. Erano spesso ingegneri del software che sono fondati sul problema specifico e sui progetti. Hanno capito che nella maggior parte delle aziende non è ' È pratico per riscrivere una base di codice funzionante da zero. Prendono una decisione di progettazione o forniscono opzioni e le loro ragioni o giustificazioni. Descrivono come iterare la base di codice in una nuova architettura nel tempo e mantengono comunque tutto funzionale. Danno raccomandazioni conservative invece di raccomandare tutto ciò che è dejour o familiare. avrebbero comunicare una visione coesa di come le cose dovrebbero funzionare e perché, MA soprattutto avrebbero tracciare come arrivarci e il costo.

1 Cosa dovrebbe portare sul tavolo una SA?

• Una pelle spessa
• Buone capacità di negoziazione
• Una buona conoscenza dei vari livelli software (dalla bizzarra bontà AJAX agli I / O di rete di basso livello). Non sei necessariamente un esperto, ma dovrai prendere decisioni importanti su quale software dovrebbe essere eseguito su quale / i layer.
• Disponibilità a sporcarsi le mani nel codice, i disegni di carta bianca non lo tagliano.
• Incoraggiamento dell'artigianato del software: sii la cheerleader per fare le cose nel modo giusto quando possibile e nel modo migliore, date le limitazioni in altri casi. Quindi cose come controllo del codice sorgente, TDD, build e CI, codifica di DOJO, revisioni del codice, un buon sistema di tracciamento dei problemi, ecc.

2 Come possono trovare un equilibrio nel loro processo decisionale?

• Molto dipende dalla tua squadra (e) e dalla loro capacità.
• Il tuo ambiente (ad esempio potresti essere costretto a utilizzare il prodotto di un determinato fornitore)
• Nel complesso è meglio non essere un architetto di torre d'avorio, essere pratico, far parte del team: le persone capiranno le tue decisioni in quel modo.

3 Si dovrebbe avvicinarsi a un lavoro di SA (come definito in precedenza) con la mentalità di dover applicare determinate regole di base?

• Sì, cose come il controllo della versione e un sistema di compilazione sono dannatamente importanti e gli sviluppatori devono usarle. Tuttavia è sempre meglio renderli parte della soluzione.

C'è molto di più, penso che ci saranno delle risposte davvero buone per questo.

1.Che cosa dovrebbe portare sul tavolo una SA?

"Dovrebbero entrare con la mentalità di" stabilire la legge "... O dovrebbero specificare la direzione e la strategia iniziale, quindi essere ritirati e saltare come necessario per correggere la direzione della nave?"

Una combinazione di entrambi direi. Quando si decide su tecnologie e processi, essere aperti a opinioni e suggerimenti può dare feedback / input preziosi sulle decisioni e farti imparare dagli altri. La tua squadra è (si spera) intelligente; approfittane. Ma una volta presa una decisione (la tua decisione), la legge è stata stabilita. Identifica coloro che si lamenteranno di ciò che non era la loro scelta e quelli che sceglieranno semplicemente qualsiasi cosa e non se ne cureranno, quindi ignorali.

Per quanto riguarda le tecnologie: lavora con quello che hai, se la società utilizza StarTeam è quello che usi. Sposarsi con qualsiasi prodotto / tecnologia / processo particolare non farà nulla per te.

2.Come possono trovare un equilibrio nel loro processo decisionale?

Ascoltare la squadra e sapere quando hanno ragione e torto è importante e avere i cojones per dire loro che hanno torto e attenersi alla tua decisione. Non ascoltare porterà una mancanza di rispetto, così come il flop in giro per le tue decisioni.

3. Si dovrebbe affrontare un lavoro di SA (come definito in precedenza) con la mentalità di dover applicare determinate regole di base?

Sempre. In caso contrario, i detenuti finiranno per gestire l'asilo, apertamente o di nascosto. Decidere su quelle regole di base, tuttavia, può essere attraverso il dialogo con il team. Ricorda che ogni squadra potrebbe non avere sempre gli stessi membri che ha ora, quindi fare concessioni per un piccolo gruppo di loro potrebbe ostacolare la squadra in futuro una volta che se ne saranno andati. Ciò include la SA.

4. Qualcos'altro da considerare?

• In riferimento al tuo secondo esempio: sembra che il team del progetto abbia formato una dipendenza strettamente accoppiata da un sottosistema interno. Le facciate liberamente accoppiate non sono solo per codice di terze parti. La creazione di un'astrazione per quel sottosistema avrebbe potuto consentire una transizione più semplice all'utilizzo di quella libreria se la soluzione interna non fosse riuscita. Questa è una soluzione logica per un solo architetto del software, ma essendo anche una forma di Project Manager con le preoccupazioni dell'espressione del team, dovrebbe essere doppiamente quindi una soluzione ovvia.
• In riferimento al tuo terzo esempio: non è una cattiva idea avere un'architettura o un processo noti per la produzione di software (anche se, certamente, hai detto "tutti i progetti"). Questo è fedele a ciò che funziona. Detto questo, ci devono essere opportunità in cui si possono tentare nuove tecniche per vedere se apportano valore aggiunto. Il software interno o progetti di portata ridotta in cui è possibile tentare queste tecnologie sono i luoghi ideali. Tieni presente, tuttavia, che spetta anche agli sviluppatori fornire dimostrazioni / argomenti ricercati e convincenti per l'adozione di tecnologie. E non ci si può aspettare che SA conosca tutti gli ORM concorrenti e i suoi punti di forza e di debolezza rispetto agli altri.