Bom pessoal, vamos falar agora sobre o papel do arquiteto ou arquiteta de software. O que esse cara faz? Agora que a gente teve uma ideia mais básica, a gente falou sobre resolução, evolução, gestão, a gente falou sobre componentização. Então, aonde que o arquiteto de software se inclui no meio dessa história? Vamos lá. O que o arquiteto de software faz? Ele transforma requisitos de negócio em padrões arquiteturais. Legal? Ou seja, toda vez que você vai desenvolver alguma coisa, você vai ter que entender padrões. Um bom arquiteto entende o padrão de como a organização funciona. Muitas coisas acontecem de forma repetida. Entender padrões é entender a forma de como você vai arquitetar você vai desenvolver um prédio você sabe que você tem que ter viga você tem que ter um andar atrás do outro tudo isso vai seguir um padrão quando você desenvolve um software você vai começar a perceber esses padrões também legal quando você é um arquiteto de software normalmente você orquestra pessoas desenvolvedoras tá a e expert de domínio o que isso significa o arquiteto de software se ele não tiver perto de pessoas que entendam do domínio que vai ser resolvido né do que o software vai atender, muitas vezes o software vai ficar algo extremamente passivo. O que significa? O software vai fazer com que a organização tenha que se adaptar a ele. Por muitos e muitos anos isso acontecia. Você tinha um software e a empresa tinha que usar aquele software as-is, porque a tela, o nome, a comunicação interna do software era feita da cabeça do expert do domínio para conseguir ajudar a traduzir isso para que os desenvolvedores consigam trabalhar. Então, ele consegue fazer essa balança e essa orquestração. Ou seja, o arquiteto também tem que entender de forma profunda conceitos e modelos arquiteturais. Isso aí é um pouco complexo. Por quê? Porque você só vai conseguir entender de forma profunda esses conceitos, honestamente falando, quando você estiver dentro de um projeto. Você vai ter, inclusive, aqui toda a teoria na de tudo dos padrões de modelos etc etc mas quando você gasta a sola de sapato em cima daquilo você começa a ganhar cicatrizes e essas cicatrizes vão mostrar pra você o que funciona o que funciona, com qual tipo de time e esses tipos de coisa. Mas, obviamente, como existem padrões, você não vai ter que sair pensando em resoluções de coisas que pessoas já resolveram 10 anos atrás. Ou seja, você ganha tempo entendendo fundamentos de software mas um bom repertório né gastar a sola de sapato vai fazer muita diferença na sua carreira a dica que eu posso dar de ouro aqui pra você é muito comum você vê desenvolvedor pula pula o que é isso ele passa seis meses uma empresa oito meses na outra e vai fazer um upgrade do salário eu tô falando que é ruim isso não é muito bom tempo e grande salário é mas conseguir fazer parte de um projeto como um todo por um bom tempo dentro de uma empresa vai gerar uma segurança pra você vai gerar cicatrizes que vai fazer com que o que vão fazer com que quando você for para outro desafio você esteja muito mais consolidado desenvolvedor que pula muito rápido de uma empresa para outra raramente consegue aprender nesse processo por isso que eu sou totalmente a favor que você balancei muito o que você está fazendo com a sua carreira tá outro ponto importante é que o arquiteto de software ele ajuda no momento tomada de decisão quando nós temos alguma crise crises acontecem sistemas dão pau coisas dão erradas sistemas vão falhar né a stakeholders entendem tem têm muitas vezes, como eu posso dizer, perspectivas, eu não digo nem perspectiva, um alinhamento de expectativa diferente de quem está desenvolvendo. Nesses momentos de crise, o arquiteto de software tende a entrar nesse meio e conseguir fazer essa mediação. O arquiteto de software consegue navegar nos ambientes. Isso são soft skills também. Não existe mágica, galera. Não existe hack. Existe experiência. Por isso que existem muita gente daquela história. Lembra aquela história do sênior de dois anos? Por que muita gente critica isso, tá? E normalmente quem critica isso são sêniors. Por que que isso acontece? Essa crítica. Eu consigo entender os lados da moeda. O que que acontece? Um dev sênior de dois anos ele pode ser muito bom em codificação, ele pode ser muito bom em frameworks, ele vai conseguir entregar muitas vezes código muito mais legível, muito mais polido do que muitos sêniores de 10 anos por aí. Isso acontece de monte, eu conheço gente fantástica que tem pouquíssimo tempo de experiência. Por outro lado, novamente, olha o que eu falei para você, pouco tempo de experiência. Ou seja, esse cara não passou por momentos de crise, ele não ganhou cicatrizes, ele não passou por um repertório tão grande de resolução de problemas, que coisas que ele está pensando apenas ainda na codificação, um Devil My Senior, umLead, um Principal Engineer, você vai ver que muitos desses caras nem ficam mais programando tanto no dia a dia, porque esses caras já estão calejados e sabem lidar com determinadas situações onde apenas o código não vai resolver. Entendeu? onde apenas o código não vai resolver, entendeu? Então, sim, um dev sênior de dois anos, eu posso dizer que ele é sênior na tecnologia, mas ele não é sênior na experiência, porque experiência vem com o tempo, não existe mágica, tá bom? E outra coisa super importante, normalmente dizem, né? né a exemplo arrasta se você quer que o seu código que o código do seu desenvolvedor seja bom você tem que reforçar essas práticas de desenvolvimento esse é um padre esse é um ponto muito importante que o arquiteto de software vai ter que fazer esse cara vai ter que o arquiteto de software vai ter que fazer. Esse cara vai ter que fazer code review, esse cara vai ter que mentorar, esse cara vai ter que conseguir entender como é o comportamento do time que ele está, e fundamentalmente, ele em primeiro lugar vai ter que falar, o código daqui tem que ser bom, o nosso código, a nossa linha de qualidade é essa. Se esse cara não dá o exemplo, ninguém vai conseguir seguir nada. Vai ficar totalmente um vácuo e esse vácuo é extremamente perigoso a longo prazo. Beleza? Então esse é um dos papéis quando a gente fala em o papel do arquiteto de software. Porém, você vai perceber que algumas organizações não têm esse papel lá dentro. Vamos falar sobre isso no próximo vídeo.