O que você deve trazer para a mesa como arquiteto de software? [fechadas]

Existem muitas perguntas com boas respostas sobre o papel de um arquiteto de software (SA) no StackOverflow e Programmers SE . Estou tentando fazer uma pergunta um pouco mais focada do que essas. A própria definição de uma SA é ampla, portanto, para fins desta pergunta, vamos definir uma SA da seguinte maneira:

Um arquiteto de software orienta o design geral de um projeto, envolve-se nos esforços de codificação, realiza revisões de código e seleciona as tecnologias a serem usadas.

Em outras palavras, não estou falando de descanso gerencial e colete nos tipos de SAs (mais palavras que rimam com elides). Se eu perseguir qualquer tipo de posição de SA, não quero ficar longe da codificação. Posso sacrificar algum tempo para interagir com clientes e analistas de negócios etc., mas ainda estou tecnicamente envolvido e não estou apenas ciente do que está acontecendo nas reuniões.

Com esses pontos em mente, o que uma SA deve trazer para a mesa? Deveriam entrar com a mentalidade de "impor a lei" (por assim dizer) e impor o uso de certas ferramentas para se ajustarem "a seu caminho", isto é, diretrizes de codificação, controle de origem, padrões, documentação UML, etc.? Ou eles devem especificar a direção e a estratégia iniciais e depois recuar e pular conforme necessário para corrigir a direção do navio?

Dependendo da organização, isso pode não funcionar. Uma SA que depende do TFS para fazer cumprir tudo pode ter dificuldade para implementar seu plano em um empregador que usa apenas o StarTeam. Da mesma forma, uma SA precisa ser flexível, dependendo do estágio do projeto. Se for um projeto novo, eles têm mais opções, enquanto que podem ter menos para projetos existentes.

Aqui estão algumas histórias de SA que experimentei como forma de compartilhar alguns antecedentes, na esperança de que as respostas às minhas perguntas também possam lançar alguma luz sobre esses problemas:

• Trabalhei com uma SA que revisou literalmente todas as linhas de código da equipe. A SA faria isso não apenas pelo nosso projeto, mas por outros projetos da organização (imagine o tempo gasto nisso). A princípio, foi útil impor certos padrões, mas depois se tornou incapacitante. FxCop era como a SA encontraria problemas. Não me interpretem mal, era uma boa maneira de ensinar desenvolvedores juniores e forçá-los a pensar nas consequências de sua abordagem escolhida, mas para desenvolvedores seniores isso era visto como algo draconiano.

• Uma SA em particular foi contra o uso de uma determinada biblioteca, alegando que era lenta. Isso nos forçou a escrever toneladas de código para realizar as coisas de maneira diferente, enquanto a outra biblioteca nos pouparia muito tempo. Avanço rápido para o último mês do projeto e os clientes estavam reclamando sobre o desempenho. A única solução foi alterar determinadas funcionalidades para usar a abordagem originalmente ignorada, apesar dos avisos iniciais dos desenvolvedores. Nesse ponto, muito código foi jogado fora e não reutilizável, levando a horas extras e estresse. Infelizmente, as estimativas usadas para o projeto foram baseadas na abordagem antiga que meu projeto foi proibido de usar, por isso não era um indicador apropriado para a estimativa. Eu ouvia o PM dizer "já fizemos isso antes"

• A SA que aplicaria o uso de DTOs, DOs, BOs, camadas de Serviço e assim por diante em todos os projetos. Os novos desenvolvedores tiveram que aprender essa arquitetura e as diretrizes de uso aplicadas de forma inflexível pela SA. Exceções às diretrizes de uso foram feitas quando era absolutamente difícil segui-las. A SA foi fundamentada em sua abordagem. Classes para DTOs e todas as operações CRUD foram geradas via CodeSmith e os esquemas de banco de dados foram outra bola de cera semelhante. No entanto, tendo usado essa configuração em qualquer lugar, o SA não estava aberto a novas tecnologias, como LINQ to SQL ou Entity Framework.

Não estou usando este post como uma plataforma para ventilação. Havia aspectos positivos e negativos em minhas experiências com as histórias da SA mencionadas acima. Minhas perguntas se resumem a:

1. O que uma SA deve trazer para a mesa?
2. Como eles podem encontrar um equilíbrio na tomada de decisões?
3. Deve-se abordar um trabalho de SA (conforme definido anteriormente) com a mentalidade de que eles devem aplicar certas regras básicas?
4. Mais alguma coisa a considerar?

Obrigado! Tenho certeza de que essas tarefas são facilmente estendidas a pessoas que são desenvolvedores seniores ou líderes técnicos, portanto, fique à vontade para responder nessa capacidade também.

Um arquiteto de sistemas deve:

1. Especifique a arquitetura de alto nível
2. Participe das revisões de código
3. Aprovar tecnologias usadas
4. Ajude os desenvolvedores em seu esforço de codificação
5. Manter e monitorar o cronograma de desenvolvimento
6. Produza artefatos de SA, como diagramas UML, gráficos de Gantt e similares.

As SAs devem saber codificar e devem participar de parte do trabalho de codificação, molhar as mãos, por assim dizer. Isso os mantém em contato com a gestalt do esforço de desenvolvimento. Como o tio Bob Martin disse uma vez , o arquiteto deve fazer parte da codificação, para que ele possa ver a dor que está causando aos outros com seus projetos.

A SA deve ter a última palavra em todas as decisões de design, tecnologia e estilo de codificação. Mas, como todos os gerentes, o trabalho da SA é abrir caminho para o seu pessoal para que ele possa ser produtivo. Isso significa, na maioria das vezes, que os desenvolvedores decidem, em seu nível, como os problemas serão resolvidos. Isso significa que a SA mantém os chefes de cabelos pontudos fora dos cubículos dos desenvolvedores. E isso significa que a SA contribui para ajudar, conforme necessário.

Como todos os seres humanos, as SA podem cometer erros. Os bons aprendem com esses erros e se tornam melhores SAs.

Nunca encontrei um arquiteto que fosse útil, principalmente porque eles não eram práticos.

Para mim, os maiores problemas que já vi são:

• adesão cega ao processo por causa do processo
• tendência cega à tecnologia antes de conhecer o problema
• criação e aplicação de regras sem uma boa justificativa
• rewrite from scratch mentalidade

Os melhores "arquitetos" com quem trabalhei trouxeram para a mesa:

• Perguntas que levaram a uma melhor compreensão do problema e das possíveis soluções.
• Opções / tecnologias de design e suas vantagens e desvantagens.
• Explicações claras e racionais para condenações e endossos de projetos e tecnologias.

O problema para mim é que os melhores "arquitetos" com quem trabalhei não tinham "arquiteto no título". Eles eram na maioria das vezes engenheiros de software baseados em problemas e projetos específicos. Eles entendiam que na maioria das empresas não é " Não é prático reescrever uma base de código em funcionamento, eles tomam decisões de projeto ou fornecem opções e seus motivos ou justificativas. Eles traçam como iterar a base de código para uma nova arquitetura ao longo do tempo e ainda mantêm tudo funcional. Eles dão recomendações conservadoras em vez de recomendar o que quer que seja dejour ou familiar.Eles comunicariam uma visão coesa de como as coisas deveriam funcionar e por quê, mas mais importante ainda, mapeariam como chegar lá e o custo.

1 O que uma SA deve trazer para a mesa?

• Uma pele grossa
• Boas habilidades de negociação
• Um bom entendimento das várias camadas de software (da bondade AJAX whizzy à E / S de rede de baixo nível). Você não é necessariamente um especialista prático, mas terá que tomar decisões importantes sobre qual software deve ser executado em que camada (s).
• Disposição para sujar as mãos no código, os desenhos de papel branco simplesmente não são suficientes.
• Incentivo ao desenvolvimento de software - seja o líder de torcida para fazer as coisas da maneira certa sempre que possível e da melhor maneira, considerando as limitações de outros casos. Então, coisas como controle de origem, TDD, build e CI, DOJOs de codificação, revisões de código, um bom sistema de rastreamento de problemas etc.

2 Como eles podem encontrar um equilíbrio na tomada de decisões?

• Muito disso depende do (s) seu (s) time (s) e quão capazes eles são.
• Seu ambiente (você pode ser forçado a usar o produto de um fornecedor específico, por exemplo)
• No geral, é melhor não ser um arquiteto de torre de marfim, ser parte prática da equipe - as pessoas entenderão suas decisões dessa maneira.

3 Deve-se abordar um trabalho de SA (conforme definido anteriormente) com a mentalidade de que eles devem impor certas regras básicas?

• Sim, coisas como controle de versão e um sistema de compilação são muito importantes e os desenvolvedores precisam usá-las. No entanto, é sempre melhor fazê-los parte da solução.

Há muito mais, acho que haverá respostas realmente boas para essa.

1.O que um SA deve trazer para a mesa?

"Eles deveriam entrar com a mentalidade de 'impor a lei' ... Ou deveriam especificar a direção e a estratégia iniciais, depois serem recuadas e pular conforme necessário para corrigir a direção da nave?"

Uma combinação dos dois, eu diria. Ao decidir sobre tecnologias e processos, estar aberto a opiniões e sugestões pode fornecer um retorno / feedback valioso sobre as decisões e fazer com que você aprenda com os outros. Sua equipe é (esperançosamente) inteligente; tire vantagem disso. Mas uma vez que uma decisão (sua decisão) é tomada, a lei foi estabelecida. Identifique aqueles que reclamarão sobre o que não foi sua escolha e aqueles que escolherão qualquer coisa e não se importam - e depois os ignoram.

No que diz respeito às tecnologias: trabalhe com o que você tem, se a empresa usa o StarTeam, é isso que você usa. Casar-se com qualquer produto / tecnologia / processo em particular não fará nada por você.

2. Como eles podem encontrar um equilíbrio na tomada de decisões?

Ouvir a equipe e saber quando estão certas e erradas é importante, e ter os cojones para dizer a eles que estão errados e se ater à sua decisão. Não ouvir trará falta de respeito, assim como as suas decisões.

3. Deve-se abordar um trabalho de SA (conforme definido anteriormente) com a mentalidade de que eles devem aplicar certas regras básicas?

Sempre. Caso contrário, os detentos acabarão administrando o asilo, abertamente ou secretamente. Decidir sobre essas regras básicas, no entanto, pode ser através de conversas com a equipe. Lembre-se de que qualquer equipe pode nem sempre ter os mesmos membros que tem agora, portanto, fazer concessões para um pequeno grupo deles pode atrapalhar a equipe no futuro depois que eles se forem. Isso inclui o SA.

4.Algo mais a considerar?

• Em referência ao seu segundo exemplo: Parece que a equipe do projeto formou uma dependência fortemente acoplada a um subsistema interno. Fachadas fracamente acopladas não são apenas para código de terceiros. Criar uma abstração para esse subsistema poderia ter permitido uma transição mais fácil para o uso dessa biblioteca, se a solução interna falhar. Essa é uma solução lógica apenas para um arquiteto de software, mas também como uma forma de gerente de projeto com as preocupações de expressão da equipe, deveria ter sido uma solução óbvia em dobro.
• Em referência ao seu terceiro exemplo: não é uma má idéia ter uma arquitetura ou processo conhecido para produzir software (embora, é verdade, você tenha dito 'todos os projetos'). Isso está aderindo ao que funciona. Com isso dito, é preciso haver oportunidades nas quais novas técnicas possam ser tentadas para ver se elas agregam valor adicional. Softwares internos ou projetos de escopo menor, onde essas tecnologias podem ser experimentadas, são locais ideais. Porém, lembre-se de que o ônus também é do (s) desenvolvedor (es) para fornecer demonstrações / argumentos pesquisados ​​e convincentes para a adoção de tecnologias. E não é de esperar que a SA conheça todos os ORM concorrentes e seus pontos fortes e fracos em comparação com os outros.