Cosa dovresti portare al tavolo come architetto del software? [chiuso]

16

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:

  1. Che cosa dovrebbe portare una SA al tavolo?
  2. Come possono trovare un equilibrio nel loro processo decisionale?
  3. Si dovrebbe avvicinarsi a un lavoro 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 sono facilmente estese a persone che sono sviluppatori senior o lead tecnici, quindi sentiti libero di rispondere anche a quella capacità.

    
posta Ahmad Mageed 11.11.2010 - 19:12
fonte

4 risposte

21

Un Architetto di Sistemi dovrebbe:

  1. Specifica l'architettura di alto livello
  2. Partecipa alle recensioni del codice
  3. Approva le tecnologie utilizzate
  4. Assistere gli sviluppatori nello sforzo di codifica
  5. Gestisci e monitora il programma di sviluppo
  6. Produce artefatti SA, come diagrammi UML, diagrammi di Gantt e simili.

Le SA devono sapere come codificare e dovrebbero partecipare ad alcuni dei lavori di codifica, avere le mani bagnate, per così dire. Questo li tiene in contatto con la gestalt dello sforzo di sviluppo. Come disse zio Bob Martin , l'Architetto dovrebbe fare da solo parte della codifica, in modo che lui può vedere il dolore che sta infliggendo agli altri con i suoi disegni.

La SA dovrebbe avere l'ultima parola su tutte le decisioni relative a stile, tecnologia e stile di codifica. Ma, come tutti i manager, il lavoro della SA è quello di chiarire il percorso per il suo popolo in modo che possano essere produttivi. Ciò significa, per la maggior parte, che gli sviluppatori decidono, al loro livello, come devono essere risolti i problemi. Significa che la SA mantiene i boss dai capelli a punta fuori dai cubicoli degli sviluppatori. E significa che la SA interviene per aiutare, se necessario.

Come tutti gli esseri umani, le SA possono e fanno errori. I bravi imparano da quegli errori e diventano migliori SA.

    
risposta data 11.11.2010 - 19:29
fonte
7

1 Cosa dovrebbe portare una SA al tavolo?

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

2 Come possono trovare un equilibrio nel loro processo decisionale?

  • Gran parte dipende dal / dai tuo / i team / i e quanto sono capaci.
  • Il tuo ambiente (potresti essere costretto a utilizzare un particolare prodotto di un venditore, ad esempio)
  • In generale è meglio non essere un architetto di torre d'avorio, essere onesti, far parte del team - le persone capiranno le tue decisioni in questo modo.

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

  • Sì, cose come il controllo della versione e un sistema di compilazione sono piuttosto dannosi e gli sviluppatori devono usarli. Comunque è meglio farne parte della soluzione.

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

    
risposta data 11.11.2010 - 19:32
fonte
7

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

Per me i problemi più grandi che ho visto sono:

  • adesione cieca al processo per il processo
  • pregiudizi ciechi alla tecnologia prima di conoscere il problema
  • creazione e applicazione di regole senza una buona giustificazione
  • mentalità rewrite from scratch

I migliori "Architetti" con cui ho lavorato portati in tavola:

  • 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 per entrambe le condanne e le approvazioni di design e tecnologie.

Il problema per me è il migliore "Architetti" con cui ho lavorato non aveva "Architetto nel loro titolo. Erano molto spesso ingegneri informatici che si basavano su specifici problemi e progetti. non è pratico riscrivere da zero una base di codice funzionante, prendere decisioni di progettazione o fornire opzioni e le loro ragioni o giustificazioni, che descrivono come iterare la base di codice a una nuova architettura nel tempo e mantenere tutto funzionale. invece di raccomandare qualunque cosa sia dejour o familiare, comunicherebbe una visione coesa di come le cose dovrebbero funzionare e perché, MA più importante avrebbero mappato come arrivare e costo.

    
risposta data 12.11.2010 - 10:35
fonte
3

1.Che cosa dovrebbe portare una SA al tavolo?

"Dovrebbero entrare con una mentalità di 'dettare legge' ... O dovrebbero specificare la direzione e la strategia iniziali, quindi essere rilassati 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 un prezioso feedback / input sulle decisioni e far sì che si impari dagli altri. La tua squadra è (si spera) intelligente; approfittane. Ma una volta presa una decisione (la tua decisione), la legge è stata posta. Identifica quelli che si lamenteranno di qualsiasi cosa non sia stata loro scelta, e quelli che sceglieranno semplicemente qualsiasi cosa e non gli interesseranno, e poi li ignoreranno.

Per quanto riguarda le tecnologie: lavora con ciò che hai, se la società utilizza StarTeam, ecco cosa usi. Sposarti con un particolare prodotto / tecnologia / processo non ti farà nulla per te.

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

Ascoltare la squadra e sapere quando è giusto e sbagliato è importante, e avere i cojones per dire loro che hanno torto e attenersi alla tua decisione. Il non ascolto porterà una mancanza di rispetto, come faranno le tue decisioni.

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

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

4.Qualcosa altro da considerare?

  • In riferimento al tuo secondo esempio: sembra che il team del progetto formasse una dipendenza strettamente accoppiata su 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ù facile all'utilizzo di tale libreria se la soluzione interna non funzionava. Questa è una soluzione logica per un solo architetto software, ma essendo anche una forma di Project Manager con le preoccupazioni espresse dal team, avrebbe dovuto essere doppiamente una soluzione ovvia.
  • In riferimento al tuo terzo esempio: non è una cattiva idea avere un'architettura o un processo noto per produrre software (anche se, ammettiamolo, hai detto "tutti i progetti"). Questo si attiene a ciò che funziona. Detto questo, ci devono essere opportunità in cui è possibile tentare nuove tecniche per vedere se apportano un valore aggiunto. I software in-house o i progetti di portata minore in cui queste tecnologie possono essere tentate sono i luoghi ideali. Tenete presente, tuttavia, che l'onere è anche per gli sviluppatori di fornire dimostrazioni / argomenti ricercati e convincenti per l'adozione di tecnologie. E non ci si può aspettare che SA conosca tutti gli ORM in competizione e i suoi punti di forza e di debolezza rispetto agli altri.
risposta data 11.11.2010 - 20:34
fonte

Leggi altre domande sui tag