Como arquiteto de software, eu deveria me concentrar tanto em analisar os logs e corrigir os erros dos outros?

45

Desde a minha graduação (final de 2005), eu estava trabalhando para a mesma empresa como engenheiro de software c ++. Há um ano fui promovido como arquiteto de software, mas me envolvi cada vez mais na qualificação e correção de bugs, suporte de nível 2.

50% do tempo gasto no Notepad ++ analisando os logs de software e tentando descobrir o que deu errado. 30% corrigindo os erros de outros e o restante (se houver) analisando o código do spaghetti dos desenvolvedores.

Comecei a odiar este produto e a pensar numa estratégia de saída desta empresa.

O que você acha que eu posso fazer nessa situação? você outro arquiteto de software ainda está corrigindo erros no código?

    
por cpp81 13.12.2012 / 14:30
fonte

11 respostas

81

A maioria das pessoas geralmente concorda que um Arquiteto de Software deve estar envolvido principalmente em design de alto nível, estabelecendo padrões, escolhendo ferramentas ou frameworks, avaliando produtos, implementando protótipos e Provas de Conceitos, e treinando e orientando desenvolvedores

A realidade, entretanto, é que o título geralmente pode ser um compromisso político para um desenvolvedor, um título especial dado para liderar desenvolvedores de projetos, ou até mesmo algo tão simples quanto uma solução gerencial de RH para contratar um desenvolvedor tão necessário a um salário ou classifique o RH ou a alta gerência como inaceitável para o título do desenvolvedor de software ou do engenheiro de software.

Em outras palavras, os títulos são basicamente sem sentido.

    
por 13.12.2012 / 14:50
fonte
17

O artigo da Wikipédia define arquiteto de software como:

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

Dadas acima, suas estimativas "50% do tempo gasto ... analisando os logs de software ... 30% corrigindo erros de outros" colocam você longe desativado do que normalmente espera-se que o arquiteto de software faça.

  • Eu diria acima que o título que eles lhe deram sobre 50+30=80% fake.

Observe que, por si só, atividades como análise de logs ou correção de bugs de outras pessoas podem legitimamente ocupar parte do tempo do arquiteto - desde que atendam ao objetivo principal dessa função - ou seja, fazer design de alto nível escolhas e estabelecimento de normas técnicas. Na verdade, esse é o caso de qualquer tipo de atividades de desenvolvimento / manutenção / teste de software.

Por exemplo, se analisar os registros levou você a um insight sobre como tornar isso mais fácil - aprimorando o design, as ferramentas ou os padrões de codificação -, isso seria um esforço perfeitamente justificável para um arquiteto. Da mesma forma, pode ser completamente certo para o arquiteto sujar as mãos, corrigindo falhas específicas - contanto que isso resulte em melhorias específicas no design / processo, levando a uma menor taxa de erros, etc.

Em uma nota um pouco mais positiva, sua pergunta demonstra pelo menos uma habilidade que é muito importante para o arquiteto: a capacidade de classificar diferentes tipos de atividades e rastrear os esforços gastos nelas. Considere adicionar à sua "caixa de ferramentas" habilidades complementares para resumir suas observações e estimativas e comunique-as claramente, especialmente na hierarquia administrativa. :)

    
por 13.12.2012 / 14:41
fonte
5

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

Suposto para? sim e não. Você é responsável pela totalidade da qualidade do produto e pelo caminho da evolução - faça funcionar amanhã, mas também faça com que funcione no próximo ano.
Isso significa dar uma ajuda para resolver questões difíceis? Absolutamente - pelo menos eu faço. Você não pode fazer o produto funcionar amanhã se seus clientes o deixarem.
Isso significa que você deve dedicar todo o seu tempo a isso? Absolutamente não. Você é responsável pela TOTALIDADE da qualidade e evolução. Dedicar muito tempo para perseguir problemas é contraproducente.

Você deveria ser proativo:

  1. Inicie os planos de educação para que outras pessoas (dev / support) possam levantar a carga. "ensinar um homem a pescar" e todo esse jazz.
  2. Invente formas e desenvolva ferramentas para oferecer suporte à análise de defeitos mais rápida e fácil e ao isolamento de causa raiz. Se você acha que esses desenvolvedores chato, outros, possivelmente menos talentosos ou experientes, acham isso não apenas entediante, mas também difícil e talvez até assustador. Ajude-os a superar isso pela tecnologia.
  3. Inicie um esforço para elevar a qualidade do produto - simplifique, modularize, crie estruturas de teste - dê o exemplo, não choramingando e ameaçando desistir.
  4. Verifique se os desenvolvedores sabem o que você está fazendo, mas também seus gerentes. Um papel de arquiteto é muito mais sobre relações com outras pessoas do que sobre codificação e análise. Por mais que você possa odiar isso, a política é fundamental aqui. Certificar-se de que seus colegas vejam suas conquistas torna mais fácil convencê-los mais tarde de que você está certo. Se você ainda não chegou lá, devolva suas reivindicações por pesquisas e POCs.
  5. Se tudo mais falhar e somente depois de passar algum tempo tentando melhorar as coisas, fale com seu gerente. Diga que suas habilidades são melhor usadas nas fases de planejamento e design e veja o que pode ser feito para mudar a situação atual. Seu produto pode estar em apuros e a resposta do seu gerente pode ser "precisamos de você para essa coisa aqui e agora". Eu insistiria em um plano de longo prazo - como vamos mudar a situação atual?

Eu vejo o papel de um arquiteto como um privilégio. Você consegue influenciar o produto de uma forma que muitas outras pessoas não podem - o único teoricamente mais influente do que você é ele é o gerente de P & D do produto (e, possivelmente, o marketing) - mas ele é um jeito de gerenciar tudo.

    
por 13.12.2012 / 21:16
fonte
3

O papel de um arquiteto de software tradicionalmente não os impede de corrigir bugs. Os arquitetos de software ajudam a corrigir problemas de design no software, portanto, se você entender que a maneira principal como o software foi projetado se presta a mais fragilidade ou dificuldade de expansão / manutenção, seria o trabalho da SA propor ou reprojetar aspectos do software. software para resolver esse problema.

Dado o que você disse:

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.

Esse não é o papel de uma SA verdadeira e, em vez disso, é mais do que eu teria com nossos programadores nível 1 desenvolvedor e desenvolvedor 2 ao lado de um desenvolvedor sênior. Digo isso em particular porque acho que realmente ajuda os novos desenvolvedores de nossa empresa a entrar no produto e no código trabalhando nesse nível em questões de qualidade de código. Você é um novo SA em sua empresa e eles estão fazendo você fazer esse trabalho para entrar no sistema? Se sim, talvez esteja tudo bem por um curto período de tempo. Se este é o seu trabalho diário e tem sido por mais de um ano, então possivelmente é hora de procurar outro papel.

    
por 13.12.2012 / 14:52
fonte
3

Eu entendo sua frustração, mas entenda se você escreveu o código ou foi o último a tocá-lo, o tempo é curto e eles podem entrar em contato com você, muitos gerentes irão até você para consertá-lo, independentemente do seu título.

Achando que você ainda tem amigos no grupo de desenvolvimento que está em crise, você ajudará. O problema é quando eles e, mais importante, o seu gerenciamento se acostumar com você ajudando, eles continuam voltando. Como dizem, "nenhuma boa ação fica impune". Se eles puderem contar com você para corrigir os problemas, independentemente do seu título, você será apenas outro desenvolvedor e outra pessoa que eles possam usar.

É um problema difícil de resolver, mas meu conselho é:

  1. Solicite o número de cobrança para o projeto este tempo de projeto do arquiteto não de software. Acho que os gerentes de projetos não estão tão ansiosos para pedir o seu tempo, se eles precisam ser responsáveis por isso.

  2. Fale com seu gerente sobre quanto tempo está sendo perdido e para quais grupos ou projetos. Seu gerente pode lhe dizer para não ajudá-los e manter o foco em seus projetos. Se sim, então o outro grupo vem pedir ajuda, você diz que seu chefe também não disse.

  3. Organize seu trabalho, mantenha suas prioridades claras e não seja tão responsivo a sair de seus projetos de arquitetura.

  4. Aja como um arquiteto, faça com que seus colegas o vejam como arquiteto, não como o mesmo desenvolvedor que você tem sido todos esses anos. Você quebrou os outros do hábito de tratá-lo apenas como desenvolvedor.

Boa sorte.

    
por 13.12.2012 / 16:37
fonte
2

Não, você está aqui para gerenciar o quadro geral.

Você tem um problema de gerenciamento: corrigir bugs e melhorar a qualidade do código é tarefa dos desenvolvedores, como arquiteto, você deve emitir diretrizes e arquitetura real (UML ou o que flutua no barco) e fazer revisões regulares de código para garantir essas diretrizes são seguidos corretamente.

Você pode, no entanto, implementar e corrigir erros na arquitetura principal.

Exemplo: você trabalharia em PRISM, MEF etc em um projeto WPF / C #, mas não trabalharia no XAML para exibir a tela inicial.

Você trabalharia no design do banco de dados, mas não escreveria procedimentos armazenados para operações CRUD.

etc.

    
por 13.12.2012 / 14:40
fonte
1

Parte da resposta seria encontrar um engenheiro disposto a assumir essa carga.

Claro, a razão pela qual isso é um problema é que você acha este trabalho indesejável, o que não envia a mensagem de que ele é atraente para os outros engenheiros, então eles não estão ansiosos para buscá-lo.

Eu vejo duas possibilidades.

  1. Você recebeu a posição de arquiteto para trabalhar em itens de imagens maiores.
    Nesse caso, você deve mencionar à gerência que não é possível trabalhar com esses itens de imagem maiores porque ninguém deu um passo à frente para assumir a função de suporte de nível inferior. Esse é então o problema deles para resolver.

  2. O título é em grande parte cerimonial - um osso jogado para você para mantê-lo por perto.

Nesse caso, a administração pode não estar muito interessada em aliviar sua carga de suporte.

-

Uma coisa que definitivamente não será útil para o seu objetivo é adotar uma atitude de desprezo pelos outros desenvolvedores e engenheiros que vejo vazando na sua pergunta. Você quer que essas pessoas se aproximem e lidem com esses problemas com confiança para que você não precise (possivelmente cometendo alguns erros ao longo do caminho). Se eles souberem que você só vai falar mal de suas soluções e consertar isso para eles depois, eles provavelmente nunca vão avançar.

    
por 13.12.2012 / 18:51
fonte
1

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.

Este é definitivamente um tipo de trabalho que você NÃO deve fazer, para este papel. De acordo com minha experiência / observações, o arquiteto precisa estar envolvido no design de aplicativos, melhorias, esclarecimentos de requisitos técnicos e possíveis problemas de desempenho (não verificar logs todos os dias, mas analisar principalmente problemas de sever / erros) que precisam ser abordados ou evitados.

Em outras palavras, meu ponto # 1 é - os arquitetos são designers de alto nível e integradores de sistemas com experiência prática em como o funcionamento interno da tecnologia funciona / aplica e precisa ser usado.

Se você tiver a oportunidade de atribuir e gerenciar a qualidade do código, suas habilidades de gerenciamento de trabalho precisam ser melhoradas. Assim, o trabalho de planejamento deve ser sua prioridade na abordagem "como fazer o trabalho".

Ponto # 2 : se você é um dos poucos desenvolvedores nesses aplicativos - então este título é apenas mais um esmalte de açúcar da administração da empresa para mantê-lo no mesmo papel "conserte" com um novo título fantasia .

    
por 13.12.2012 / 18:45
fonte
0

O papel de um arquiteto de software é muito mais do que o que você está fazendo na sua empresa atual. Ele é responsável por definir padrões de design de software, fazer design de alto nível, padrões para codificação etc., e consertar bugs pode ser considerado apenas uma pequena parte dele, na verdade, não é. Mas como você disse, você está trabalhando em um produto, ou seja, sendo um arquiteto de software, a expectativa de você para a confiabilidade do produto será bastante alta e, nesse caso, o seu envolvimento em tais coisas não só Ajudar o produto, mas também a empresa, como você é bastante experiente nisso. Mas você também deve receber alguma exposição ao desenvolvimento de novos recursos e novas tarefas que incutirão seu interesse em sua organização atual.

    
por 14.12.2012 / 09:45
fonte
-1

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

Em uma questão de falar, "Sim".

Veja como eu qualificaria minha resposta:

  1. Por padrão, você deve permitir que os desenvolvedores de software analisem os logs e corrijam os erros.
  2. No entanto ... Você deve estar ciente dos defeitos que causaram uma perda de dados, exigir uma reversão de banco de dados onerosa, levar muito tempo para os desenvolvedores resolverem ou exigir um pedido de desculpas do cliente .
    1. Como regra, seus subordinados diretos devem informar você sobre esses defeitos.
    2. Você deve criar uma cultura na qual seus subordinados diretos se sintam autorizados para informá-lo sobre esses defeitos, mas não obrigados a falar sobre os triviais.

Mais em # 2:

  1. Esses tipos de defeitos geralmente implicam em falha na arquitetura. Quando isso acontecer, você deve entender a natureza precisa do defeito e arquitetar uma correção.
    1. Portanto, por extensão, você deve estar pronto, disposto e capaz de vasculhar os logs e corrigir os erros de outras pessoas (mesmo que você não envie diretamente o código para o repositório do código-fonte).
por 13.12.2012 / 18:45
fonte
-1

A resposta é provavelmente não. Por que você está gastando muito tempo com problemas de depuração e suporte? Alguém atribui esse trabalho a você?

Parece que você precisa esclarecer o que deveria estar fazendo. Você pode precisar consertar bugs; que provavelmente não deve ser a maior parte do seu tempo.

    
por 07.01.2013 / 21:30
fonte