Conteúdo original em https://twitter.com/zanfranceschi/status/1681112067934396416
Ei dev,
Algumas pessoas me perguntam sobre arquitetura – pedem algum direcionamento, livros, cursos, etc.
Tenho cerca de 10 anos de experiência atuando exclusivamente com arquitetura e o começo foi difícil porque é uma disciplina sem muito material explicitamente dedicado.
↓
DISCLAIMER 1: O assunto aqui é arquitetura de sistemas, integrações, solução. Não é sobre a organização de código – arquitetura de aplicação, software.
DISCLAIMER 2: É o meu ponto de vista, a minha experiência individual.
Vou começar pela conclusão: é uma disciplina/área que dificilmente no início você vai se sentir preparada/o.
Se já estiver dando seus primeiros passos nessa direção e tiver aquela sensação de estar perdida/o, saiba que isso é mais normal do que imagina.
EXPERIÊNCIA PRÁTICA
Arquitetura (ou "System Design" que está mais na moda) é difícil praticar porque os desafios estão justamente na escala, no longo tempo de execução dos sistemas, na operação, etc. Coisas que um localhost ou apenas uma conta na AWS não vão te oferecer.
ABRANGÊNCIA DE CONHECIMENTO
Cada empresa pode – e geralmente vai – exigir diferentes níveis de conhecimento em diferentes subáreas para quem exerce a disciplina de arquitetura. Existem empresas com times dedicados à rede, então p.ex. uma arquiteta talvez não precise conhecer [+]
muita coisa ou até mesmo não tenha autonomia para decisões nessa subárea. O mesmo pode acontecer com bancos de dados, armazenamento, identificação/autenticação/autorização, etc.
Na minha experiência, geralmente quanto maior a empresa, mais as coisas já estão resolvidas por times dedicados.
Em empresas menores, geralmente você terá uma atuação mais abrangente e aprofundada – você precisará conhecer mais sobre mais coisas.
CONTEXTO
Um desenho pode funcionar muito bem em uma empresa, mas não em outra. O código de uma API tem mais chances de funcionar bem em mais lugares. Arquitetura é sobre contexto: vendors, suporte, operação, orçamento, infra, etc. Já um código é algo mais especializado/focado.
Você precisa desenhar a solução de acordo com as ferramentas, suporte, conhecimento das pessoas, e qualquer outro tipo de recurso disponível para aquele contexto. Não adianta colocar Kubernetes que funciona super bem para uma empresa numa empresa que não tem a capacidade e/ou [+]
intenção de manter uma tecnologia dessas. gRPC pode ter sido uma escolha muito boa na sua empresa anterior, mas na atual pode simplesmente não fazer sentido. E assim por diante.
Ou seja, contexto e restrições – que podem ser a mesma coisa no final do dia.
HÁ ESPERANÇA
Mas nem tudo é uma mudança drástica ou uma experiência completamente diferente de empresa para empresa. Com o passar do tempo e acúmulo de experiência, você nota que muitas coisas mais fundamentais são iguais nos desenhos de solução de diversas empresas.
Vê-se que para um tipo de cenário, p.ex. o processamento assíncrono é mais adequado, e usar Kafka, RabbitMQ, uma fila em banco de dados é mais um detalhe de implementação. E assim o é com muitas outras coisas – segurança, processamento em lote, redes pública vs privada, etc.
Ou seja, a cada novo desenho, novo projeto, você pode aprender mais um pouquinho e usar um pouco do que já aprendeu. É um ciclo que vai – mais ou menos rapidamente dependendo da sua exposição à coisas novas – preenchendo alguns buracos de conhecimento dessa estrada.
CARGO/DISCIPLINA
Algumas empresas possuem o cargo para arquitetura, outras empresas incorporam a arquitetura como uma disciplina aplicada pela engenharia. No começo, não se preocupe muito com títulos, se preocupe com o aprendizado.
E COMO APRENDER?
A pergunta de milhões! Não existe uma resposta, mas uma forma de aprender é manter a curiosidade, buscar entender como as coisas funcionam. Se você é dev, procure entender onde e como as aplicações que desenvolve funcionam. Se envolva com times e pessoas com [+]
conhecimentos diferentes dos seus. Fale com DBAs, pessoal de segurança, de foundation, etc. Se junte com pessoas que exercem a disciplina de arquitetura. Tente fazer um desenho de algo que já sabe como poderia funcionar – talvez algo mais simples no início.
Arquitetura/System Design é uma jornada gradual e às vezes mais ambígua do que programação justamente pela quantidade das dimensões/interpretações que podem ser menos objetivas para um desenho (pessoas, contratos, restrições, suporte, etc.).
Tenha paciência! Eu nunca vi uma arquiteta ou arquiteto júnior, mas todo mundo envelhece e fica mais experiente. 🙃
E muito obrigado por ter lido até aqui! ♥️
Top comments (3)
Parabens por mais um artigo de qualidade!!!
conteudo top zan
Muito bom!!! Eu já sou do "outro lado", a arquitetura de software hahaha gostei muito das explicações