Come architetto del software, dovrei concentrarmi così tanto sull'analisi dei registri e sulla correzione degli errori degli altri?

Dalla mia laurea (fine 2005) ho lavorato per la stessa azienda di ingegnere informatico c ++. Un anno fa sono stato promosso come architetto del software, ma mi sono trovato sempre più coinvolto nella qualifica e nella correzione di bug, supporto di livello 2.

Il 50% del mio tempo trascorso in Notepad ++ analizza i registri del software e cerca di capire cosa è andato storto. Il 30% corregge i bug degli altri e il resto (se presente) rivede il codice spaghetti degli sviluppatori.

Ho iniziato a odiare questo prodotto e a pensare a una strategia di uscita da questa azienda.

Cosa pensi che possa fare in questa situazione? altro architetto del software risolve ancora bug nel codice?

La maggior parte delle persone generalmente concorda sul fatto che un architetto del software dovrebbe essere coinvolto principalmente nella progettazione di alto livello, nella definizione di standard, nella scelta di strumenti o framework, nella valutazione dei prodotti, nell'implementazione di prototipi e Proof Of Concepts e negli sviluppatori di formazione e tutoraggio

La realtà, tuttavia, è che il titolo spesso può essere un appuntamento politico per uno sviluppatore, un titolo speciale dato a guidare gli sviluppatori di progetti o anche qualcosa di semplice come una soluzione di gestione-risorse umane per assumere uno sviluppatore gravemente necessario con uno stipendio o tasso che Le risorse umane o la direzione superiore sarebbero inaccettabili per il titolo di sviluppatore di software o di ingegnere del software.

In altre parole, i titoli sono per lo più insignificanti.

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

un programmatore di computer che fa scelte di progettazione di alto livello e detta standard tecnici , inclusi standard di codifica software, strumenti o piattaforme ...

Dato sopra, le tue stime "Il 50% del mio tempo speso ... analizzando i log del software ... 30% correggendo i bug degli altri" ti mettono molto lontano da ciò che normalmente dovrebbe fare l'architetto del software.

• Vorrei dire sopra rende il titolo che ti hanno dato sul 50+30=80%falso.

Si noti che attività come l'analisi dei registri o la correzione di bug di altri potrebbero legittimamente occupare parte del tempo dell'architetto - a condizione che questi servano allo scopo principale di questo ruolo - vale a dire, fare scelte di design di alto livello e stabilire standard tecnici. In realtà, questo è il caso di qualsiasi tipo di attività di sviluppo / manutenzione / test del software.

Ad esempio, se l'analisi dei registri ti portasse a capire come renderlo più semplice - migliorando gli standard di progettazione, di attrezzamento o di codifica - questo sarebbe uno sforzo perfettamente giustificabile per un architetto. Allo stesso modo, potrebbe essere completamente OK per l'architetto sporcarsi le mani risolvendo particolari bug, a condizione che ciò comporterebbe miglioramenti specifici di progettazione / processo che portino a un tasso di bug più basso, ecc.

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

Come architetto del software, dovrei concentrarmi così tanto sull'analisi dei registri e sulla correzione degli errori degli altri?

Supposto di? sì e no. Sei responsabile della totalità della qualità del prodotto e del percorso evolutivo: fallo funzionare domani, ma fallo funzionare anche l'anno prossimo.
Significa dare 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 il tuo tempo a quello? Assolutamente no. Sei responsabile della TOTALITÀ della qualità e dell'evoluzione. Dedicare così tanto tempo alla ricerca dei problemi è controproducente.

Dovresti essere proattivo:

1. Avviare piani di istruzione in modo che altre persone (sviluppo / supporto) possano sollevare il carico. "insegnare a un uomo a pescare" e tutto quel jazz.
2. Inventare modi e sviluppare strumenti per supportare analisi dei difetti più rapide e semplici e l'isolamento delle cause. Se lo trovi noioso, altri sviluppatori forse meno talentuosi o con esperienza trovano questo non solo noioso, ma anche difficile e forse persino scoraggiante. Aiutali a superare questo con la tecnologia.
3. Inizia uno sforzo per aumentare la qualità del prodotto - semplifica, modularizza, crea quadri di prova - conduci con l'esempio, non lamentando e minacciando di smettere.
4. Assicurati che gli sviluppatori sappiano cosa stai facendo, ma anche i tuoi manager. Un ruolo di architetto riguarda molto più le relazioni con altre persone, piuttosto che la codifica e l'analisi. Per quanto tu possa odiare questo, la politica gioca un ruolo chiave qui. Assicurarti che i tuoi colleghi vedano i tuoi risultati rende più facile convincerli più tardi che hai ragione. Se non ci sei ancora, sostieni le tue richieste di ricerca e POC.
5. Se tutto il resto fallisce e solo dopo aver trascorso del tempo a 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 si può fare per cambiare la situazione attuale. Il tuo prodotto potrebbe essere 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: come cambieremo la situazione attuale.

Vedo il ruolo di architetto un privilegio. Puoi influenzare il prodotto in un modo che molte altre persone non riescono - l'unica teoricamente più influente di te è il suo responsabile R&D del prodotto (e, possibilmente, il marketing) - ma è un modo di gestire il lavoro.

Tradizionalmente, il ruolo di un architetto del software non prevede la correzione di bug. Software Architects aiuta a risolvere i problemi di progettazione nel software, quindi se per bug intendi il modo in cui il software è stato progettato si presta a maggiore fragilità o difficoltà nell'espansione / manutenzione, sarebbe compito della SA proporre o ridisegnare gli aspetti della software da risolvere per quel problema.

Dato quello che hai detto:

Il 50% del mio tempo trascorso in Notepad ++ analizza i registri del software e cerca di capire cosa è andato storto. Il 30% corregge i bug degli altri e il resto (se presente) rivede il codice spaghetti degli sviluppatori.

Questo non è il ruolo di una vera SA e invece è più di quello che vorrei che i nostri programmatori di livello sviluppatore 1 e sviluppatore 2 iniziassero insieme a uno sviluppatore senior. Lo dico in particolare perché trovo che aiuti davvero i nuovi sviluppatori della nostra azienda a entrare nel prodotto e nel codice lavorando a quel livello su questioni di qualità del codice. Sei una nuova SA nella tua azienda e ti stanno facendo fare questo lavoro per entrare nel sistema? Se è così, forse è OK per un breve periodo. Se questo è il tuo lavoro quotidiano ed è stato per più di un anno, allora è probabilmente il momento 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 andranno da te per risolverlo, indipendentemente dal tuo titolo.

Supponendo che tu abbia ancora amici nel gruppo di sviluppo in crisi, aiuterai. Il problema è quando, e soprattutto la loro gestione si abitua a dare una mano, continuano a tornare. Come dice "nessuna buona azione rimane impunita". Se possono contare su di te per risolvere i problemi, indipendentemente dal tuo titolo, sei solo un altro sviluppatore e qualcun altro può usare.

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

1. Chiedere il numero di addebito per il progetto in questo momento del progetto di un 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 con il 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ì, poi arriva l'altro gruppo e chiede aiuto, dite loro che anche il vostro capo ha detto di no.

3. Organizza il tuo lavoro, mantenendo chiare le tue priorità e non essere così sensibile ai tuoi progetti di architettura.

4. Comportati come un architetto, fai vedere ai tuoi colleghi come architetto, non come lo stesso sviluppatore in cui sei stato in tutti questi anni. Hai rotto gli altri con l'abitudine di trattarti come sviluppatore.

In bocca al lupo.

No, sei qui per gestire il quadro generale.

Hai un problema di gestione: correggere i bug e migliorare la qualità del codice è il compito degli sviluppatori, in quanto architetto dovresti pubblicare le linee guida e l'architettura effettiva (UML o qualsiasi altra piattaforma galleggiante), quindi fornire periodiche revisioni del codice per garantire che queste linee guida siano seguite correttamente .

Tuttavia, è possibile implementare e correggere bug nell'architettura di base.

Esempio: lavoreresti su PRISM, MEF ecc. In un progetto WPF / C #, ma non lavoreresti su XAML per visualizzare la schermata iniziale.

Lavoreresti sulla progettazione di DB ma non scriveresti le procedure memorizzate per le operazioni CRUD.

eccetera.

Parte della risposta sarebbe trovare un ingegnere disposto a sostenere questo carico.

Ovviamente, la ragione per cui questo è un problema è che trovi questo lavoro indesiderabile, il che non invia il messaggio che è attraente per gli altri ingegneri, quindi non sono nemmeno desiderosi di prenderlo.

Vedo due possibilità.

1. Ti è stato assegnato il ruolo di architetto in modo da poter lavorare su oggetti più grandi.
   In questo caso, dovresti dire al management che non sei in grado di lavorare su questi elementi più grandi perché nessuno si è 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 a te per tenerti in giro.

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

-

Una cosa che sicuramente non sarà utile per il tuo obiettivo è adottare un atteggiamento di disprezzo per gli altri sviluppatori e ingegneri che vedo trapelare nella tua domanda. Vuoi che queste persone si intensifichino e gestiscano con sicurezza questi problemi in modo da non dover (eventualmente fare degli errori lungo la strada). Se sanno che non riuscirai più a risolvere le loro soluzioni e a risolverle in seguito, probabilmente non aumenteranno mai.

Il 50% del mio tempo trascorso in Notepad ++ analizza i registri del software e cerca di capire cosa è andato storto. Il 30% corregge i bug degli altri e il resto (se presente) rivede il codice spaghetti degli sviluppatori.

Questo è sicuramente un tipo di lavoro che NON dovresti fare, per questo ruolo. In base alla mia esperienza / osservazione, l' architetto deve essere coinvolto nella progettazione dell'applicazione, miglioramenti, chiarimenti sui requisiti tecnici e potenziali problemi di prestazioni (non controllo dei registri di tutti i giorni, ma principalmente analisi di problemi / errori gravi) che devono essere affrontati o evitati.

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

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

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

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

Come architetto del software, dovrei concentrarmi così tanto sull'analisi dei registri e sulla correzione degli errori degli altri?

In una questione di parlare, "Sì".

Ecco come qualificherei la mia risposta:

1. Per impostazione predefinita, è necessario consentire agli sviluppatori di software di analizzare i log e correggere i bug.
2. Tuttavia ... È necessario essere consapevoli dei difetti che hanno comportato una perdita di dati, richiedere un rollback del database oneroso, impiegare molto tempo per la risoluzione degli sviluppatori o richiedere scuse ai clienti.
   1. Di norma, i rapporti diretti dovrebbero informarti di tali difetti.
   2. Dovresti creare una cultura in cui i tuoi rapporti diretti si sentano in grado di parlarti di tali difetti, ma non sei obbligato a parlarti di problemi insignificanti.

Altro su # 2:

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

La risposta è probabilmente no. Perché stai dedicando così tanto tempo al debug e ai problemi di supporto? Qualcuno ti sta assegnando quel lavoro?

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