Come architetto di software, dovrei concentrarmi molto sull'analisi dei log e sulla correzione dei bug di altri?

La maggior parte delle persone concorda sul fatto che un Software Architect dovrebbe essere principalmente coinvolto nella progettazione di alto livello, nella definizione di standard, nella scelta di strumenti o framework, nella valutazione di prodotti, nell'implementazione di prototipi e Proof Of Concepts e nella formazione e nella gestione di sviluppatori

Tuttavia, la realtà è che spesso il titolo può essere un appuntamento politico per uno sviluppatore, un titolo speciale assegnato agli sviluppatori di progetti, o anche qualcosa di semplice come una soluzione di gestione-risorse umane per assumere uno sviluppatore di cui si ha davvero bisogno in uno stipendio o giudicare inaccettabili le risorse umane o il management superiore per il titolo Software Developer o Software Engineer.

In altre parole, i titoli sono per lo più privi di significato.

L'articolo di Wikipedia definisce l'architetto del software come:

a computer programmer who makes high-level design choices and dictates technical standards, including software coding standards, tools, or platforms...

Dato sopra, le tue stime "il 50% del mio tempo trascorso ... analizzando i log del software ... il 30% che risolve i bug di altri" ti ha messo lontano lontano di ciò che ci si aspetta normalmente da un architetto del software.

• Direi sopra rende il titolo che ti hanno dato circa 50+30=80% fake.

Nota che di per sé attività come l'analisi dei registri o la correzione dei bug di altri potrebbero legittimamente occupare parte del tempo dell'architetto - a condizione che servano allo scopo principale di questo ruolo - cioè, progettare ad alto livello scelte e stabilire standard tecnici. In realtà, questo è il caso per qualsiasi tipo di attività di sviluppo / manutenzione / test del software.

Ad esempio, se l'analisi dei registri ti ha portato a capire come rendere più semplice - migliorando la progettazione, gli strumenti o gli standard di codifica - questo sarebbe uno sforzo perfettamente giustificabile per un architetto. Allo stesso modo, potrebbe essere completamente OK per l'architetto sporcarsi le mani fissando bug (s) particolari - a patto che ciò si tradurrebbe in specifici miglioramenti di progettazione / processo che portano ad una minore frequenza di errori, ecc.

_{Su una nota un po 'più positiva, la tua domanda dimostra almeno un'abilità che è piuttosto importante per l'architetto: la capacità di classificare attività di diverso tipo e tenere traccia degli sforzi spesi per queste. Considera di aggiungere alla tua "cassetta degli attrezzi" competenze complementari per riassumere le tue osservazioni e stime e comunicarle chiaramente, in particolare la scala di gestione. :)}

As a software architect, am I supposed to focus that much on analysing the logs and fixing other's bugs?

Dovrebbe? sì e no. Sei responsabile della totalità della qualità del prodotto e del percorso di evoluzione - fallo funzionare domani, ma fallo funzionare anche l'anno prossimo.
Ciò significa prestare una mano per risolvere problemi difficili? Assolutamente - almeno lo faccio. Non puoi far funzionare il prodotto domani se i tuoi clienti ti lasciano.
Significa che dovresti dedicare TUTTO del tuo tempo a quello? Assolutamente no. Sei responsabile della TOTALITÀ della qualità e dell'evoluzione. Dedicare così tanto tempo a inseguire i problemi è controproducente.

Dovresti essere proattivo:

1. Avviare i piani di istruzione in modo che altre persone (sviluppatori / support) possano sollevare il carico. "insegnare a un uomo a pescare" e tutto quel jazz.
2. Inventa modi e sviluppa strumenti per supportare l'analisi dei difetti più rapida e più semplice e l'isolamento delle cause principali. Se trovi questo noioso, altri sviluppatori, forse meno talentuosi o con esperienza, lo trovano non solo noioso, ma anche difficile e forse anche scoraggiante. Aiutali a superare questo problema con la tecnologia.
3. Iniziare a migliorare la qualità del prodotto - semplificare, modulare, creare framework di test - dare l'esempio, non piagnucolare e minacciare di uscire.
4. Assicurati che gli sviluppatori sappiano cosa stai facendo, ma anche i tuoi manager. Un ruolo dell'architetto è molto più relativo alle relazioni con le altre persone, quindi riguarda la codifica e l'analisi. Per quanto tu possa odiare questo, la politica gioca un ruolo chiave qui. Assicurarti che i tuoi pari vedano i tuoi successi rende più facile convincerli dopo che hai ragione. Se non ci sei ancora, sostieni le tue affermazioni tramite ricerca e POC.
5. Se tutto il resto fallisce, e solo dopo aver passato del tempo per cercare di migliorare le cose, parla con il tuo manager. Dì che le tue abilità sono meglio utilizzate nelle fasi di pianificazione e progettazione e vedi cosa può essere fatto per cambiare la situazione attuale. Il tuo prodotto potrebbe essere in un pizzico e la risposta del tuo manager potrebbe essere "abbiamo bisogno di te per questa cosa proprio qui, proprio ora". Insisterei su un piano a lungo termine, tuttavia, come cambieremo la situazione attuale.

Vedo il ruolo di un architetto un privilegio. Puoi influenzare il prodotto in un modo che molte altre persone non riescono a fare - l'unico teoricamente più influente di te è il product manager di R & D (e, possibilmente, il marketing) - ma è molto impegnato nella gestione.

Il ruolo di un architetto del software tradizionalmente non prevede che risolvano bug. Gli architetti del software aiutano a risolvere problemi di progettazione nel software, quindi se per bug si intende il modo principale in cui il software è stato progettato si presta a più fragilità o difficoltà nell'espansione / mantenimento, sarebbe compito dell'SA proporre o riprogettare aspetti del software per risolvere il problema.

Dato ciò che hai detto:

50% of my time spent in Notepad++ analysing the software logs and trying to figure out what went wrong. 30% fixing other's bugs and the remaining (if any) reviewing developers spaghetti code.

Questo non è il ruolo di una vera SA e invece è più di ciò che vorrei che i nostri sviluppatori 1 e programmatori di livello 2 iniziassero insieme a uno sviluppatore senior. Lo dico in particolare perché trovo che aiuti davvero i nuovi sviluppatori nella nostra azienda a entrare nel prodotto e nel codice lavorando a quel livello su problemi di qualità del codice. Sei una nuova SA nella tua azienda e ti stanno facendo questo lavoro per entrare nel sistema? Se è così allora forse va bene per un breve periodo. Se questo è il tuo lavoro quotidiano ed è stato per più di un anno, allora probabilmente è tempo di cercare un altro ruolo.

Capisco la tua frustrazione, ma capisco se hai scritto il codice o sei stato l'ultimo a toccarlo, il tempo è breve, e possono raggiungerti, molti manager stanno andando da te per aggiustarlo, indipendentemente dal tuo titolo.

Immaginando di avere ancora amici nel gruppo di sviluppo in crisi, aiuterete. Il problema è quando loro, e ancora più importante la loro gestione si abitua a dare una mano, continuano a tornare. Come dire "nessuna buona azione resta impunita". Se possono contare su di te per risolvere i problemi, indipendentemente dal tuo titolo, sei solo un altro sviluppatore e qualcun altro che possono usare.

È un problema difficile da risolvere, ma il mio consiglio è:

1. Richiedi il numero di addebito per il progetto per questo tempo di progetto dell'architetto non software. Trovo che i project manager non siano così ansiosi di chiedere il tuo tempo, se devono essere responsabili per questo.

2. Parla al tuo manager di quanto tempo si perde e di quali gruppi o progetti. Il tuo manager potrebbe dirti di non aiutarli e rimanere concentrato sui suoi progetti. Se è così, allora arriva l'altro gruppo e chiede aiuto, digli che il tuo capo non ha detto troppo.

3. Organizza il tuo lavoro, mantenendo chiare le tue priorità e non essere così reattivo all'esterno dei tuoi progetti di architettura.

4. Agisci come un architetto, fai in modo che i tuoi pari ti vedano come un architetto, non come lo stesso sviluppatore di tutti questi anni. Hai infranto gli altri dell'abitudine di trattarti solo come sviluppatore.

Buona fortuna.

No, sei qui per gestire il quadro generale.

Hai un problema di gestione: correggere bug e migliorare la qualità del codice è compito degli sviluppatori, come architetto dovresti pubblicare linee guida e architettura reale (UML o qualsiasi altra cosa galleggi la tua barca), quindi dare regolari revisioni del codice per garantire queste linee guida sono seguiti correttamente.

Potresti, tuttavia, implementare e correggere i bug nell'architettura core.

Esempio: lavorerai su PRISM, MEF ecc in un progetto WPF / C #, ma non funzioneresti su XAML per visualizzare lo splashscreen.

Lavoreresti su DB design ma non scriverei stored procedure per le operazioni CRUD.

ecc.

Una parte della risposta sarebbe trovare un ingegnere che sia disposto ad assumersi questo carico.

Ovviamente, il motivo per cui questo è un problema è che ritieni che questo lavoro sia indesiderabile, che non invia il messaggio che è attraente per gli altri ingegneri, quindi non sono desiderosi di prenderlo neanche.

Vedo due possibilità.

1. Ti è stata assegnata la posizione di architetto in modo da poter lavorare su immagini più grandi.
   In questo caso, dovresti menzionare alla direzione che non sei in grado di lavorare su questi elementi di immagine più grandi perché nessuno ha intensificato per assumere il ruolo di supporto di livello inferiore. Questo è il loro problema da risolvere.

2. Il titolo è in gran parte cerimoniale - un osso lanciato per tenerti in giro.

In questo caso, la gestione potrebbe non essere terribilmente interessata ad alleggerire il carico di supporto.

-

Una cosa che non sarà utile per il tuo obiettivo è l'adozione di un atteggiamento di disprezzo nei confronti degli altri sviluppatori e ingegneri che vedo trapelare nella tua domanda. Volete che queste persone si facciano avanti e gestiscano con sicurezza questi problemi in modo da non doverlo fare (probabilmente facendo degli errori lungo la strada). Se sanno che stai solo svaligliando le loro soluzioni e sistemandole per loro in seguito, probabilmente non lo faranno mai.

50% of my time spent in Notepad++ analyzing the software logs and trying to figure out what went wrong. 30% fixing other's bugs and the remaining (if any) reviewing developers spaghetti code.

Questo è sicuramente un tipo di lavoro che NON dovresti fare, per questo ruolo. Secondo la mia esperienza / osservazioni, architect deve essere coinvolto nella progettazione delle applicazioni, miglioramenti, chiarimenti dei requisiti tecnici e potenziali problemi di prestazioni (non controllando i log ogni giorno, ma analizzando principalmente sever issues / errori) che devono essere affrontati o evitati.

In altre parole, il mio punto 1 è - gli architetti sono i progettisti di alto livello e gli integratori di sistemi con esperienza pratica su come funzionano e si applicano i meccanismi interni della tecnologia.

Se hai la possibilità di assegnare e gestire la qualità del codice, allora le tue capacità di gestione del lavoro devono essere migliorate. Pertanto, il lavoro di pianificazione dovrebbe essere la tua priorità sull'approccio "come fare il lavoro".

Punto # 2 : se sei uno dei pochi sviluppatori su queste applicazioni - allora questo titolo è solo un'altra glassa di zucchero da parte del management dell'azienda per mantenerti nello stesso ruolo "aggiustalo" con un nuovo titolo di fantasia .

Il ruolo di un architetto del software è molto più di quello che stai facendo nella tua attuale compagnia. È responsabile della definizione degli standard di progettazione del software, della progettazione di alto livello, degli standard per la codifica, ecc. E la risoluzione dei bug può essere considerata solo una piccola parte di esso, in realtà non lo è. Ma come hai detto, stai lavorando su un prodotto, significa che, essendo un architetto del software, l'aspettativa da parte tua per l'affidabilità del prodotto sarà piuttosto alta, e in tal caso, il tuo coinvolgimento in tali cose non solo aiuta il prodotto ma anche l'azienda, poiché ne hai abbastanza esperienza. Ma dovresti anche avere una certa esposizione per lo sviluppo di nuove funzionalità e nuovi compiti, che inculcheranno il tuo interesse per la tua organizzazione attuale.

As a software architect, am I supposed to focus that much on analyzing the logs and fixing other's bugs?

Per parlare, "Sì".

Ecco come definirei la mia risposta:

1. Per impostazione predefinita, dovresti consentire agli sviluppatori di software di analizzare i registri e correggere i bug.
2. Tuttavia ... devi essere consapevole dei difetti che hanno subito una perdita di dati, richiedere un rollback del database oneroso, richiedere molto tempo agli sviluppatori per risolvere o richiedere scuse da parte dei clienti .
   1. Di norma, i tuoi rapporti diretti dovrebbero farti conoscere tali difetti.
   2. Dovresti creare una cultura in cui i tuoi rapporti diretti si sentano potenziati per informarti di tali difetti, ma non costretti a parlarti di cose di poco conto.

Altro su # 2:

1. Questi tipi di difetti generalmente implicano un errore architettonico. Quando lo fanno, devi capire la natura precisa del difetto e architettare una correzione.
   1. Quindi, per estensione, devi essere pronto, disponibile e in grado di setacciare i log e correggere i bug di altre persone (anche se non impegni direttamente il codice nel repository del codice sorgente).

La risposta è probabilmente no. Perché spendi così tanto tempo per il debug e i problemi di supporto? qualcuno ti sta assegnando questo lavoro?

Sembra che tu abbia bisogno di chiarire che cosa dovresti fare. Potrebbe essere necessario correggere i bug; probabilmente non dovrebbe essere la maggior parte del tuo tempo.