Legal, gente. Então, obrigado aí, Léo, obrigado Wesley, time da FUSAI, por me convidar mais uma vez. Então, para mim é sempre um privilégio falar e trazer os cases aqui da Conta Azul. Então, o pedido da gente hoje, o nosso papo vai ser sobre projeto. É um pouco controverso, a gente vai falar ali, tem uma parte da apresentação que a gente vai conversar, e vocês vão entender por que eu usei essa palavra controverso, né, tem pessoas que fazem uma carinha feia quando falam de problema de software, e tem outras que não, já defendem ali com incidentes que tem que acontecer, tá? Mas antes ali eu vou falar de mim, então, meu nome é Rafael Dantz, normalmente o pessoal me chama de Dantz, porque Rafael é um nome que é igual a rato, você encontra em cada esquina, igual a barata. Aqui na Conta Azul mesmo tem uma época que tinha quase 10 Rafael. Mas esse meu sobrenome me carrega ali de altas empresas que eu trabalhei. Eu sou natural de Salvador, Bahia. Eu tenho 25 anos de experiência na nossa área. Comecei ali no ano 2000 com o Softing Clipper, porque eu estou vendo aqui que tem uns de cabelo branco aqui que devem saber o que eu tô falando, né? Então, cara, tá aí, ó. Então, gente, era ali a telinha preta lá, não tinha praticamente mouse, tá? E aí depois eu fui evoluindo com o tempo, tá? Então, Delphi, bastante Java, tá? Então, front-end também eu brinquei bastante ali com as três principais hoje, né? Minha preferência particular é Vue, sem, sem haters, tá? Eu gosto muito do Vue.js ali do ecossistema, mas, cara, React, o Mesh, o Angular também. E no Backend ali, basicamente, meu dia a dia hoje tem sido bastante Golang, tá? E Java, tá? Aqui na conta azul é as duas stacks principais que a gente tem. E no mobile ali, basicamente, eu trabalho bastante com Flutter, mas já mexi com a Ionic, já mexi com as loucuras ali também do dia a dia. Minha função atual aqui na Conta Azul é ser arquiteto de software, ou barra soluções. Então, a gente tem aqui um time de arquitetura, somos quatro arquitetos, e eu sou arquiteto responsável pela frente de Framework Cross. Nós temos outro arquiteto ali de sistema financeiro, que cuida ali de bank e outras coisas voltadas pro financeiro, e temos dois arquitetos ali no software legado da Conta Azul, que é o software principal, né? Que é o RP na nuvem, tá? Então, pra quem conhece a Conta Azul, ali seria isso, tá? Eu vou falar um pouco da Conta Azul pra vocês. Se alguém perguntou alguma coisa, eu não consigo enxergar aqui, deixa eu ver se eu consigo mover, acredito que seja isso mesmo. É isso mesmo, sobre eu, né, eu parei aqui pra falar um pouquinho de mim, tá, então, baiano, comedor de acarajé com pimenta, então, meus amigos aí conterrâneos, estamos aí, tá bom? Fala da Conta Azul, tá, gente? Conta Azul ali, ela foi fundada em 2012, tá? É uma empresa, é um SaaS de software, uma RP em nuvem, e ela tá expandindo o negócio dela, tá? Então, ela tá virando um banco também, então ela recebeu a licença ali pra poder atuar como banco, então estamos ali agora virando também uma conta digital, e também tem outras frentes também, né, que a gente tá especializando no software ali, com conta IA e abrindo caixa de entrada ali pra trabalhar com IA, então você coloca um, por exemplo, você coloca uma nota lá e ela já vai ser lançada lá no teu financeiro, usando IA, então tem uma frente nova aí, bem legal, que a Conta Azul tá trazendo. Então, falando em Conta Azul, ela é sediada em Joinville, em Santa Catarina. Então, é uma empresa que tem uma cultura muito forte, muito bacana. Então, o que me motiva, principalmente na empresa, é essa cultura. Ela aproxima realmente as pessoas. Então, vocês viram aqui essa fotinha que eu estou aqui na parte onde fica a engenharia, o mezanino. Embaixo aqui tem comida, tem bolinha, tem videogame. E aqui fica a parte do pessoal de vendas e comercial. Então tem esse bumbo aqui, não sei se esse é o nome correto, o pessoal fica batendo ali quando bate meta, canta música, sabe? Os donos da Conta Azul, os executivos da Conta Azul não tem sala dos executivos, não só aquele pessoal que passa engravatado, você tinha medo de falar, eu trabalhei set Sétima Petrobras, eu vi esses executivos, você tinha que ficar meio assim, dar um bom dia, uma boa tarde pro pessoal, o da Conta Azul não, ele senta, ele toma café com você, ele pergunta, eu acho que é gongo o nome disso, né? Você bate, aquele negócio lá, meio oriental, né? E aí eles falam com você, realmente são bem próximos ali, é bem legal, tá? Então, isso é bem forte. E assim, e também falando de tecnologia, né? Conta Azul também, ela tem estado na vanguarda ali de boas práticas na nossa área, então é bem legal quando você entra na Conta Azul, você aprende bastante coisa, tá? Ela tem um onboard, uma imersão muito legal. Sem contar, cara, o pacote de benefícios e tudo mais é uma empresa muito boa isso de trabalhar. Está em evolução constante e sempre ali batendo suas metas e tudo mais. É bem bom trabalhar na conta azul. Tá, gente? Falando da empresa em si. Beleza? Mas vamos falar do nosso objetivo de hoje, tá bom, gente? Nós vamos falar de projeto, tá bom? Não vamos falar de código hoje, mas isso vai refletir no código do futuro. Então, eu dividi em duas partes nossa apresentação de hoje. A primeira parte é o que eu vou falar é do dia a dia da empresa. Então, gente, se vocês se identificarem com alguma coisa, ah, você não concordou com isso, ou eu concordo com aquilo, fiquem à vontade para abrir o microfone e a gente vai conversar, tá? E hoje eu vou falar da maioria das empresas que a gente trabalha que não tem documentação, não tem um padrão definido de documentação no seu ciclo de desenvolvimento. Tem uma barrinha aqui na tua perna de ver os comentários. Se alguém está falando, deixa eu jogar para cá, agora eu vejo. Vou falar primeiro ali da metáfora do abismo, não sei se você já ouviu falar dessa metáfora do abismo. Que existe nos times entre front e back. Então, vamos já dizer que a gente está no nosso fluxo de desenvolvimento. E aí, cara, chegou lá um card para a gente executar. Vamos criar uma tela, vamos criar um endpoint, né? Mas não tem lá muita definição daquilo que vai ser feito, né? No máximo tem um protótipo ali, feito no Figma ou algo parecido por alguém, mas ali não tem definido como é que vai ser o contrato e, cara, aí o back tem que chamar o front, o front tem que chamar o back, tá, me diz o contrato do endpoint que você vai mandar, como vai ser ele, o cara também não sabe como expor os dados direitos pro front-end, né, quem nunca viveu isso, né? Isso é uma coisa bem comum em nossa área, tá? Já vi várias vezes a gente ter que refazer telas e refazer trabalhos justamente por causa desse tipo de problema ou seja, já fomos meter a mão sem saber o que ia fazer não amolamos o machado primeiro então, essa é uma realidade que eu acredito que alguns de nós vivamos até hoje, não sei quem de vocês aí quiser levantar a mão aí, gente, eu vivo isso fica à vontade hoje, né? Não sei quem de vocês aí quiser levantar a mão aí. Gente, eu vivo isso. Fica à vontade aí, tá? Vamos fazer a documentação via chat no Skype, chat no Teams. É. E é... Me manda esse parâmetro e deu. Entendi. E quando chega um card aí, já vamos fazer um feature novo aí, né? Normalmente já chega ali com o endpoint, como é que vai ser? Chega uma telinha lá mais ou menos, ou só o desejo? Vamos fazer isso aqui e tá tudo bem? Pelo menos aqui é muito organizado onde eu trabalho, né? No FBank. Tem que vir lá da galera de produto, tem que... Aí passa pelo Tech Lead, o Tech Lead pega as tasks, tudo bonitinho e segue o processo, entendeu? Agora, documentação é mais complicado. Documentação técnica, né? Porque de produto tem, mas técnica... É isso, é exatamente isso. Documentação de produto, boa. O meu estilo é time de produto, é milagre. É Deus nos ajude, é isso aí. Quem nunca ouviu documentação, sou de produto, é milagre. É Deus nos ajude aí sim. Quem nunca ouviu documentação, sou de hoje, né? Quem nunca ouviu, não conhece, né? Eu tenho uma camiseta, assim. É? Pronto. Então, gente, vou falar também aqui de um outro tema, bem parecido com esse, né? O cara tá ali codando, não sabe os requisitos direito, às vezes nem tem um BDDzinho, alguma coisa que o produto colocou no card, dado que eu sou isso, eu quero aquilo outro, né? Não, só chega lá no card, eu tenho que fazer aquilo outro, né? Então, normalmente, às vezes, a gente tem documentação de produto, pedido que eles querem, mas o cliente ali, a gente que está na cozinha fazendo a comida, às vezes o garçom nem sabe o que o cliente pediu lá na mesa e a gente já vai falar, tá, o cara quer uma caixa mal passada, beleza. Vou fazer aqui do jeito que eu acho, né? Então, é uma realidade também que a gente colga muitas vezes no escuro, né? Então, chega ali uma demanda meio estranha pra gente e a gente, cara, tá, beleza. Como é que eu vou fazer isso aqui? como o cliente realmente quer. Exatamente, gente. É isso aí. Boa. BDD é quase um milagre, isso é verdade. Documentação é sempre deixar de lado. Documentação que é isso, perfeito, gente. E essa foto é verdadeira, deve back-end. É isso aí, cara. É a próxima coisa. Dantas, uma pergunta. Você costuma ver a documentação vindo primeiro de produto ou desenvolvimento? porque a gente como desenvolvedores costuma mais fazer documentação não sei de outras áreas mas você chega a ver produto passando da documentação? boa Max, excelente pergunta aqui na conta azul a gente tem duas esteiras de desenvolvimento. A primeira chama-se Flux Upstream. O que é o Flux Upstream? É o fluxo de ideação. O produto chega com uma ideia. Isso é discutido ali com arquitetura e tech leads. E uma etapa do fluxo da esteira de desenvolvimento no upstream é fazer o projeto técnico. Tem a esteira de produto, que ele faz todos os requisitos, e tem a esteira do desenvolvimento técnico, ou seja, o tech lead e o arquiteto fazem a documentação daquele projeto. E o que a gente faz? Quando vai sair para o fluxo de downstream, que acontece ali a quebra das atividades, vamos fazer um endpoint aqui, então tem um back. O front vai fazer tal tarefa aqui. Então, a história está ali, mas a gente consegue quebrar ela. Normalmente, o que o Nantes faz? Cara, eu faço lá, eu tiro um print do meu documentação, vou mostrar pra vocês como é que eu faço, e colo no card. Já tem tempo que eu venho fazendo isso e, cara, depois que eu comecei a fazer os devs, até o Júnior me agradecer, eu prefiro muito mais olhar a documentação técnica do que ficar lendo todo aquele produto ali, sabe? Então tem ajudado bastante ali, justamente esse é o foco do que eu gostaria de passar para vocês hoje, é esse sentimento, é essa visão, sabe? Esse é o meu objetivo, entende? Não sei se eu respondi o que você queria. Matheus, você abriu ali a mãozinha, quer falar alguma coisa? Boa noite. Eu queria só, entrando um pouco mais nesse ponto, entender como que isso, com que granularidade que essas coisas acontecem, como que se enquadra dentro de uma metodologia ágil, tipo assim, com que cadência as coisas vão acontecendo aí dentro. Aqui na conta azul a gente tem um scrum ban, a gente não tem nem scrum, nem kanban. É a mistura dos dois. Como é que funciona esse ciclo de desenvolvimento aqui na Conta Azul? Ele ocorre a cada 45 dias. Ocorre uma cerimônia chamada PI Planning. Nessa PI Planning, os times se reúnem e elaboram ali tudo o que vai olhar, o que eles já tinham puxado do upstream para levar para a API, e aí eles quebram ali, estimam, e aí leva para a diretoria o que vai ser executado naquele próximo ciclo de 45 dias. E aí existe o time de COI aqui que vai acompanhando e tudo mais. Então, a API que começou, aquilo é o ciclo downstream. Mas na API anterior é o fluxo de upstream que a gente vai estudar, que é aquilo que eu falei, é a esteira de estudo, entende? E nessa esteira que está acontecendo agora tem uma outra esteira de upstream para abastecer o backlog para o próximo, entende? Então a gente usa aqui na conta azul o Gira, para gerenciar isso, então tem Gira Plane, tem o Gira lá, dashboard, e aí a gente vai e consegue ver ali tudo, os stick-roders conseguem mapear e conseguem acompanhar essas métricas e como é que tá andando. Ah, já andamos tanto, foi criado novas tarefas que não tava mapeado, caiu, alguns carros caíram também, entendeu? A gente consegue ver isso aí também. Tem um amigo meu que é da Conta Azul, que disse que ia apoiar na live, ele que é o fera de agilidade. Não sei se ele está aí, o Zilli, ele falou que ia participar. Ele é um cara extremamente fera nesse tema. Então, se vocês quiserem evoluir em qualquer coisa, chamem ele lá no LinkedIn dele, é o Júnior Zilli. Olha ele aí. Estou aqui, mas estou sem câmera. Qualquer coisa, se vocês quiserem saber, ele que foi o pai na conta azul ali, de criar todo esse fluxo de desenvolvimento, de piar, ele foi o pai que criou a piar, então ele é o cara, tá? Então, qualquer coisa, fala com ele aí. Beleza? Gente, alguma pergunta sobre isso aqui? Senão eu vou avançar aqui, tá? Pra gente ir conversando mais. O que essa imagem diz pra vocês aqui, gente? conversando mais. O que essa imagem diz pra vocês aqui, gente? Eu já vi ali falando de gambiarra, né? Quem nunca tem seu fusquinha, que a gente passa mais um arame e anda mais 10 quilômetros, né? Quantas vezes o produto, às vezes, nem tem paciência, espera a gente entender o que vai pedir, já tem que entregar, porque o time to market tá muito alto, tem que entregar logo lá, o cliente está esperando a empresa vai faturar e às vezes a gente entrega ali uma gambiarrazinha para a gente não ficar mal queimado mal visto pela empresa e cara, mas imagine o problema que a gente está armendando esse carro para andar mais 10 quilômetros mais 10 quilômetros então eu acho que isso é um dia a dia de todos nós. Então, qual o problema que a gente tem com isso que eu coloquei ali? Na arquitetura fica muito estável. Vai chegar uma hora que a manutenção desse código vai ficar inviável. E tanto o band-aid, arame e esparadrapo que a gente coloca no software. Parece que isso vai ficar padrão. para começar a falar o pai alguém abriu aí o microfone pode falar eu ia falar sobre a questão da arquitetura vocês utilizam algum padrão de arquitetura ou vocês desenvolveram a própria arquitetura é uma boa desenvolver a própria arquitetura dependendo da solução interna da Conta Azul, por exemplo? Excelente, excelente pergunta. Na Conta Azul, a gente criou o padrão de arquitetura, o padrão arquitetural. Quando me pediram para criar esse padrão há uns dois anos atrás, mais ou menos, três anos, eu fui muito baseado no clima arquiteto. Só que aí,, eu fui muito baseado no arquiteto. Só que aí, como eu fui muito purista, o pessoal começou a reclamar que estava codando muita coisa a mais que não tinha na cidade. Então, eu já sabia que tinha outro time também aqui que trabalhava na Conta Azul com a Exágora, que foi uma empresa que a Conta Azul adquiriu. O cara também tinha esse mesmo problema de tá? De codar, às vezes pra fazer um reposito eu tenho que codar dois, três arquivos aqui, né? E aí eu estudei o Simplocan Arquiteto, não sei se vocês já ouviram falar, tem um pesquisado depois, e aí eu montei todo o padrão arquitetural da Conta Azul, padrão de pacote, padrão de nomenclatura, voltado em cima dele. E a galera aceitou muito bem. Então, a gente consegue monitorar, a gente consegue colocar no CI as violações de camadas. Eu não trouxe isso hoje, mas eu acho que é um tema bem bacana. É Simple Clean Architecture. É a versão do Clean Architecture mais simples. Então, cara, muito bom. Acho que vale a pena vocês darem uma olhada. O código realmente fica legível. Os pacotes ficam realmente onde deveriam estar, tá? E até para o Debra, que é um raciocínio ali de como ele vai colocar cada coisa que lugar, fica muito mais fácil e o desenvolvimento muito mais rápido, tá? Eu tenho bastante ali, bastante isso, assim, que eu tenho. É isso mesmo. É isso que eu estou passando em um projeto meu que eu vim muito da clean arquitetura, eu estava eu desenvolvia bastante, eu gosto por que me pareça, eu até sei só que eu não vou colocar um hexagonal que é mais fácil vou primeiro implementar aqui, só que o meu viés é clean arquiteto, eu quero separar tudo naturalmente na minha cabeça, e é meio complicado, sabe? Vou dar uma olhada nesse simple. Vale a pena. Eu sou um cara um pouco assim, eu não aposto muito no Garzaguna, não, mas assim, não existe bala de prata, né? A gente já viveu bastante ali pra entender que, cara, é igual Lego, né? Cada átomo quadrado, círculo no círculo, triângulo no triângulo. Então, vamos colocar as coisas pra funcionar. Hoje a gente tem muita linguagem generalista, né? Goleng, generalista, Java, generalista, .NET também tá sendo. Então, tá muito abrindo também .NET também está sendo. Então, dá muito a ver também de outros fatores que não é a linguagem, por exemplo, pessoal capacitado para trabalhar, por exemplo. Quantidade de treinamentos no mercado, empresas que fornecem treinamento sobre aquela stack ou aquele determinado paradigma. Então, eu acho que esses fatores que vocês têm que começar a pensar também, para tomar decisão. Alguém abriu o microfone? Sim, Dantas. No caso, em relação à arquitetura, você conseguiria citar momentos em que você viu que a arquitetura não estava funcionando e chega no momento em que você precisa revisar? Que pontos você conseguiria levantar? viu que a arquitetura não está funcionando e chega no momento em que você precisa revisar, que pontos você conseguiria levantar? Aconteceu aqui algumas vezes de a gente pegar, principalmente coisas de software legado, que a gente faz que... Casos como isso, né? Foi feito sem projeto, né? Foi feito gorroce, né? Cara, normalmente o que é que eu faço? Eu não reaproveito nada. Eu sempre falo, demore a casa que está mal feita e constrói outra. Normalmente a gente usa técnicas de estrangulamento. Eu faço divisões ali, um quantidade de pessoas vão ficar com um fluxo de AB, um quantidade de pessoas vai continuar no fluxo antigo, outro vai começar a entrar no fluxo novo. E, cara, sempre, sempre, quando eu estou envolvido, eu prezo pelo projeto, por mais simples que ele seja, por mais simples que a feature seja, eu não preciso fazer um projeto rebuscado. Às vezes vem uma história de usuário ali, um épico para a gente fazer, não precisa de um projeto complexo, como eu vou mostrar a vocês ali. É só um diagramazinho, mas pelo menos tem. O importante é ter. Porque, seriam sinceros, quem aqui desenvolve uma coisa e um mês depois, com tanta coisa que passou, consegue levar no mínimo os detalhes que você fez um mês atrás? Eu não lembro. No caso, você comentou que é fazer meio que do zero dependendo da situação você chega a fazer algum estudo de impacto na empresa, da solução alguma coisa desse tipo como seria esse estudo? normalmente quando eu vejo eu vou sempre na dor. Normalmente a gente é focado na dor. Qual é a dor que eu quero resolver? Então, o que eu vejo ali? Qual é a dor que eu tenho hoje para não criar outra dor? Eu tenho que resolver a dor que a gente tem hoje e ainda brilhar do outro lado com uma coisa mais performática. E aí, normalmente, eu estudo o que está acontecendo hoje e monto a estratégia para poder esse cara deixar de existir e ser substituído por uma coisa melhor. Esse é o modo basicamente padrão da forma que eu trabalho ali quando tem uma mudança. Não sei se é isso que você queria ouvir. Sim, só um pouquinho mais a fundo, só para... Esse termo dor, você coleta algum tipo de dado para identificar essa dor, não sei, quantidade de usuários, quantidade de desenvolvedores? Normalmente, o que eu olho? Vamos falar de software de back-end, por exemplo. Olho as métricas de throughput, de APDX, infraestrutura, eu olho muito, o pessoal aqui na Conta Azul, desculpa a palavra Me chamam de tarado da performance Eu fico olhando ali o CPU Em memória, eu fico ali contando As coisas E aí se não estiver me agradando Eu vou logo lá e, gente, não está me agradando Isso aqui, vamos rever Será que esse sistema aqui vale mesmo Valeu a pena ter feito em Java? Será que não fazia sentido fazer em Go? Então, tem alguns times aí que a gente na Contasul ainda tem esse tipo de mentalidade. E tudo bem, não tem nenhum tipo de imposição. Mas eu vou muito no dado, tá, Marcos? Eu gosto muito de me embasar e tomar uma decisão baseada nos dados. Eu não fico muito no empírico, não, no machismo, porque argumentos virão. Quando você está embasado de dados, cara, não dá fatos no argumento, entende? Já vivemos bastante ali e, cara, cada vez que eu cheguei amarelo, vamos dizer, falar assim, velho, o pessoal vinha com um argumento mais forte, como é que eu ia me embasar em quê? No meu sentimento? Não, você tem que ir aqui, ó, é isso aqui que eu tô embasado. O cliente ali tá reclamando, cuidado de chamado, os devs estão demorando de encodar, entende? Por exemplo, eu vou dar um exemplo aqui pra você entender. Eu fui, no ano passado, me pediram pra eu ajudar pra ajudar o time de de né? E aí ah tinha tava usando e cara era muito pra contar um feature às vezes um feature levava uma semana uma simples uma semana enquanto um feature em gol usando o né? E o nosso que a gente fez aqui cara eu levo uma hora duas horas assim no máximo pra uma mediana uma grande quatro horas no máximo assim de profiana, uma grande quatro horas no máximo, de estar de profissão, entende? Então, existe essa diferença, sem contar a satisfação das pessoas, né? Trabalhar com uma coisa mais organizada, trabalhar com uma coisa dentro de um padrão, onde você sabe que tem pessoas, foi definido, tem um estudo, tem uma inteligência, gasta em cima daquilo, entende? Não sei se eu consegui aprofundar o quanto você queria agora. É o meu xará, Senna. Fala aí. Beleza? Tudo bom? Bom, eu sou da área de RP também, tá? Já tem mais de 20 anos aí. Trabalho na Ares, que é a lítia americana, né? E a gente passa por várias formas, a gente ainda tem software legado também, e estamos fazendo vários estudos. Passamos pelo hype do microserviço, mas como é grande o projeto, ele ainda não passou por esse momento, e talvez não passe, depende muito do modelo. Mas é por isso que eu queria perguntar para você, para tentar ter uma ideia, né, de como que vocês trabalham para ver se eu consigo passar algo mais interessante para o pessoal ali. se eu consigo passar algo mais interessante para o pessoal ali. Por momentos nossos, é que cada cliente, ele tem o seu executável, muitos deles tem servidores próprios e não vão largar esse osso, tá? É vantajoso para eles. E tem outros clientes que estão em estruturas de nuvem, certo? Diferente, acredito, da empresa que já começou na nuvem. Não sei. Estou pressupondo, tá bom? Mas o que eu queria entender? No caso seus, vocês têm um software na nuvem, seus clientes são tenantes, qual que é a média de acesso dos clientes, vocês têm um throughput de dados muito grande, qual que é o balanceamento aí? Para falar assim, é mais vantajoso estar num processo de nuvem, ou não, ou por exemplo você pode manter o seu núcleo do RP e os serviços que necessitam de alguma escala partir para uma estrutura em nuvem não sei se eu consegui passar bem, mas só para ter uma ideia assim, ó vou falar um pouco antes da conta do eu estava indo a uma empresa que era software jurídico passar bem, mas só para ter uma ideia. Assim, vou falar um pouco antes da conta, eu estava indo a uma empresa que era software jurídico, e ela era 100% on-premise, você tinha que levar o executável lá para o servidor, Ministério Público, Tribunal de Justiça, né, e, cara, monitoramento era tudo feito por eles, a gente monitorava muito pouca coisa. E aí, quando a gente começou a migrar para a cloud, né? Fazer os microserviços e tal, aí a gente começou a ter um monitoramento. Mesmo construindo em microserviços, a gente fazia um priming. Estava o call e class lá e tudo mais, tá? Que eu acho que também pega um pouco da tua realidade. E um Prime sempre é um pouco mais complicado. Você está na infra da pessoa. Então, tem vários fatores ali, tem perdicionamento, horário, tem várias coisas que implicam nisso aí. E a Cloud, quando é tua, eu acho que você tem que entender assim, falando entre monolito e microserviços. Gente, microserviços está na hype? Está. Sempre teve, passou tempoiços está na hype? Está. Sempre teve. Faz tempo que já está. Mas a premissa principal de trabalhar com microserviços, toda a literatura que você lê, é ter um ambiente estável. Não adianta você querer ir para microserviços tendo uma infraestrutura péssima. Depois não é automatizado. Cara, é uma dor de cabeça no Caito S, é uma dor de cabeça em vários lugares. Isso vai transformar a sua vida mais complicada do que você ter um código monolito. Era melhor que você tivesse um monolito. E uma outra coisa, uma outra coisa também é, não construa monolitos distribuídos. Tem gente também que tem esse costume de querer construir monolitos distribuídos. Ah, eu estou trabalhando com microserviços, mas a mentalidade ainda está de monolito. Então, a mentalidade para você migrar, virar chave para microserviços é, cara, o meu microserviço de estoque, ele tem ali o domínio de estoque. Então, ele é o responsável por tudo voltado para estoque. Eu não tenho que ter venda dentro dele, eu não tenho que ter... Ah, mas no estoque ali eu tenho que ter o nome do produto e eu tenho outro microserviço de cadastro. Tudo bem. Ok. Foi você que definiu o seu domínio. Mas não tem nenhum problema você ter uma parte desses dados de produto aqui dentro do stock, porque faz parte do domínio de stock. Então, você vai ter que manter essa sincronização toda vez que o dono, o pai, dono da informação do produto, exemplo, mandar aqui, você vai pegar uma quantidade desses dados, não todos, não faz sentido você ter toda a entidade, você tem que ter uma parte dessa entidade aqui que faz sentido para você. A mesma coisa com o cliente, tem um cadastro de clientes, é um microserviço. Aí eu tenho 90 e tenho nota fiscal, por exemplo, são outros microserviços separados. Eu tenho que ter ali os dados de cliente que fazem sentido para a venda e os dados do cliente fazem sentido para a fiscal. É muito comum fiscal tem que funcionar sozinho, independente do cadastro estar funcionando ou não. O de venda tem que funcionar sozinho, independente do cadastro estar funcionando ou de cadastro funcionando. Isso é resiliência. Tá, gente? Trabalha com micro serviço, é isso. É uma virada de chave que as pessoas, muitas vezes, estão tão acostumadas a trabalhar com código monolito que não entendem ainda. Aí Dentro de um monolito, é um outro chamando o microserviço. Aqui na Contas, eu tenho, tá? São uns códigos legados aí que são monolitos distribuídos. Beleza? Beleza. Só mais uma coisinha. Com relação, por exemplo, como a gente trabalha com vários clientes, dependendo de cada cliente, principalmente na parte fiscal, tem tem suas peculiaridades, correto? E como que dentro de uma estrutura que mesmo são microserviços, e como que dentro dessa estrutura eu consigo trabalhar com cliente X, Y, Z, sendo que cada um tem uma peculiaridade própria que é só dele e que não deveria ser exibida para outra por exemplo. Eu vou pedir para você dar uma olhada bastante na questão de multitenância. Multitenância. Tem várias estratégias, não tem a certa e a errada. Como diz, não existe alguns grátis. Se você for colunar, tem os prós e contras. Se você partir por bancos separados, tem os seus prós e contras também. Então, eu acho que por mais que você tenha um SaaS, um software RP que vai ser generalista, para atender a maioria dos clientes, mas sempre um cliente ali vai pedir uma personalização. E aí você vai tratar essa especialização, como se dizia assim, com técnicas de multitenância. Naquele cliente ali eu tenho essa configuração. Tá? Tá certo. Se você tem vários clientes pequenos, você consegue jogar dentro de um banco, né? Mas provavelmente se você tem um cliente muito grande, ele vai exigir um banco próprio. Exato. Isso aí é já bem... Mas era mais isso e assim, quantos de acesso que vocês têm por dia ali no seu serviço, ele chega a ser algo preocupante com relação a escalar horizontalmente? Ou não? Como a gente trabalha com Kubernetes e tem uma configuração já voltada para trabalhar com microserviços, o Autoscape funciona, o HPA aqui funciona. O que a gente configura aqui? 80% de uso. Tanto CPU quanto memória. Chegou naquele limite de 80%, ele vai lá e escala novos pods para dar conta. Só que, assim, os pods são horizontais, não são verticais. É a boa prática de trabalhar com microserviços. Se você não trabalha com escala vertical, tem uma falta maior da... Não faz sentido. Mas, Rafa, vamos pedir ali. Acho que o Leandro e eu já avançamos ali. Já tem o quê? 40 minutos? Desculpa. Não, não. Se você quiser mais, você me pergunta mais Pode me chamar no LinkedIn Eu vou mandar Algumas questões Valeu Valeu Então Doutor Eu tenho uma pequena empresa aqui de guarda de documento Eu sou C-Level da empresa De 15 funcionários É um negócio Não muito escalável. Mas é o que eu vi você falando aqui, a hora que você implementou o Simple Cleaner Architecture, aplicou para o Go, mas não para o Node. Como é que funciona essa divisão da empresa? Excelente. Pô, assim, quando eu criei o padrão baseado no Simple Cleaner Architecture, eu miei o padrão, baseado no Simple King Tethering, também eu mudei um pouco ali, baseado também nas outras experiências que eu tive, Petrobras e SoftPlan. Mas, cara, funciona independente desse deck. Entende? Então, isso é legal por vários fatores. Migrar um dev de um outro time pro outro, a base de código é a mesma. Certo? O cara, quando for ler um código Java, ler um código Go, é o meu padrão de pacotes e pastas. Camadas. Então, ele não tem aquela carga cognitiva pra ficar mudando. Ah, agora em Go eu tenho lá CMD e internals. Até um pessoal que entrou recente que manja muito de Go, né? Que aprendeu o padrão oficial de pacotes ali que a comunidade usa, quando eu olhei o padrão da conta, eu falei, mas isso aqui não é para legal, não, cara. Estou acostumado com semelhante interno, mas isso aqui é muito viajado de água. Não, vai estudar ali o simple content, dá uma olhadinha ali para entender melhor, qualquer coisa, vamos ali, a gente bate um one-on-one ali, toca uma ideia e explica mais. Cara, aconteceu bastante aqui. Mas aí, esse tipo de definição de arquitetura não é bem compartilhado aí? Ou é você que define para as outras áreas? Ou cada língua tem o seu arquiteto? Não, foi definido. Neste caso, eu fui escolhido para poder definir o padrão da empresa, e aí eu pedi, eu divulguei para os outros arquitetos, e pedi a ajuda de um outro arquiteto, daqui para me apoiar no teste dos times dele. Cara, eu vou testar nos meus aqui, que é Go e Java, e você testa no seu e do Java, e a gente junta as opiniões e vamos refinando ali o padrão de código. E aí, quando definiu, já era. Todo mundo vai ter que seguir aquele padrão. Indepenente da linguagem. Chique. Muito obrigado, Jorge. Valeu, valeu. Galerinha, eu vou avançar aqui, viu? Tem mais uma treta aqui, ó. Essa imagem, gente, é a imagem do terror, essa é a que mais me mete medo. Essa eu gerei com o chat GPT, tá? Me gera uma imagem de um sistema escorando na madeira com um monte de usuário dentro. Imagine a nossa gambiada de todo dia. Essas madeiras ali embaixo, gente, que a gente faz todo dia, a gente não tá vendo. Daqui a pouco o Dom Domingo Peixe vai lá, vamos fazer aquele estacionamento de carro também, um botão andar, a gente vai começar a botar carro ali dentro também do nosso prédio. Será que essas madeiras que a gente fez aguentar? Essa é uma preocupação ali. Então, quanto mais usuários tem seu sistema, mais risco você tem de... Mais exige que você faça as coisas com qualidade, com capricho, com atenção, com padrão. Por que isso acontece? Por que essas coisas acontecem ainda hoje? A gente está tão evoluído tecnicamente. Cara, falta de cultura. Principal fator. Falta de cultura. A empresa não tem criou essa cultura. O bom que o Leo acabou de falar, ele é um silério, ele já tem uma mentalidade mindset bem maior até que o meu. Quando ele ouve isso aqui e já está na cabeça dele Galera, a gente precisa criar o nosso padrão aqui Vamos botar ferramentas aqui no CICD Pra, ó, violou o padrão, não vai o PR pra frente É isso aí, gente É simples o negócio, funciona Uma vez, há muito tempo atrás Eu ouvi um chefe, era um senhor de idade já Ele falou pra mim Ele falou, Dantas, usuário e desenvolvedor tem que andar igual o curral. O boi não anda no curral, você tem que determinar o caminho dele ali. Se você soltar o boi no pasto, ele vai pra qualquer lugar. Ele não vai pra onde você quer. Ele vai clicar onde não é pra clicar, ele vai desenvolver do jeito que não tem que desenvolver, é a mesma coisa. Então, a gente como especialista, vocês estão fazendo a pós aqui, imagina que as três turmas que estão aqui, liderança técnica, MBA, pós e gol, cara, vocês são especialistas. Vocês estão estudando para ser especialistas. Então, vocês são os caras referentes, entende? E isso aí, o Sonar ajuda bastante. A ferramenta que eu falei ali, tem o Struct 101, que a Sonar comprou recentemente. Cara, fantástica a ferramenta. Você mapeia visualmente ali o seu padrão de pacotes, cara. Se der uma violação, ela te dá um relatório visual. Esse arquivo aqui, não deveria chamar esse aqui, tá? Falta de ferramentas, como eu falei, que visualizem e ajudem a ter esse padrão. Então, tem o ArcUnit também, que é Java e tem Google também. E muita gente de mentalidade. Mentalidade é uma coisa muito difícil, muito pessoal. Já ouvi isso aí. Depois a gente arruma. Quem nunca lá ouviu essa, né? O código é a documentação. A vida de um arquiteto me dizia isso. Falei, cara, não e a documentação, o código sou eu. Ou a documentação sou eu de hoje, né? E o meu negócio é só mexer no código. Tem muitas pessoas, devs, né? Ah, eu só quero saber de código, eu só quero saber disso aqui. Negócio de documentação, não é a minha praia, não. Negócio de codar. Então, esses são os principais fatores de que as empresas não têm documentação. Entende, gente? Faz sentido o que eu falei, galera? Ó, joinha aí. Beleza? Vou seguir, tá? Qual é a solução, Dantas? Você vai pedir pra gente escrever o código da menina lá, dos anos lá, da década de 1900 e bolinha que fez o código pra ir pra lua? Não, não tô pedindo isso. Ninguém vai pegar isso aí e vai ler isso aí. Eu lembro quando me vieram as documentações, umas RFC que o pessoal começou a fazer aqui para inovar, que me vieram umas bíblias assim eu falei, cara, não vou ler isso não é uma versão resumida aí para mim é uma versão pocket aí eu falei, gente, equilíbrio é tudo uma frase que os dois falaram, equilíbrio é tudo outra frase que eu gosto de usar bastante a perfeição se encontra na simplicidade quando você começa a construir castelos, com certeza vai ter um calabouço lázinho pra você ficar preso lá dentro. Então o código tem que ser simples, lindo, clean code ali, bem descritivo, com os métodos separadinhos, com responsabilidade separada, obedecer o solid, vai fazer aquilo dali que ele nasceu pra fazer. Quando você começar a ter essa maturidade, gente, vocês vão ver que vai ficar tudo mais fácil. E nós somos seres visuais. Já pensou se essa placazinha aqui de, sei lá, qualquer placa dessa aqui, fosse toda a placa de dança, fosse uma placa enorme com um descriptivo ali dizendo que você não pode fazer isso, não pode fazer aquilo outro. Ninguém ia parar pra ler aquilo ali. Eu tô ali a 80, eu não vou ver o que tá ali. Eu não vou ler. Então, quando eu vejo ali um E com dois X, eu sei que é proibido parar isso na semana. É mais fácil, né? Nós somos assim seres visuais. Então, é muito mais fácil eu ler um diagrama do que abrir uma base de código e sair lendo para entender o que é base de código. Não é verdade? Se você me der o software aí, se você me der o diagrama, eu sei que o seu software faz. Então, a primeira ferramenta que eu queria falar com vocês hoje se chama C4Modal. Quem já ouviu falar dela? Levanta a mão aí. Não? Nunca ouviu falar? Está o link ali, C4Modal. Tá, gente? C4Modal é bastante usado aqui na Conta Azul. Nos cursos da Fullcycle tem também. O Wesley fala bastante. Cara, é a minha preferida. Wesley fala bastante cara, é a minha preferida por isso que eu já trouxe logo a minha primeira ela consegue abranger todas as camadas do teu software C4 porque ela tem quatro níveis, primeiro é o contexto depois é o container, depois é o componente e depois é o código então vou ter que desenhar muito assim? às vezes você faz uma vez só e copia e colada outras vezes você faz muito projet só e copia e colada outras vezes. Dantas, você faz muito projeto, seus são sempre muito desenhados e tá muito caprichados. Eu falei, cara, mas às vezes você acha que eu levo um dia pra fazer isso aqui? Cara, eu já fiz uma vez, eu copio e colo, ajusto ali e faço o desenho diagrama que eu quero fazer e entrego. É trégua, é muito rápido. Entende? Quando você já está na veia de fazer, cara, vai fluir que nem água, tá bom? Ela é muito focada em arquitetura de software, tá gente? Ela deixa a comunicação clara. E eu dei um exemplo aqui, ó. Resumando o C4Mod, o que que ele é? Imagine o mapa do Brasil. O mapa do Brasil é o nosso país, né? Então, você está vendo ali todos os est Estados. Ali, tá vendo um negócio bem global. Esse é o teu contexto. Meu contexto é o mapa do Brasil. Cara, eu quero dar uma olhadinha agora na Bahia. Então, eu vou lá e olho ali, ó. Dentro do Brasil, eu tô olhando agora ali o mapa da Bahia. Eu quero dar mais um zoom. Agora eu vou lá e olho o mapa da minha cidade, Salvador. Olha ali, Salvador. Mas agora eu quero olhar o meu bairro. Vou ali agora que olha o meu bairro. Então eu consigo ver do macro pro micro. Ou imagine um carro, né? Você tá ali e tá vendo o capô do carro. Ah, eu quero ver o que tá dentro. Eu abro o capô do carro e tô vendo dentro, é o nível 2. Ah, eu vou abrir ali o cabeçote do motor. Tô olhando ali o nível 3. Não, agora eu vou abrir ali, sei lá, caixa de fusívelzinhos, entende? Então, começa a ver o do macrozão e começa a ver no micro ali. Matheus levantou a mão. Quer falar, Matheus? Fala aí, Maninho. Só para entender um pouco melhor sobre essa parte do contexto, isso está alinhado de alguma forma ao que a gente vê sobre o contexto do domain-driven design, do contexto delimitado? Sim. Ou não tem necessariamente? Depende. Depende de como a tua empresa organizou. Porque às vezes tem a questão do contexto, né? Ali que o pessoal aplica muito o DDD bem raiz. Às vezes casa o contexto do teu projeto com o contexto de negócio ali que você agregou no DDD. Entende? Eu tô falando de contexto de venda. Mas às vezes é um microserviço o contexto. Que é o Mas, às vezes, é um microserviço o contexto. É o exemplo que eu vou mostrar a vocês aqui. Perfeito. Tá bom, gente? Qual a sua opinião sobre as ferramentas de código para gerar os diagramas, ferramentas case? Cara, eu já, no passado, eu já usei ferramenta case. Aqui na Bahia tem uma bem famosa que é a Maker One. O pessoal fazia um diagrama ali, gerava front, back, banco, pintava o set. Dá uma cabalhota, fazia, e o terror. Mas eu ainda sou mais fazer, eu fazer. Entende? Eu sou um pouco cético até com o uso da IA ainda, tá? Eu ainda não tô crente de que a Skynet vai fazer tudo sozinha, não, tá? Como algumas pessoas acham que 100% do código vai sair ali, eu digo duas palavrinhas, ou um prompt ali, um pouquinho mais de 10 linhas, e ele vai fazer tudo, tá? Tem gente que tá fazendo hoje, tem a caixa do Figma, vai fazer tudo, tá? Tem gente que tá fazendo hoje, tem a caixa do Figma, tem gente que tá fazendo até aqui na conta, às vezes tá experimentando bastante, e a IA tá ajudando bastante isso aí, tá? A gente pedir ela gerar o código, mas às vezes ela alucina, ela gera um código que a gente não fez, isso tá muito ligado também ao prompt, aí a gente vai entrar numa discussão muito de IA que vai muito, aí, tá? Tem sim, tem ferramentas ali, plant o ML, tem uma galerinha que usa também coda e ele gera o diagrama. Também já vi isso aí também, tá? A gente experimentou aqui. Gente, aqui na conta azul tem o C4 como padrão de código e também tem um outro chamado MDL. O site tá fora hoje, eu tentei acessar ali, tava meio fora, queria trazer pra vocês, mas o link está ali. Eu uso o MDL bastante ali para quando eu vou fazer o famoso papel de pão. O C4 eu uso quando eu vou fazer o projeto em si. O MDL, foi até um outro arquiteto que trouxe, é assim, Dantas, vamos sentar com o pessoal de produto aqui para a gente discutir o que o projeto vai fazer. A gente vai bater aqui, o que vai fazer isso. Então, olha esse diagrama aqui do lado direito. Está vendo? Isso é o fluxo. Basicamente, o fluxo resumido de negócio junto com a aplicação, o que a aplicação vai fazer. Então, também tem me servido bastante usar o MDL. Nesses casos, rascunhos iniciais, papel de pão, sabe? Tem pessoas que usam ele em todos os... um C4 melhorado ali, que faz todas as camadas, tá? Tem gente que não gosta do C4, mas tudo bem, não tem nenhuma obrigatoriedade, mas eu acredito que na empresa de vocês, vocês queiram ter um padrão ali onde as pessoas sigam e faz sentido pra mim, tá? Gente, vou mostrar aqui o projetinho que eu fiz pra vocês, tá? Vou mostrar aqui o projetinho que eu fiz para vocês. Vou mostrar aqui um exemplo para vocês verem ali. De um MDL. O que eu pensei aqui? Vou criar um microserviço que resolve um problema para mim. Qual problema que eu tenho hoje? O pessoal do Java vai saber. Eu tenho ali os Chrome Jobs. Concorrência de Chrome Jobs. Eu tenho ali um Chrome Jobjobs, né? Concorrência de cronjobs. Eu tenho ali um cronjob que vai ter vários pods ali ou várias instâncias do meu microserviço e aí todos eles vão disparar no mesmo horário ali o cronjob e aí como é que vai ser tratar a concorrência do banco, quem acessou o quê? Aí eu tenho que fazer lock na mão ou eu tenho que buscar ferramentas externas que fazem isso, que a gente sabe que existe no mercado, ou fazer técnicas rebuscadas ali no código. Então, muitas pessoas estão fazendo o quê? Ou delega isso para um cara externo, até no Cal8S, tem lá a parte de Chrome Jobs, ou na própria Cloud, AWS, GCP também tem isso, ou tem gente que cria o seu próprio microserviço de agendador de jobs, né? E o meu caso aqui foi isso. Vou criar um microserviço pra galera ver aqui como seria a documentação. Então, um MDL ali, ó, o que vai ser esse cara ali? Como é que eu vou cadastrar ali o fluxo de cadastro? Então, primeiro o usuário solicita a criação, tá aqui o nosso bonequinho, chama ali a via portal interna enviada para o meu API Gateway, que é redirecionada para o meu microserviço, esse aqui é o domínio dele, ele cria o job ali dentro do banco, o banco retorna o resultado, o microserviço processa o resultado do banco e retorna o resultado para o usuário. Simples, rápido, papel de pão, entende? Muito fácil de fazer, se está discutindo com alguém vai ser, vamos dar um rascunho aqui. Esse cara serve para pintar. C4 ali, você vai ter um tamanho maior, porque você vai ter que fazer todas as camadas. Entende, gente? Viram aqui, gente, alguma dúvida do MDL? Vai tranquilo? Tranquilo, né? Bem simples. E aqui, eu vou mostrar a vocês aqui um exemplo de um C4. Camada de contexto. Cara, eu tô vendo ali o meu contexto, o meu domínio, né? Schedule Jobs. É o meu cara que é responsável por gerenciar esses jobs agendados. Ele não tá dizendo que é microserviço, que é banco, que é front, ele não tá dizendo nada. Tá dizendo que é o contexto, que é o que o Matheus perguntou, é o domínio, certo? Tem Matheus perguntou, é um domínio, certo? Tem um personal admin que realiza os grudes dentro desse domínio e o que esse cara faz? Chama microserviços. Bem basicamente, tá? Se eu clicar aqui, eu vou entrar, eu vou abrir o capô do carro. O que é que eu tô vendo aqui que tem ali dentro desse domínio, né? Ah, eu tenho um front-end envio JS, que é o portal interno do administrador, que é onde o admin acessa. Eu tenho um microserviço ali em Go, que é o back-end desse serviço. E eu tenho um banco de dados fósseis ali, com um banco desse cara. Ah, legal. E quem chama os outros serviços ali, os SEIAs e Payments, é esse cara. Entende? Eu comecei a ver aquilo que era o mapa do Brasil, come miúdo. Ah, mas eu quero ver mais miúdo ainda. Então, eu vou aqui, ó, no banco, eu quero ver o DR do banco. Então, eu consigo ver ali, ó, se tivesse umas tabelas, se tivesse relacionamento e tudo mais, você estaria vendo ali as suas entidades. Certo? Mais um? Claro. Tá bom, hein? Se eu botar a tela cheia, tá me ajudando. Melhorou? Pronto, show. Então, aqui eu tenho um DR do meu banco, beleza? Aí, se eu voltar aqui pra container, voltei pra aquela camada superior, eu quero ver aqui o meu mockup das minhas telas. Uma coisa legal, gente, que eu tenho feito, que tem dado bastante resultado. Lembra daquele probleminha do abismo entre o back e o front? Eu resolvi assim, ó. Depois eu comecei há uns dois, três anos a fazer aqui na Conta Azul esses modelos, cara, nunca mais eu tive problema e os front-end tantas foram melhor que o que tu começou a fazer, cara. Quando é de softwares internos da Conta Azul, front-end interno, eu mesmo faço no capital, mas quando é de coisas externas para os clientes, e tela, mas quando é de coisas externas para os clientes, já vem o pessoal de design pronto, o que eu faço? Eu tiro uma foto do Figma, coloco aqui e eu faço ligar aqui. Então eu consigo dizer para o front como é que ele vai fazer a tela e como é o contrato que ele vai se seguir na tela. Ou o back-end já sabe também o contrário, como é que vai ser o endpoint que ele vai construir e como é que vai ser chamado lá na tela. Eu resolvi o primeiro problema lá que eu coloquei naquele abismo lá entre back-end. Entende? Muito mais fácil. Gente, isso aqui acelera demais o desenvolvimento das equipes de vocês. Muito, muito mesmo. Tá. Tá aqui, ó. Se eu voltar... alguém quer falar alguma coisa disso aqui, gente? Tá safe? Tá safe, né? Voltando aqui, ó. Eu tenho uma pergunta. Opa, cadê? O back-end recebe os contratos todos prontos pra desenvolver, então já é feita uma pré-análise completa tanto do back, do front? Exatamente. No FluxTabStstream. Lembra que eu comentei mais cedo que tinha o Flux Upstream? Eu não vi quem começou, tá, gente? Não levantou a mão, não apareceu pra mim aqui, tá? Opa, eu? Tá. No Flux Upstream, a gente faz os projetos, lembra que é uma etapa de desenhar o projeto? Então é nessa etapa que eu faço isso aqui. Ou eu, ou o Teclil. Show, entendi. Hoje, quem define o padrão é o back-end, né? Então, meus irmãos, quem define o padrão é o back-end. Isso, isso aí. É isso aí, gente. Imagine aqui, você chegar aqui, o pessoal fala, pô, Dancio, tu deixa os caras preguiçosos, né, velho? Cara, é o curral. Lembra do que eu falei do curral do boi? O cara vai fazer aquilo ali e tá tudo certo. Entende? Não é que ele não tem que pensar, não é isso. Mas o ponto mais de dado no inicial. Tipo, olha, vocês vão no prompt hoje, você pica uma linha, ele não vai lhe dar qualquer coisa. Se você preencher mais o prompt ali, ele vai lhe dar uma coisa mais repuscada, né? Vai lhe dar uma coisa mais reformada. E isso não quer dizer que tá escrito em pedra. Muitas vezes eu mando pra esteira de downstream e voltam com dúvida. Às vezes acontece. Dantas. Pô, cara, estou metendo a mão aqui estou desenvolvendo, cara, pensei numa coisa aqui que talvez seja melhor e aí o cara fala Dantas, exatamente sobre o que você está comentando aqui onde eu trabalho, normalmente quando a gente vai definir esse contrato a gente chama alguém do BEC e alguém do FRONT e a gente define junto, olha preciso definir tal história e precisa dessas informações. O contato vai ser esses campos. E aí, os dois lados começam a argumentar mas essa informação não tem no banco, não tem tal. E aí, em determinado momento, chega num acordo, o contato é esse, e aí cada um vai pro seu lado, e aí gera menos retrabando. Isso. É isso aí, mano. Isso aí que você fez é o Fluke Substream. É. É a ideação. Chamar todo mundo ali, botar todo mundo na sala e vamos definir tudo. Vai criar tabela, vai fazer a query assim, vai criar índice, vai buscar num gateway externo, vou bater lá no Febraban, vou bater lá na API do Asas, para pegar esse dado, por exemplo. É isso aí. Leandro quer falar. Falei, Leandro. Olhando aqui pelo desenho, eu percebo ali que no Chrome está sendo gravado tudo o que está em tela, mas na definição, você define tipo separado, que o Chrome lá ele vai escolher dia, mês e ano, e no back ele vai ter que fazer uma transformação para gravar isso aí, ou não. É exatamente o dado que está na tela, vai ter que ser gravado no banco. Cara, isso aqui é um... É, é bem didático, pensando no detalhamento do negócio em si. É, bem didático, mas assim, cara, o que eu tenho feito, né? Se tem transformações, o front, imagine assim, quem é responsável? Isso é uma coisa bem complexa. Regra de negócio do front. E aí, a regra de negócio, gente, primariamente tem que estar no back-end. Ah, Dantos, campos obrigatórios. Nome, Chrome e endpoint. O cara do front pode vir ali, eu coloquei no front, no back não me preocupo, tá errado. Isso tem que estar no back, tá? Não tem que estar no front. O front tem que fazer. Mas se alguém, algum esperto ali vem inspect, você copiar o curl e executar, tu vai salvar, o teu back tá zoado, o seu banco vai ficar zoado, entende? Teu back-end ali, cara, vou mostrar pra vocês ali depois na camada ali mais baixa, eu boto lá, esse campo é requerido e ele é um e-mail. Cara, já foi, não tem que fazer mais nada. Entende? E aí eu testo o meu contato. O back-end tem que validar a historinha técnica dele lá, de criação do endpoint, que ele criou e validou todos os campos, e está respondendo assim. Eu exijo, às vezes, eu sempre fiz, né? E aí as pessoas que eu mentoro, normalmente eu exijo, cara. Coloca a evidência no teu cargo. Bota o CUR e bota o BOE lá pra pessoa saber como é que você fez. Tá? Ah, essa é uma dúvida que eu tenho sempre. A data, eu devolvo do BEC já formatada ou o BEC que se vire pra exibir? O BEC tem... O front que se vire pra exibir. Normalmente o BEC, ele trabalha... Uma recomendação que eu falo para vocês, tá? Eu tenho dor de cabeça de data. O BEC vai trabalhar com um único padrão de data. ISO. RFC 3339. Tá? E, de preferência, trabalhe com o TC. Porque quando você responder em um TC, independente do front que está chamando, ou time zone que ele esteja, ele vai visualizar no time zone dele. É uma boa prática ter feito isso. Eu já vi situações de, cara, sistema quebrar por causa disso aí. A data é sempre um problema. Front é telinha, é formato de front. Não tem que ter regra de negócio Tem que estar pensando na experiência do usuário Regra pesada Validações É back-end Vou avançar aqui, tá bom? Voltando aqui Eu fechei todos os carinhas aqui Vou entrar em componentes Aqui do back-end Então eu tenho ali meus controllers Nesse caso aqui exemplo, só vai ter um controlador, o REST, meus casos de uso, ou services, eu batizei aqui de casos de uso, e um repositório, onde eu vou ali fazer os inserts. Então, eu tenho minhas camadinhas ali bem definidas. A camada de acesso a dados está aqui. Está mais próxima. Opa, alguém falou aí? Se quiser, coloca a mão. Não, pode ir lá. Ah, tá bom. E a parte de camada de API está aqui em cima. Entende? Então, esse é o design da minha API ali, do meu serviço. Isso está muito baseado ali no que a gente começou, do print tetra, simples print tetra, hexágono, seria basicamente onde estão os seus componentes dentro do seu sistema. E aí, vamos dizer que eu vou aqui, eu quero ver meu caso de uso ali de paginação. Então, eu tenho feito assim também. Esse é o meu nível mais detalhado possível. Eu já deixo pro dev pronto ali, as entidades ou os models, depende depende como você chama aí na tua empresa, DTOs, não sei como é que você chama, whatever, né? Cara, esse é o meu modelo. Então, aquele endpoint que tá lá no meu mockup, tá aqui de novo, copia e colê. E aí eu já fiz aqui pro cara saber como é que vai ser o model lá dentro. Quais campos serão requeridos, se tiver uma transformação, vai estar aqui também, tá? E como é que vai ser a minha regra de negócio? Recebeu, validou os parâmetros, se deu um erro na validação, retorna o erro, se não, eu consulto, retorna o erro na consulta, eu já digo qual é o erro que eu quero, se não, eu vou ali e retorno os dados. Bem simples. Fl bem simples, fluxo de cadastro é a mesma coisa tá vendo fluxo de atualização o crude ali daquele jobs, a mesma coisa e o fluxo de exclusão eu tenho todo o meu projeto pronto, não tem descritivo aqui, porque muitas vezes a gente pede um papel de folha ali, tipo um memorial descritivo revisão, objetivo você pega o diagrama, alguns lugares na contas ainda pedem, eu não trouxe isso hoje, tá? Mas isso aqui já tem de boa parte, porque o que eu faço? Quando o card tá feito, eu exporto isso aqui com o PNG e colo no card. Já foi. O dev já sabe o que tem que fazer. O time já sabe o que tem que fazer, já sabe estimar, no endpoint já tá ali o contrato, já tem a regra de negócio está tudo mapeadinho, já tem tela já tem tudo entende gente? faz sentido isso aqui que eu falei? que é uma coisa, eu estou alucinando aqui Max falei Max eu vi um colega que eu perdi a mensagem dele mas foi uma pergunta bem interessante em algum momento na empresa, existia um momento do antes e depois que você implementou essa forma de trabalhar para ter uma comparação? Beleza, você gasta todo esse tempo no planejamento e passa meio que mastigado para o desenvolvimento. Você conseguiu analisar a diferença para ver o tempo de desenvolvimento, se afetou muito ou não? Sim. Na verdade, ele afetou positivamente. A gente pensa, é o que eu falei, lembra no slide de mentalidade? A gente acha que gastar tempo planejando, amolando o machado, vai me retirar tempo de cortar a árvore mais rápido. Muito pelo contrário. Entende? Pega um machado tempo de cortar a árvore mais rápido. Muito pelo contrário. Entende? Pega um machado e vai cortar a árvore com um machado cego. Para tu ver o trabalho que você vai ter. Você vai ficar batendo ali, batendo, batendo, horas batendo até cansar. Se ele está moladinho, é capaz de você dar uma porrada só e ele cair. Entende? Essa é a mentalidade. Gente, há muitas empresas que pensam que upstream é jogar dinheiro fora. Na verdade, não é. E nós falamos isso baseado em dados. O Ziri está aqui, ele que fica mais focado nesse tipo de tema, de análise. Cara, a gente reduziu muito o tempo de desenvolvimento. Com várias técnicas. Obviamente, upstream e também a questão do padrão de código. Tem um padrão de código bem definido, tem uma cultura bem definida. E, assim, uma coisa legal é quando você não é impositivo. É colegiado. Então, você toma decisões colegiadas, a turma que vocês trabalham, elas enganjam. E se é top-down, cara, a galeradown, cara, mas aquele cara decidiu aquilo ali e não me perguntou. Se der errado, foi o Dampers que decidiu. Entende? Então, tem... Frank perguntou, o que é upstream? Upstream, Frank, é a esteira de desenvolvimento antes da esteira de desenvolvimento. É a esteira de ideação, onde produto e engenharia trabalham antes de ir para a esteira de colar. Certo? O dev se sente muito mais produtivo. Cara, eu tenho vários depoimentos aqui. Muita gente falou para mim. Dantas, eu queria que todos os projetos fossem assim, cara. Tivesse um slidezinho, um mockup, com os endpoints prontos. Gente, é muito mais rápido. Muito mais rápido mesmo. Tá? Muito. Imagina, e vocês podem? Se vocês recebem algo assim, ou o caso que o outro colega falou ali ah, eu junto um, junto outro a gente define ali meio, anota aqui no meu papelzinho, no meu bloquinho e leva não, tá ali no card abre lá e olha a imagem tá ali, o produto deixou o BDD lá, o descritivo lá né, bonitinho, entende? falei mais pronto, aí entra agora do outro lado em que momento você decide o nível onde você para a sua informação e deixa a cargo do desenvolvedor pensar, por exemplo, eu vi que você colocou a parte da estrutura do banco, não é isso? Em que momento você para, não, aqui já está bom agora o resto é com eles que está desenvolvendo. Assim, normalmente o upstream, o tech lead que está fazendo o projeto, ele conhece o projeto dele. E ele chama as pessoas envolvidas, back-end e front, para discutir como o colega falou. É assim que funciona. Então o upstream, ele vai, ele não para o astral desenvolvimento, o downstream, mas vai, ele não para o astral desenvolvimento, o downstream, mas ele chama pessoas chaves que entendem bem daquele fluxo e, ó, vamos trocar uma ideia aqui para desenvolver. E aí as pessoas comentam e fecham o projeto. Ó, isso aqui que a gente vai fazer, acabou e vai para frente, entende? Na hora de codar, o que o DAE vai fazer? Ele tem que traduzir isso que a gente escreveu para o código que está lá. Aqui não tem dizendo o show de when, then, que ele vai fazer no teste, por exemplo. Ou use case que ele vai fazer get by id use case ou create alguma coisa de use case. Aí já vai no talento dele. Usar essa prática de clean code, quebrar o código dele, o use case, em box que seja entendível, legível para entender. Tipo, o Dantz colocou aqui que o fluxo é esse, mas eu não disse aqui se ele tem que usar um partner, tipo um factory. Não, eu não disse. Aí está mais da técnica da pessoa, entende? Eu disse o que eu preciso. E a regra de negócio que está envolvida, que é o que eu preciso. E a regra de negócio que está envolvida. Que é o que o usuário espera e o que a gente espera como tecnologia. Mas a técnica em si, aí é da pessoa. No caso desse planejamento, quem faz? O arquiteto? Em casos de coisas cross. Cross, arquitetura. Técnico, do dia de produto, é o tech lead que faz. E, lógico, se ele pedir nossa ajuda, a gente faz também. Já aconteceu de coisas de produto, os arquitetos fazerem o projeto. E por time, já aconteceu. Mas por ajuda mesmo, tá? Normalmente, a gente não desempodera os tech leads, a gente empodera ele fazer. Gente, eu não sei como é que está a ordem aí, se vocês quiserem, podem perguntar, tá bom? Não sei como é que está, quem levanta a mão primeiro. Dantas, uma dúvida. Às vezes, na equipe, tem um dev que é mais sênior e tem um dev que é mais júnior, né? Um trainee. Aí, tipo... Essa documentação, quando é pra um trainee, eu preciso descer um pouco mais o nível? Não. Ou ela é padrão tanto pra sênior quanto pra júnior? Cara, vou contar uma história aqui, inclusive ele não vai me deixar mentir, ele vai dar um joinha. Tem um menino que entrou aqui, que é nosso xodózinho, é o Cris. Menino novo. Cara, ele entrou, ele era fronteiro. Ele chegou aqui devorando o fronteiro. Aí ele, cara, eu quero aprender back. Ele foi lá, estudou gol, aprendeu. Hoje chuta com as duas pernas. Manda bem qualquer coisa. E ele foi um dos estudou gol, aprendeu hoje chuta com as duas pernas manda bem qualquer coisa e ele foi um dos que eu fiz esse laboratório aqui e trazer esse nível de detalhe quando eu comecei a colocar nos caras ele, se eu tivesse presente, eu te daria um abraço sério mesmo cara, velho, isso aqui reduziu assim, porque o Júnior tem que ele olha e olha essa meia. Inicia aqui, aqui eu faço isso, aqui é uma decisão, eu desço ou não. Entende? É didático a leitura. Fica didático, entende? Pra quem vai fazer. A mesma coisa aqui, ó. Fica didático pro front. Ah, minha tela vai ser assim, vou ter esse campo aqui, esse aqui, esse aqui. Eu não disse, voltando à pergunta anterior, que o campo, vamos dizer assim, é DT nome ali, vamos dizer que tem uma abreviação padrão no front, que eu tenho que ser DT nome. Eu não entrei nesse detalhe. Não precisa. Entende? Ou que ele é requerido. Eu já tenho aqui, eu não preciso deixar a minha paleta de propriedade do meu componente descrita, eu estou com dano num projeto, não precisa o projeto tem que chegar até um certo nível onde oriente a pessoa como ele executar Dantas uma última dúvida não vou perguntar mais normalmente essa tarefa que tu está comentando de fazer esse mockup tudo bonitinho normalmente nas nossas equipes, é o analista de equilíbrio que faz, entendeu? A tua equipe é você que faz, tipo assim, não? É assim, o project manager é o project manager, e tem o designer que trabalha junto com ele, a designer, normalmente é uma mulher, a gente encontra designers mulheres. Cara, elas fazem fantástico trabalho. Ela faz tela, ela pinta, ela põe o cônico pra lá, botão pra cá, e faz estudo, e faz pesquisa, e traz isso pronto pra gente, que é o mock-up. No caso de produtos internos, tipo back-office, tem um back-office aqui na Conta Azul, que são coisas pra nós, isso aqui na conta azul, o que são coisas pra nós? Pra engenharia, pra produto, pra N2, pra suporte, etc. Esse cara, normalmente a gente não pede designers pra fazer isso, a gente mesmo faz. É o que eu entrego. Quando vai fazer uma tela nesse produto interno nosso, eu faço a telinha aqui, cara, é como eu disse, já tô poucas semanas fazendo com torcer, com torcer, com torcer, com torcer, com tor não tem nenhum trabalho. Mas assim, normalmente essa tarefa não fica assim para arquiteto, normalmente joga para alguém mais... De produto, é isso mesmo. Isso é mais de produto. No meu caso, eu faço às vezes, mas quem entrega para mim normalmente é produto. Beleza. Aí o que o produto faz, o que eu faço no meu projeto aqui? Eu tiro o print da tela que ele fez, colo aqui e relaciono com o endpoint. Aí eu tiro um outro print, exporto para o PNG e coloco um card. A tela e o endpoint junto, como vocês estão vendo aqui. Beleza. Fechou. Fechou? É, Dantas, uma dúvida. Quando a empresa não tem a cultura de seguir esse padrão que você está nos mostrando aqui, muitas vezes a gente recebe um stop-down, alguma coisa desse tipo, o que seria um mínimo aceitável para a gente começar a desenvolver uma atividade de acordo com esse padrão que você tem. Se você trouxe várias camadas assim, mas o que você diria assim, não, isso aqui é o mínimo que daria para a gente passar para frente pra uma demanda que é top da alguma coisa bem urgente. Ou não, descarto. É essa aí que eu pergunto. Cara, em tempo de vacas magras, né, ou outro ditado, quem tem um olho é rei, né? Então, se você tiver somente um papel de pão, você já é rei. Você já está ano e ano na frente de quem não tem nada, que é o cérebro. Aqui é onde você tem um olho só. Entende? Se você tiver um papel de pão que diga onde começa o seu fluxo e onde termina, e eu consigo bater o olho e ler, e daqui a um ano, quando a gente voltar a conversar sobre esse projeto aqui, e a documentação está viva, cara, não preciso nem abrir o código, eu vou, olho a documentação e já sigo o software e faz. Perfeito, obrigado. Beleza, irmão. Da minha parte, lá a gente tem fluxo diferente, a demanda chega, eu pego, descrevo para o desenvolvedor um pouco, poucos detalhes, não entro no termo técnico, peço para ele. Vai lá e faz um doc, entrega a solução, depois a gente debate. Então, esse é o nosso fluxo de documentação antes de desenvolver. Eu digo para ele brevemente, porque eu tenho demanda também, não sou só tecnista, não sou só arquiteto, então eu descrevo ali, dou um caminho, mas se pá não é esse. Se duvidar, tu vai achar uma ideia melhor. Vai lá e pesquisa e faz um doc pra nós. É mais ou menos o que a gente funciona lá. Bom, mas, assim, Diego, o teu caso é 90% dos casos. O produto chega com alguma coisa, a gente senta com o nosso time, discute ali, define, faz um papel de pão. Às vezes, quando tem um fluxo bem definido ou tem mais tempo, que às vezes não tem, não dá tempo, a gente faz o C4, bonitinho, entrega, faz mock-up e tal. Mas muitas das vezes, 90% das empresas é isso aqui. Ou nem isso. Chega lá, escute ali, já vai metendo mão, ou escreve no card, não sei se é Trello ou é Gira que vocês usam, mete ali, escreve no cardzinho, eu vou fazer isso e isso e isso. Vamos meter a mão em cima, vamos para frente. É isso aí. Então, ainda mais, muito bom. Edu quer falar, né? Fala aí, Edu. Opa, e aí? É, na verdade, é mais uma pergunta ali. Como é que vocês lidam, como é que vocês trabalham quando chegou na etapa ali do downstream, daí o desenvolvedor está codando de acordo com o que foi projetado e por algum motivo se percebe que existe a necessidade de mudar o contrato da API. Como é que vocês fazem para cascatear isso? Eventualmente tem alguma outra dependência que está trabalhando junto excelente pergunta Douglas, muito boa mesmo acontece, tá e assim o que a gente fez na etapa de ideação muitas vezes na hora de construir não é o que acontece vou dar um exemplo, trabalhei na Petrobras em um projeto, nos meus dois primeiros anos às vezes, num projeto que eu usava ali, tipo, vou interligar um sistema assim, assim, assim, normalmente eu vou passar uma fibra ótica aqui. Às vezes eu olhava no projeto anterior, não dizia que passava um cabo de energia aqui. Aí o pessoal, quando ia lá cavar, pra passar a nossa fibra ótica ali, metal e sistema tal, achava um cabo de energia. E aí, vai fazer o quê? Voltava pra a gente conversar. É a mesma ideia. A mesma analogia, entende? Então, muitas vezes quando tá no downstream, vai estar desenvolvendo e aí, pô, a gente repensou isso aqui, a gente pensou lá no upstream daquele jeito, mas nós metemos no código que a gente entendeu aqui que seria mais rápido. O que tu acha? Cara, mete pau. Taca ali pau, velho. Vamos dizer aquela taca ali pau nesse carrinho, né, Marco? Então vai, só vai. Não criam nenhuma obstrução, seguiu o baile ali pra focar na entrega. Exatamente. Aí o que que eu peço normalmente? Faço o as-built. O que que é o as-Built, vê na documentação e atualize a mudança a documentação continua viva, entende? Entendi, mas qualquer um pode colocar a mão ali na documentação não tem problema a documentação é do time entendi, e o mesmo acontece por exemplo, tu tá mostrando agora um diagrama aí sei lá, antes do microserviço se comunicar com o banco foi notado na etapa do downstream que, poxa, a gente precisa fazer duas chamadas, duas requisições que não foram planejadas ali. Daí é a mesma pegada, atualiza a documentação. Mesma pegada, vai lá, faz, implementa, vai lá na documentação e atualiza. Não volta pro fluxo upstream, entende? Já desceu pro down, já era. É meter pau e aí vai lá na documentação e atualiza a decisão. Aí isso fica eterno. Sabe? Projeta, constrói, atualiza se precisar, projeta, constrói, é eterno. Cíclico. Acho que foi o Léo que levantou a mão primeiro, né, Léo? Falei. É bem rápido. Eu queria saber como é que vocês gerenciam os endpoints, né? Como é que vocês fazem a gestão? Tipo, guardar tudo isso aí, porque pra nós que é pequeno, que já tá complicado saber em que rótulo eu coloco cada uma das cadastras. Imagino de vocês. Excelente. A gente usa o Swagger. Então, nossos microserviços, a gente documenta e aí ele já exporta o Swagger para lá e a gente tem um Swagger único onde eu consigo velar todos os e todos os microserviços. É, porque pensar se está como microserviço separado, como é que vai saber as rotas que cada um está? Acho que você perguntou mais no viés de documentação, não é isso mesmo? Isso, é. Para eu saber onde que eu vou, na hora que eu criar o V1, já tem o V1, já tem o V2, já tem o V3. Isso, é isso aí. Legal, valeu. Valeu. Oswaldi, pode falar a mão. Opa. Houston? Não, acho que teu mic deu ruim aí, velhinho. Show! Vamos pegar o próximo aí. That's one. Eu acho que tem aqui a... Gabriela Mendes. Boa. Acho que o Sirão é o Sirão nosso aqui da Conta Azul, Sirão? As ADRs a gente não trouxe, tá, Sirão? Se for você... As ADRs, cara, alguns times de produto não estão mais fazendo, tá? A gente coloca lá no Git. Tá só colocando no drive do time e no Confluence, né? Na documentação descritiva. Esse é o mesmo. Ah, e aí, senão, beleza? Outro azul aí, galera. Aí é fera, hein? É o nosso chefe da plataforma, ele que manda, até que lida a plataforma aí. Um doce. É isso aí, se não se foi você perguntou, né, das ADR, né? Alguns times estavam na Bolívia, tá, de usar as ADRs, a gente até tá conversando sobre isso lá. Aí a gente tá usando mais o C4, o MDL, e quando pede, aquela documentação descritiva lá, a metodologia confluência. E aí, meu povo? Fiquem à vontade aí, tá? A hora é agora. Tô aqui pra vocês aí. Tamo junto. Tão me ouvindo? Agora sim. Agora sim. Ô, Dantas, achei muito da hora o teu fluxo. Eu queria fazer duas perguntinhas. Vocês estão utilizando o IA para a parte de desenvolvimento, discover do produto e validação das ideias enquanto não vai para a área de desenvolvimento? Se estão utilizando o IA e como estão utilizando? E a minha segunda pergunta é quais foram os desafios para chegar nesse ponto ideal que você comentou para a gente e o que vocês enfrentam de problemas ainda hoje, atual, que ainda vocês precisam refinar, porque vocês estão bem no mundo, vamos dizer assim, da hora. Muitas empresas querem chegar, muitas devem, principalmente quem é especialista, é arquiteto, quer chegar nesse modo aqui que você tem a documentação, como você diz, visual. Quais são os problemas que enfrentaram e estão enfrentando ainda e se a IA tem algo auxiliado na validação das ideias? Cara, pergunta top, top, duas perguntas excelentes. Você não respondeu ali, usamos o G Suite, tá vendo? Hoje parece que o pessoal lá liberou um slack ali, um novo motorzinho que a gente faz as perguntas e ele até vi hoje, não testei ainda, mas foi bem legal. Cara, a conta azul, a conta IA, tá numa frente novo motorzinho que a gente faz as perguntas e ele até vi hoje não não não testei ainda tá mas foi bem legal cara a conta azul conta aí ela tá numa frente é é e a uma frente muito forte de ar tá tanto para uso interno como externo por seus produtos ele é internamente a gente tinha um time focado em laboratório de IA. Está estacionado neste momento. A gente estava começando a testar hipóteses de prompts para back-end e front através do plug-in de Figma, por exemplo. Chega lá, já vem o protótipo design, a gente vai lá e gera. Só que a gente tem alguns problemas, tipo design system nosso, particular, privado. Nossos frameworks internos de backend também privado. A IA, na base dela lá de conhecimento, ela não vai ter esse código. Nem nosso padrão de código ela vai ter também. Ela vai fazer tipo assim, ó. Eu chego ali no back e peço para ele gerar uma API para mim, Go, que vai fazer isso e isso. Ela vai instalar normalmente o GIM. Ela fazer isso e ela vai baixar o realmente o Jim ela vai lá fazer o padrão boa não vai usar o nosso pelo outro não vai usar nossa lib entende que a gente tem internamente isso a gente tá amadurecendo ainda através de prompt e enriquecimento da nossa inteligência aqui como fazer tá é e com relação a uso também de um produto. Eu estou vendo bastante o pessoal usando, poder ter ideação, validação, melhorar texto também. O cara vai ali, começa a escrever uma história, ele vai lá e pede para a IA, olha, por favor, valida, deixa mais repuscada, mais profissional, para quem tem mais didática, a IA vai lá e dá uma arrumada no texto também, está sendo usado bastante. Como deve também, eu sou um pouco cético ainda de IA, mas estou começando a usar mais, a ficar mais familiarizado, como se dizia assim, experimentando e convivendo com ela. A gente está usando aqui na conta azul devin.ia e o cursor. E normalmente, às vezes, eu tenho pedido para fazer testes baseado em alguma coisa. Olha, eu tenho esse modelo aqui, eu tenho esse teste para criar. Cria esse teste para mim usando o AAA e show do andam baseado nesse código aqui. De exemplo. Cara, ela gera perfeito. Perfeito. O Zili e eu fizemos uma POC no final de semana, juntos. No sábado de tarde. A gente pegou um projeto Java, mediano, realmente complexo, que usa Java 21 e 17. E a gente queria migrar ele pra um outro usando o Go. Aí o que a gente fez? Pegou um outro repo exemplo de Go, com todos os padrões que a gente conversou, bem documentado. E, cara, pega esse projeto aqui, baseando nesse daqui, cria uma outra pasta e começa a migrar todos os repositórios, todas as consultas, com esse template aqui, cara, ela chegou a fazer 70%. Ela travou. Ela fez todos os repositórios, ela fez todos os casos de uso, ela fez tudo certinho. Mas nós, ele criou o controladorador a gente parou, a gente ficou ali testando, aí vamos deixar ela aqui gerando e amanhã a gente continua aí no outro dia no domínio de Ita, a gente voltou pra ver ela tava tentando gerar o código do controlador lá na pasta e não tava conseguindo aí eu gerei o controller, aí quando a gente olhar cadê o arquivo? Não tava aí eu ia lá, ó, você não gerou o arqu só alucinar, alucinar e se perdeu. Travou e não foi mais pra frente. Aí a gente ficou de voltar e melhorar o prompt, a gente melhorou o prompt, ficou gigante, mas mesmo assim a gente ainda não teve tempo de voltar a testar. Então a gente tá nessa frente aí, entendeu? Experimentar e validar, cara, tá bem legal isso na conta azul, tá bem forte mesmo. Tá vindo dos executivos, lá do C-Level da conta azul, Acho que eu respondi a você, né, Valdão? As duas, né? Foi boa, né? Isso. Aí o outro lado é quais foram os maiores desafios para chegar nesse modelo de você fazer o teu primeiro upstream do lado de prototipar toda a idealização do produto e o que vocês enfrentam hoje de problemas nesse fluxo do lado de prototipar toda a idealização do produto. E o que vocês enfrentam hoje de problemas nesse fluxo? Se tem algo que vocês ainda precisam vencer. Você fala... Eu não peguei bem a ideia ainda. Na parte de projeto... Quando vocês estão idealizando, que nem você explicou ali o teu projeto de scheduler jobs. Você desenhou o C4, desenhou o teu MDL. E aí, isso hoje, para vocês, é extremamente sustentável? Tem alguma coisa que vocês precisam vencer ainda? Que tem alguma coisa ali que às vezes falha nessas definições? Boa pergunta. Entendi agora. Maturidade. Por mais que a gente ainda tenha um padrão experimentado, validado, mais times e mais pessoas com experiências maduras e diferentes, ainda quando vai descer para a esteira, tech leads e desenvolvedores ainda não têm maturidade às vezes para desenrolar. Ou o outro fator também é produto, priorização. Cara, preciso disso para onde? Você acha que todos saem com um desenhozinho? Não, não saem. Como a gente gostaria, entende? Às vezes, sai alguma coisinha por debaixo da porta ali, que, às vezes, a gente não consegue atualizar a documentação. Entende? Então, como eu falei lá no início da apresentação, né? Por que às vezes as empresas não implementam? Porque é falta de maturidade, falta às vezes de visão, de mindset. Né? É difícil. Às vezes a pessoa pensa que é custoso e na verdade não é custoso, é o contrário. Quando você começa a colocar na cabeça de stakeholders que é o mindset de amolar o machado, cara, funciona que é uma beleza. E essa documentação, ela vai ficar ali pra vida toda. Não sei se eu respondi tudo o que você gostaria. Respondeu, obrigadão aí pela sua disponibilidade de trazer sua experiência pra nós aí. Tamo junto. Next one, é Rodolfo agora? É isso? Opa, isso, boa noite. Excelente conteúdo. Gostaria de saber se essa metodologia do upstream, além de ser usada na comunicação de on-chain e back-end, se é usada também ali entre microserviços, usando ali alguma mensageria como o RabbitMQ ou a Kafka? Perfeito, Rodolfo. No meu exemplo, porque eu fiz correndo, mas, cara, aqui no desenho, quando representa este caso de microserviços com microserviços, eu coloco aqui também. Eu coloco aqui qual é o endpoint que eu vou chamar do outro microserviço, coloco o contrato, o DevCon vai receber lá e já vai receber o endpoint, os parâmetros, o body, tudo que vai estar lá no outro que vai chamar, já está ligado, entende? E aí, no C4, eu consigo ver aqui dentro do container qual é o sistema que ele está chamando. Então, já vai estar lá o contratinho. E quando é fila, eu também coloco. Tipo aqui, ó. Quando é fila, eu coloco aqui SQS. Em meio de post, eu coloco SQS, o nome da fila e o body da fila. Tá bem? Joia, maravilha. Então já, isso já me induz à segunda pergunta, né? Que, inclusive, é uma das matérias que nós estudamos aqui no MBA, que é a lei de Postel. Não sei se pronunciei certo, mas ele meio que faz com que você seja mais flexível na hora de receber informação. Então, você pode receber informação ali quando... Sei lá, é um exemplo, tá? Um int vem entre aspas duplas, então você consegue converter para int. No caso, ele vem em string, você consegue converter para int. Você consegue ser mais flexível na informação que você recebe, mas você tem que ser exato na informação que você distribui. Essa é a lei de Postel. Eu gostaria de saber se faz sentido para você, se você usa, e se não, se realmente faz sentido essa lei. Não fazemos, porque, cara, o meu atributo ele ser generalista, tipo um object Java ou uma interface Go, por exemplo, ou um Node.js que aceita string, número e tudo embolado ali naquele mesmo var, cara, não é uma boa prática, tá? É uma armadilha isso daí. A gente às vezes pensa que isso vai agilizar o nosso lado. Na verdade não é. E aqui a gente não usa. O atributo é forte, tem que ser fortemente tipado. Entende? Sim, maravilha. É isso. Beleza? Obrigado, Carlos. Gabriela, quer perguntar? Fica à vontade. Acho que ela foi abrir o microfone e sumiu aqui para mim. Boa noite, Danco Zé. Vocês estão me ouvindo aí? Obrigada pelo conteúdo, muito bom. A minha pergunta, na verdade, ela é mais relacionada a como foi a evangelização disso com seus pares, né? Não sei se você tem outros colegas arquitetos, na parte de liderança técnica, porque hoje eu enfrento um problema que a empresa que eu estou, a gente não tem arquiteto, a gente tinha um papel que era o principal engineer, que era o cara que mais olhava pra essa parte de documentação, e tinha um time de staffs, né, no caso eu sou um dos staffs, e eu acho que eu, um time de staffs, no caso eu sou um dos staffs, e eu acho que além do Príncipe, eu acho que eu era uma das únicas pessoas que ligava pra documentação. Pra você ter ideia, nem o Swagger, os daycannels da minha empresa não faziam, começaram a fazer bem recente, acho que foi em janeiro que começaram a fazer. E a gente é uma health tech, uma health tech que já é autossustentável, a gente não depende de dinheiro de investidor, então a gente meio que não tem uma desculpa para não estar fazendo mais documentação. Está numa loucura desnecessária. Eu queria saber como é que você lidou com isso, para meio que ter uma... É mais negócio soft skill, né? É mais aprender dessa experiência mesmo. É, essa experiência. Legal, bacana. Foi uma boa pergunta. Acho que vai agregar para outras pessoas também. Gente, assim, criar também. Gente, assim, criar um padrão e implementar ele não é fácil. Qual é a primeira barreira que tem que enfrentar? É a cultura. Né? Cultura da empresa. Segundo lugar, é os vieses ou crenças das pessoas que estão envolvidas. Também é outra barreira que tem que enfrentar. Então, o que eu recomendo, normalmente, ali, quando você for implementar um projeto assim, né? vamos dizer cross, pegue o máximo de pessoas, teste com o máximo de pessoas, valide com o máximo de pessoas que você puder, e deixe a decisão colegiada, com o máximo que você puder. Por quê? Psicologia. Quando o meu chefe manda em mim, quando a mãe da gente mandava na gente, a gente ficava bem chateado. Qual mãe? Por que você está mandando eu fazer isso? Porque eu sou a mãe, eu que mando. A gente não ficava chateado com ela? Ela não explicava, né? Bom, meu filho, não bote o dedo na tomada, não. Não bote o dedo na tomada, nãoão você vai tomar um choque e pode se machucar. É diferente, né? Mas, assim, é psicológico da gente, entende? Então, o máximo decisão que você tomar na colegiada, as pessoas vão abraçar a tua ideia e, em vez de ser detratoras, elas vão ser promotores da tua ideia. E elas vão querer viver mais ainda, porque foi ela que participou da decisão. Por mais que exista um comitê de pessoas com maturidade técnica maior, os arquitetos, os principals e staff de engenheiros, vai ter os técnicos também que são especialistas. Então, se você conseguir trazer essas pessoas para perto de você, melhor. Entende? E, por si só, eles que estão no front de guerra com os outros da F, sênios, plenos e júniors. Então, ele consegue também multiplicar e replicar esse sentimento para os times deles. E, cara, existe treinamento, tem que ter essa evangelização, como você bem falou, e sempre pesando. Gente, por que nós estamos fazendo isso? Porque eu quero? Não. É baseado nisso, nisso e nisso. Padrão de código, que a gente não falou aqui, mas só comentou rapidamente. Por que importante é um padrão de código? Eu já abri repositório, gente, que tem três padrões implementados dentro dele. O cara usa Cep, o cara usa IKs e usa Interact. Dentro do mesmo rep, do mesmo microscrito. Tá, e por que eu tenho que usar esses três aqui? Não sei porque cada caso. Não, é porque aqui eu fui lá, eu sou javeiro ali que estou acostumado a usar Cepsi, o Lois fala Cepsi. Ah, não, eu sou javeiro que estou acostumado a usar Interaction, vou lá e uso Interaction. Ah, mas não para dar um encolho da conta, eu sou aquele cara que gosta de ser mais detalhista. Não, mas fala que é o Ezekiel, então eu vou usar o Ezekiel. Cara, você tem e acabei dentro do meu prato. Entende? É uma loucura isso aí. Sabe? Então, outra coisa também que eu tenho que ter o padrão de código. Um time, um cara vai pegar, um gestor precisa de, tá de alta demanda que tá com menos. Aconteceu já isso. Aí eu preciso pegar um dev emprestado aqui por, sei lá, 45 dias pra poder me ajudar minhas demandas. Acontece, né? Cara, imagina ele ter que ir pra outro time e reaprender tudo como o pessoal fez lá de frente, sepa não. A loucura que é isso aí. Ou seja, em vez de ele já chegar lá jogando, ele vai ter que chegar lá e fazer um onboard de como é que tá escrito, como é que estão os pacotes, como é que estão as entidades, tá tudo diferente do que ele tá acostumado no dia a dia do time dele. Entende? Então, é isso. Você tem que mostrar esse valor para a empresa, para os seus stakeholders. Quando você chegar e ir para os C-Levels, chegar para os diretores, gente, a gente precisa, por causa disso e disso, a gente vai acelerar assim, assim, assim. Faz uma POC, prova o teu conceito, vai lá e implementa. Como é que foi trazer o gol para Foi várias noites testando, a gente levou para o diretor que tinha na época a hipótese. Quais eram os três pilares que a gente queria aprovar? Ser mais rápido desenvolvendo, gastar menos e trazer uma maior satisfação de 10% para trabalhar com uma linguagem mais nova, mais condizente com o mercado. A gente teve desenvolvedores que saíram da conta azul, pô, eu estou trabalhando com uma linguagem de 30 anos, entende? Pô, com o mercado livre que tem Gol, pouco Pouco no C1, é PicPay. Entendeu? Então, aconteceu isso. Então, como é que a gente traz mais modernidade, né? Redução de custo e salidade de desenvolvimento. Então, pegamos esses três pilares e provamos com a POC. Levamos pro diretor, ele analisou, voltamos pra prancheta, testamos de novo, levamos outro caso, aí ele oficializou pra Cont ou para a Conta Azul. A partir de agora, o gol é uma linguagem especial da Conta Azul. Entende? Então, são esteiras que você tem que ter. Entende? Desenvolvimento, maturidade, treinamento, abranger pessoas, agaranhar pessoas para aprovar o projeto. Acho que eu fui bem detalhista na resposta, não é? Não, deu para ter entendido. Vai se inspirar aí. Obrigada. Valeu. Tem, Will. Tá aqui ele, ó. O amar desse livro aqui, tá aqui ele. É isso aí, irmão. Próximo, next one. Sim, gente, vou compartilhar. Vou ver com o Léo ali, o Devin Fusai, como é que a gente faz pra compartilhar com vocês, tá bom? Léo, quer falar aí? O Varga. Bom, boa noite aí, pessoal. Queria saber com você, Dantas, se vocês utilizam o GraphQL para alguma coisa, como é que vocês lidam com essa questão de overfetching, tendo web, mobile, que padrões vocês pensaram para ajudar quanto a isso, enfim. Boa pergunta, irmão. O Zilli está aqui. Ele dá? Então vamos botar GraphQL. Porque, cara, era... A gente queria fazer o quê? Tinha muitos endpoints, a gente queria começar a dividir os domínios e usar um BFF em GraphQL, por exemplo. Aí a gente pegou um time nosso aqui de mobile pra fazer essa POC. Acabou complicando mais do que tinha batendo com o simples REST da vida. E aí, tem no meu radar aqui que a gente usa GRPC, mas ainda não foi feita a POC, tá? Tá aqui no radar. A gente usa os padrões de mercado mesmo, APIs, endpoints, HTTP, a gente usa o padrão REST, como é, REST for normal, né? Não vamos dizer que cê é cem por cento REST, porque também, aí eu vou tá mentindo, né? Tem tem umas desviadas no mesmo caminho, principalmente nos endpoints mais antigos. Mas, cara, é endpoint... Às vezes a gente tem BFF, a gente tem proxies também aqui na Composu, pra ajudar. É isso? É isso. Obrigado. Valeu. Boa noite. De novo. Pegando o gancho da conversa. Como tu lidar com a questão de motivação de equipe? Como tu é um cara referência, como que tu lidar com motivar o time individualmente, pensando pessoa por pessoa, como é que tu faz esse trabalho? Excelente. Nos times aqui nossos, o que a gente tinha é uma cultura bem forte de one-on-one. Então a gente quer estar ali com a pessoa bem próxima a ela. Eu fazia antigamente o 101 com os tech leads. Qual a ideia? Mentorar eles para um dia ser arquitetos. Assim como eu recebia o 101 do meu gestor, que normalmente é um ré de engenharia. E os tech leads, por sua vez, fazem o 101 com os devs. E a gente faz esse planejamento de carreira. A gente tem uma planilha aqui de mapeamento de hard skill, que diz o que um júnior tem que saber, um primo tem que saber, sobre cada disciplina. Cloud, back-end, front, mobile, e por aí vai. Isso norteia o cara para estudar. Então, ah, eu quero virar um dia um sênior. O que eu preciso estudar? Então, tem ali um roteirinho, esses one-on-one, em os técnicos fazem. Os gestores de engenharia fazem esses mandamentos com mais frequência e os técnicos também fazem essa mentoria na parte técnica. E eles dois juntos fazem ali essa mentoração para o débil. Normalmente eu gosto muito de ouvir. Por mais que às vezes eu fale bastante, eu gosto muito de ouvir e entender as pessoas que estão bem perto delas. Deixar ela se abrir, entender a necessidade dela, faz parte do papel de como eu vou ajudar ela a chegar ao objetivo que ela quer. Porque uma coisa que eu gosto muito de falar é a seguinte, sem IPJ, é igual a estação de trem. Certo? Hoje, a gente está, um está na A, um está na B, ou tem a sua empresa, e quem sabe um dia a gente vai se um está na A, um está na B, ou tem a sua empresa, e quem sabe um dia a gente vai se encontrar junto na empresa C. Ou na D, na E, no futuro, de novo, já aconteceu isso. Mas as pessoas que você fez ali as parcerias, os colegas que você teve mais próximos, que você ajudou e foi ajudado, elas vão lembrar de você a vida toda. Pô, foi aquele cara que me ensinou aquele negócio. E aquele sentimento de gratidão vai estar em você a vida toda. Eu lembro lá em 2000, quando eu comecei a aprender a programar, eu fazia os cursos em 1990, mas aprendi, tinha alguém que teve que sentar comigo lá. Tinha um cara que saia do trabalho dele, ia lá para a minha casa, eu morava sozinho, abria o notebook dele lá, venho lá e me mostrava como fazer, me dava as dicas e tudo eu tenho sentimento de gratidão 25 anos depois então é isso que é bom eu acho que isso é o responder a tua pergunta, pra mim é o que tem mais valor entende? não sei se faz sentido, pode fazer sentido pra uns e pra outros não mas pra mim, Dantas, eu acho que o experimento mais válido é isso. Não, show. Muito obrigado. Valeu. Marcelo, quer falar? Opa, boa noite, Dantas. Tudo bem? Primeiramente, parabéns pela apresentação, foi muito boa. A minha dúvida é em cima da ferramenta que você usa para fazer os diagramas, se você usa o DrawIO mesmo, se tem alguma outra ferramenta que você usa para fazer o C4. Outra coisa também, só uma observação, achei bem interessante esses diagramas que você fez, partindo assim do princípio, o país, que seria o macro, e depois indo para o micro, que seria ali o seu bairro. Particularmente que seria o macro e depois indo para o micro que seria ali o seu bairro particularmente eu tive algumas experiências ano passado com um cliente e ele tinha um sistema bem complexo da parte de transferência pix e etc e uma coisa que me ajudou muito a poder entender como que funcionava a aplicação por baixo dos panos eram os diagramas. E aí eu comecei a focar bastante nisso. Tanto tentar ver os diagramas que já existiam, como cada feature ali que eu ia pegar para fazer. Tentava também criar ali um diagrama também para deixar documentado para os outros colegas ou então levar para alguma apresentação para o cliente. Então, particularmente, eu acho que diagrama é um passo ali essencial no ciclo de desenvolvimento de software. Sim. É o que eu falei, Marcelão. Tipo, cara, tem gente que não tem valor, mas isso é mindset. No momento que você colocar a ideia na cabeça de que você tá molando a sua ferramenta de trabalho, tipo, eu sou pintor. Se eu não lavar o meu rolo, cara, a minha pintura fica feia. É a mesma coisa. Entende? O projeto, a ideação, essa fase é extremamente importante para eu ser sniper. Desenvolvedor bom é aquele dos dois snipers. É um tiro na cabeça e derruba o avítico. Não é aquele fute-guerra. Tinha um patrocinador que era um louco. Quem acertar, acertou. Daqui a pouco vem o chamado, vem as buchas, entende? E aí o time, aí a produtividade, em vez de cada vez mais rápido, a produtividade do time começa a cair. Entende? Exatamente. E o que você fala aí? Em relação à ferramenta. Ah, desculpa, eu uso o Drywall, mas tem gente aqui que usa Scaledraw. Ah, tá. Perfeito. Eu uso o Drive. Correu? Perfeito, muito obrigado. Valeu. Me ouviu aí, Dantas? Opa, sim, escuto. Primeiramente, parabéns pela apresentação aí, bom demais o conteúdo, né? Eu queria só tirar uma dúvida, assim, eu vejo que você coloca bastante documentação que entra um pouquinho ali pensando em design, não design de código, né? Mas você dando a base para iniciar uma codificação. Eu queria tirar uma dúvida, você com o chapéuzinho pensando em arquitetura de solução. Dessas documentações todas que você mostrou aqui, para arquiteto de solução, só com esse chapéu puramente, se você entender que são todas essenciais, você faria algum enxugaria alguma coisinha ou montaria outra, acrescentaria ou tiraria para seguir para o sucesso de um projeto de uma grande companhia que você está atuando. Pessoal, a gente pergunta, acho que está ligado com uma outra tipo, Dantas, eu tô com muita pressa, eu preciso só qual a documentação mínima pra mandar pra frente? Cara, esse aqui, tenha um, não precisa ser um MDL, se você fizer um diagrama de fluxo, o ML mesmo, né? Diagrama de sequencial, já é alguma coisa. Entende? O que mais você tem que proteger, além da técnica, obviamente, precisamos não construir isso, Frank Stein, é você ter claro qual é o fluxo de negócio. Dentro do teu espaço. A regra de negócio. Por isso que aqui na camada 4, eu deixo bem detalhadinho, às vezes fica compridão, fica um salsichão, ou eu começo a ter que quebrar, porque não tem folha que suporte, né? Aham. Mas assim, pra mim, toda essa documentação mais valorosa é isso aqui. Ah, bacana. Show. Onde eu atuo aqui também a gente tem, né? A gente faz o diagrama C4, com algumas padronizações pro modelo da organização aqui também. Aí nós, como arquitetos, a gente também faz ali um diagrama de infraestrutura alto nível, mais em relação a componentes que serão provisionadas e a princípio, o primeiro contato é um cachograma, né? Pra gente ter mesmo esse entendimento de onde a gente tá saindo, pra onde a gente quer chegar, passos da aplicação ali. Mas, brigadão. É isso aí valeu gente, tem mais alguma pergunta, alguém que quer ficar à vontade se depois, Léo, a gente puder tirar uma foto ali pra registrar esse momento com todo mundo na hora na hora, pessoal agora tem que ligar a câmera, né, pelo amor de Deus não vamos fazer feio, pô deixa eu parar de compartilhar aqui, tá bom vou até eu também tirar umahar aqui, tá bom? Vou até eu também tirar uma foto aqui que eu vou postar lá no nosso LinkedIn. Boa. Peraí, peraí, peraí. Não, não tem esse negócio de estar jantando, não, pô. Mostra o prato aí. Peraí, deixa eu tirar, vou até expandir aqui pra ficar bonitão. Bota um joinha aí. Aí. Não, só não pode ficar esses fogos aí atrás, né? Aí não, né? Show, show de bola, cara. Tirei várias aqui, inclusive, vou até bater um print, que aí já fica até mais bonito do que minha foto. Peraí, vou até bater um print que aí já fica até mais bonito do que minha foto. Pera aí, vou botar um print screen aqui. Show! Tem uns quatro aqui. Depois eu te mando pra gente repostar lá. Galera, e aí? Mais dúvidas? Sem dúvidas? Amanhã, então, é chegar na empresa e mandar ver nas documentações? Show de bola? Massa! Ó, o Leandro tem mais uma dúvida aí. Manda aí, Leandro. Bom, vamos lá. Eu queria saber, Leandro tem mais uma dúvida aí, manda aí Leandro bom, vamos lá eu queria saber, Leandro geralmente, né como arquiteto de soluções a gente passa ali pelas equipes analisando o trabalho que está sendo feito ali no dia a dia, tá eu queria saber quais foram as principais dificuldades, assim, que você percebe do pessoal ali, eles saindo de padrões, ou na forma de comunicação, enfim, sabe? Qual a bagagem que você tem já, né, de vários anos? Queria saber, assim, um pouquinho os perrengues, assim, que você já viu ali no dia a dia. Cara, essa pergunta é difícil de responder. O principal fator, mano, as pessoas às vezes ah, eu quero fazer do meu jeito ou tem muito caso também que eu peguei muito ah, eu li, eu vi eu peguei o livro do Uncle Bob, eu li quero fazer a POC aqui, porque eu vou mudar porque, e faz a empresa de laboratório, e aí daqui a pouco meu amigo, você tá com um mandu na mão tá com um problemão na mão, um pepino gigante na mão, tudo bem você fazer tua pós no ambiente controlado, mas às vezes os caras já querem fazer no ambiente produtivo e sair e fazer, sabe? Não é que eu vou poudar a pessoa de não fazer, não é isso. Mas faça com moderação, faça no ambiente controlado, sabe? Documentação. Tem aquela velha briga, ah, o produto não deixa eu fazer. Já peguei bastante isso, tá? Ou a pressão é tão grande que tem que entregar pra ontem, documentação vai ficar lá no fundo, eu nem vou atualizar. Acontece também. Então, como eu falei, é muito de cultura e pessoas. Porque no final, tudo é isso, né, gente? Nós somos pessoas e é a cultura da empresa, né? A Conta Azul disponibiliza um sandbox pro... Sim, sim. Como é nosso ambiente aqui, tá? A gente tem esse desenvolvimento que a gente testa local, a gente sobe todos os containers que a gente precisa na nossa máquina. A gente consegue fazer testes e tudo. Aí eu vou... No nosso fluxo downstream tem um testes, uma etapa ali, um raio de testes. Aí eu vou lá e mando para o sandbox. Aí o teste sandbox, aí valido com o time, valido com o produto. Aí está tudo certo? Vai para a prod. Aí tem uma outra raia de prod aí quando eu mando pra prod, que é mando pra master, pra master já vai direto pra produção fez o merge do PR, já é, já foi aí você monitora lá pra ver se tá tudo certinho em prod é o momento ali do friozinho na barriga aí deu tudo certo em produção não quebrou nada, aí a gente vai lá e valida testou, bonitinho, chama produto produto, ó, tá safe, é isso que a gente queria, manda o card pra pronto, e game over. É assim que funciona aqui. Rapaz, que novidade, parece que eles vão criar um outro ambiente ainda de homolog, similar ao de produção. Vai ter o de sandbox, vai ter o de homolog e vai ter o de produção. Mas ainda acho que não tá pronto ainda não, tá? Vão fazendo ainda. Vocês usam uma cloud só? É. A gente aqui usa a AWS primariamente. A gente usa os serviços básicos da AWS, nosso broker, por exemplo, é a SNSKS. A gente usa a RDS Aurora. A gente só tem post, a gente não tem banco no CICO ainda. S3. E tem um time que começou que começou GCP no produto. A gente está usando o API de lá da GCP. Mas o time de ciência de dados é 100% GCP aqui na Contasul. Então a gente tem as duas clouds, GCP e AWS. Produto, G de produto, é AWS. Aí só tem um time aqui que está começando a experimentar algumas coisinhas de GCP. No caso foi o API de o gateway deles. Legal. Alguma coisa de pipeline ou pipeline tudo fora? Pipeline nosso aqui é o Sirão, o mestre dos mestres. Qualquer coisa com ele é imagem doc, é Jenkins. Está ele aí, eu peço a ele, meu braço direito, ele fala assim, não, salva nós aí. Ele vai lá e salva. Mas a gente usa o Jenkins aqui pra entregar e o nosso repo aqui é GitHub. Ah, legal. Bom, obrigado, hein? Valeu. Show de bola. É isso então, meu povo? Olha, já se... Show de bola É isso então, meu povo? Mais uma Parabéns aí, Dantas, pela apresentação Muito bom, cara Essa foi até uma pergunta que eu já fiz, mas Na minha experiência, eu tive um crescimento Na empresa que eu tô Muito acelerado E isso, basicamente É uma empresa grande e a gente tem muitos heróis lá dentro. Então, rapidamente, eu me tornei um desses heróis. Um desses caras que construiu um grande sistema na empresa. Esse sistema vem tomando conta e vem, muitas vezes, roubando a sêmena dos outros. E acaba que gera algumas questões de ego. Como que tu vê isso e como que a gente controla isso dentro de uma empresa? Excel Como que tu vê isso e como que a gente controla isso dentro de uma empresa? Excelente pergunta, tá? Assim, eu não sou psicólogo, mas eu gostaria de ter uma segunda graduação, né? Eu tenho vários livros aqui, eu estudo, eu gosto de conversar sobre esse tema. É um negócio complicado, tá? Eu, desde pequeno, eu sempre fui ensinado a ser humilde, né? Isso da minha natureza de ajudar pessoas e tudo mais. Eu ouvi uma vez de uma esposa de um amigo meu, quando eu morei em Florianópolis, que ele é desenvolvedor também, ela é enfermeira obstétrica. Ela virou para mim e falou para mim e para o esposo dela, vocês que trabalham nos emissores, vocês são muito egocêntricos. Eu olhei para ela assim, veio uma resenha aí, né? Mas por que você está dizendo isso? Não, porque vocês fazem um negócio assim, vocês batam, eu sou foda. A gente cai nessa armadilha facilmente. E, cara, mais uma vez, falta de maturidade. Porque eu, para mim, desde que eu entrei na nossa área que me apaixonei, o que me deixava feliz mesmo, aquele momento de êxtase, é saber que o que eu fiz, o usuário tá felizão. Pô, Dantas, pô, Bahia, tu que tu fez aqui, tá me ajudando na minha empresa, cara, tô faturando, tô fazendo, resolveu um pipinão. Cara, eu chego e fico aliviadão, fico felizão da vida, fico no céu. Essa é a minha satisfação. Mas já tem pessoas que não. Rapaz, sou foda. Sou melhor do que todo mundo. Isso é uma armadilha muito comum. E assim, para resolver isso na empresa, o primeiro lugar é a cultura da empresa e uma habilidade de gestão para lidar com isso, que não é fácil de lidar. Tá, Diego? Não é fácil. E assim, cara, eu acho, para nós profissionais, é o que eu tenho feito e tenho dado certo até hoje. Quem tem que falar de você é o seu trabalho. Quem vai dizer o profissional que você é o cara fera, o cara que eu quero toda a iniciativa que você esteja comigo, é o resultado que você me entrega, não é o que sai da sua boca. Eu não preciso que você fique se vendendo, se vendendo, se vendendo. Ah, eu tenho 25 anos. Imagina se todo dia essa pessoa aqui escutasse e me dizendo, eu tenho 25 anos. Imagina se todo dia essa pessoa aqui escutasse e me dizendo, eu fiz cinco anos de experiência, trabalhei com Java, trabalhei com isso, fiz isso. Pô, cara, que cara chato, não tenta conversa, não. Aí vocês vão dizer de mim, né? Já pensou? Entende? Mas não, cara. E aí, galerinha? Pô, e aí, rapaz, todo dia eu aprend aprendendo alguma coisa, velho. Todo dia. Todo dia. Esse é o princípio. Todo dia, não sei nada. Isso ativa na sua cabeça a humildade. Eu não sei nada, eu tenho que aprender. Meu colega ali tem alguma coisa pra me ensinar. Todo mundo aqui teve uma vida diferente da minha. Todos. Entende? Passou por experiência diferente, pegou problemas diferentes. Eu tenho que aprender por cada um de vocês aqui. Se eu só sentar para conversar e tomar um café um dia, eu vou aprender cada coisa. Não tem a pensar nisso não. Entende? E é isso que é a chave essa. Se foi isso que você queria ouvir, acho que é a chave. Realmente, fomentar isso e às vezes cheirar um pouco do corporativo aquele que acaba pegando e criar um ambiente bom, né? Como fomentar um bom ambiente dentro da equipe. O ambiente tem que ser divertido. A ideia é essa. Tem que trabalhar suave. Gente, a gente se vê todo dia. Eu vejo mais o meu escolar de trabalho do que a minha esposa e meus filhos. Entende? Tem que ser divertido tem que entregar, pô, a gente arrebentou chegar de manhã, o que tem pra destruir hoje? e chegar 5, 6 horas que você foi encerrar ai, mandei ver hoje, tô feliz, entendi coisa pra caramba é isso aí, gente aí você recarrega suas baterias, não sei como vocês recarregam vão pra academia, vão pro jiu-jitsu vão ver a família, não sei. Cada um tem seu jeito de carregar a bateria. Outro dia de manhã, acordou, pau de novo. Vamos lá, vamos pra cima. E sempre pensando em evoluir. Sempre. Eu tenho que aprender qual é o livro, o que tá na hype aí, seguir tipo full cycle. Sempre no Zona 1 a gente recomendou. Cara, full cycle é divisor de águas. Um dev, vocês que são tech leads, né? Um dev que quer crescer na carreira, quer virar sênior, cara, faz o curso full cycle. Muito antes disso, Conta Azul, desde a SoftPunch falava isso. Você vai meter a mão, vai ter uma boa base de conhecimento, você vai ser o profissional antes e depois de ter feito o curso. Depois você me diz. Cara, um monte de feedback eu já tive disso aí. E eu não fiz o curso full cycle. Eu conheço o trabalho, conheço o Wesley, mas assim, nunca fiz o curso. Conheço o conteúdo e conheço a responsabilidade dele. Assim como todos nós aqui, né? Estamos fazendo os outros cursos dele, né? Mas vocês que são mentores, cara, pode recomendar pros seus devs. Vocês vão ver. Vai aprender café, vai aprender mensageria, vai aprender IPGator, vai aprender um monte de coisa que o cara nem sabia que existia. Entende? Tudo condensado num lugar só. Vai sair um outro dev. Tá bom. Olha o Zilli aí. Fez o curso em 2018. Aí ele já era gestor também. E fez o curso. Zilli, você pode falar aí como foi que te ajudou no papel de gestor desse conhecimento? falar aí como foi que te ajudou no papel de gestor desse conhecimento? Sim, trabalhei quatro anos na Softplan, dois anos no terceirizado, PG, SG e dois anos no Ministério Público. Trabalhei lá, sim. Quer falar aí, Zili? Você consegue falar, Zili? Eu tô sem câmera porque eu tô com o notebook fechado e onde eu tô aqui eu não consigo abrir, mas vocês estão me ouvindo? Sim. Isso, como eu comentei ali no chat, eu fiz o curso da Full Cycle em 2018, porque era um movimento que a Softplan estava fazendo pra reescrever o seu monolito de 18 milhões de linhas de código para microserviços .NET com React. E aí se fez necessário reciclagem de muitas pessoas, muitas coisas. Por mais que já eram assuntos que a gente já estudava de maneira fragmentada, o curso da Fullcycle foi onde eu comecei a indicar para todas as pessoas do time, como o Doutor comentou, e arquitetos já renomados na Softplan, tech leads, o feedback sempre foi muito positivo, que é um lugar onde concentra o maior número de informações robustas para uma carreira de desenvolvedor. Então, desde então, a gente recomenda. Show. Fala aí, Tarcísio. Estão me ouvindo bem? Primeiramente, boa noite, Dantas. Boa noite, pessoal, todo mundo aí então primeiramente, continuando ótima apresentação, questão de documentação acredito que é algo que a maioria das empresas tem muita dificuldade muitas empresas aquele cenário perfeito é algo quase que utópico, infelizmente mas aí, assim, acho que seria mais, da minha parte, seria mais uma Cenário perfeito é algo quase que utópico, né? Infelizmente. Mas aí, assim, acho que seria mais, da minha parte, seria mais uma orientação, um conselho, porque na empresa onde eu trabalho, eu já trabalho aí já há uns oito anos, e nos últimos dois anos é que eu consegui começar a iniciar o trabalho ali de mudar o mindset, principalmente da parte mais superior, né? A mim. E daí, com isso, a mudar o mindset, principalmente da parte mais superior a mim, e daí com isso, a questão do mindset de documentação, ter uma conversa mais refinada sobre as tarefas, as necessidades do cliente e tudo mais, e assim, acabou caindo no meu colo quase que, não nomeadamente, mas quase que um cargo de tech lead, e por isso que eu estou estudando junto com o pessoal a arquitetura com o MBA, para me preparar, mas para essa parte de preparar, quando já está trabalhando praticamente nessa função, como adquirir o conhecimento para essas tomadas de decisões? Até mesmo aí, uma pergunta também para o Leonan e o pessoal da Full Cycle, se teria um trabalho de mentoria, se a Full Cycle tem uma equipe para uma mentoria mais próxima da empresa, alguma coisa do tipo que dá para a gente conversar depois junto com a minha liderança, mas como obter essa experiência para tomar determinadas decisões e falar, gente, isso daqui, baseado nisso e nisso, a gente consegue alcançar esses objetivos de melhorar desempenho, performance, entregas, qualidade e como poderia fazer isso? Tá. Bom, eu vou falar um pouco depois o Dantas fala, tá? Eu acho que isso é bem importante da gente tocar. Tá, Silvio, só antes de eu comentar, eu só queria tirar uma dúvida se você refere-se à questão técnica, ou somente à questão técnica, ou também a nível de liderança, de assumir a rede ali, enfim, vamos fazer dessa forma, tem que ser assim, como é que você, qual situação exatamente você está passando? É mais a nível de liderança? Seria ambas, seria ambas. Porque hoje na empresa onde eu trabalho, eu que busco mais a questão de qualidade de desenvolvimento, a gente ainda não tem teste implementado e a gente já tem um sistema muito grande. Apesar de ser uma empresa pequena, ele é um sistema muito complexo de gestão de armazém de depósito, mais conhecido como WMS. Entendeu? Então, essas necessidades para otimizar o tempo de entrega, documentação, teste, entregas com mais qualidade, isso daí está partindo de mim para a gente poder começar a implementar, entendeu? Eu entendi. Tá. Cara, eu iria, eu acho que, eu não sei como é que funciona a questão de cultura dentro da sua empresa, mas eu vejo que isso é muito sobre cultura. Cultura no sentido de, primeiro, para você tomar decisões e trabalhar nesse nível que você quer, você vai trabalhar muito com dados. Então, vai fazer muita POC, vai reunir dados, vai trazer isso para o time, para o head, eu não sei como é que funciona a divisão aí de cargos, né, dentro da sua empresa, mas foca sempre em trabalhar a nível de dados. E por que que eu falo muito da cultura? Porque existem empresas que você tem uma abertura para se fazer isso e existem empresas que são mais fechadas. Essas empresas que são mais fechadas, evidentemente você vai ter uma dificuldade muito grande de tipo, cara, joga aqui no meu peito que eu vou atrás, vou resolver, vou trazer pra você e daí a gente vê o que que decide, né? Tem até um livro que é bem interessante dessa parte de mais da parte de liderança que fala sobre liderança situacional. Depois você dá uma pesquisada sobre isso. Mas basicamente é dividido em quatro etapas ali e cada etapa refere-se a um passo que você tem que dar, né? Você pede ajuda ou você apoia e coisas nesse sentido. Mas eu iria muito de o que eu quero fazer, como eu quero fazer estruturar bem essa ideia isso pra você primeiro, depois quais são os cenários que eu posso aplicar isso aqui, que não vai impactar em nada, mas eu posso mostrar o ganho de forma evidente e quando você vai mostrar o ganho eu acho que a grande maioria dos devs tem muita dificuldade, não é apresentar o ganho de eu reduzi x linhas de código. Isso pouco importa, principalmente se o cara que é gestor ou dono da empresa não for de cunho técnico. O ganho tem que ser apresentado tipo, cara, a gente vai reduzir custo. O que manda na cabeça do dono é custo. Custo ou receita. Então você só vai entrar na cabeça do cara com essas duas palavrinhas. E no final, na verdade, você pode substituir tudo por uma, que é ganhar mais dinheiro. Então tenta ir por uma abordagem de que você, sim, reúna dados técnicos, mas associa isso ao negócio, porque eu acho que isso vai ser cada vez mais comum. E aí, essa entrada de novas ideias, de novas propostas, vai ser algo muito mais simples das próximas vezes. Eu faria dessa forma, por exemplo. É óbvio que tem os pormenores ali, mas a gente não consegue cobrir aqui nesse momento. Dantas, quiser adicionar alguma coisa e tal? Cara, foi perfeito a tua fala, velho assim, na cabeça do gestor ele pensa em grana lembra quando eu comentei da POC de Gol como a gente fez pra trazer, quais os três pilares? velocidade de desenvolvimento ou seja, vamos poder entregar mais fazendo menos redução de custo, porque um pode consumir 600 MB de memória pra consumir, sei lá, 32 MB de memória, tem um chão enorme, né? Então isso na conta do cartão de crédito da empresa faz uma diferença grande. Ou seja, com um de 600, só um único de 600, eu faço o quanto do outro, né? E a satisfação das pessoas, né? Então, esses fatores, quanto mais você se municiar dessas coisas, é a cabeça de um gestor que você vai conseguir trabalhar. Acho que o Léo foi perfeito ali. Mas se você falar de objetividade, velocidade, grana, essa é a chave para a empresa poder crescer. Em algum momento você vai estar bem embasado. Hoje, apesar de, depois desse certo tempo, já batendo muito cabeça, a empresa acabou chegando num nível que o gerente mesmo, o diretor mesmo ele falou, olha, do jeito que tá aqui, tá difícil as entregas tão demorando muito a gente tá entregando com baixíssima qualidade, então a gente precisa realmente melhorar e a partir daí ele me deu essa abertura pra gente, pra pra eu conseguir propor mais e até mesmo implementar. Aí a segunda parte da pergunta que eu fiz foi justamente até mesmo como obter um caminho um pouquinho mais fácil, vamos dizer assim, não vai ter uma receita perfeita, mas um caminho mais fácil para obter essa maturidade para essas tomadas de decisões, porque por mais que a gente obteve essa abertura para implementar coisas novas, trazer arquiteturas, documentação, as coisas que a gente realmente precisa, mas a gente tem pouco prazo para errar. Então, ainda mais para quem tem pouca experiência, a dificuldade de... a pouca experiência de falar, olha, isso aqui vai funcionar. E como é que a gente... como é que eu poderia começar a fazer isso, vamos dizer assim? Tá. Se eu entendi bem a sua pergunta, você tá numa situação em que, eventualmente, você não tem tanta experiência, quer ajudar de alguma forma, mas não sabe se aquilo ali é a melhor solução. Da regra de negócio, eu já compreendi bastante, eu já compreendo bastante, já com meus oito anos de empresa, eu já consigo discutir direto com o diretor, a empresa é pequena, então eu converso direto com o diretor, meu gerente, então eu já consigo falar, olha, isso aqui funciona, isso aqui não funciona, a gente tem que fazer dessa maneira. Sobre a regra de negócio, eu já consigo determinar sobre isso, mas aí sobre a questão de documentação, ah, essa documentação é a que a gente precisa a gente precisa de teste desse jeito entendeu? mas essa parte dessa experimentação é que eu não tenho, vamos dizer assim eu não vou ter muito muita bagagem pra poder passar isso pra frente entendi, entendi é, cara, nesse caso aí eu trabalharia com microvitórias, basicamente. O que é micro vitórias? Até pelo receio que você tem, você tem um objetivo muito grande, muito amplo na sua cabeça. Qual é o mínimo, o MVP, o mínimo viável para você entender se aquilo faz sentido ou não? Porque baseado nesse mínimo, você faz, você não vai gastar muito tempo. Chega para o gestor, para o dono e fala, cara, eu fiz isso aqui. O que você acha? Faz sentido? Posso seguir nessa linha? Porque como você não tem essa... E eu acho que não é vergonha nenhum, tá? Me fala aí, o que você entende do que eu fiz aqui? Faz sentido ou não faz sentido? Tá caminhando pros objetivos da empresa? Porque aí você vai ter uma direção mais coesa até de onde partir. Porque talvez o que tá incerto na sua cabeça é o macro muito grande e você não tá conseguindo separar o que efetivamente você vai ter um resultado a curto prazo de forma rápida, entende? Pelo tom da sua fala, talvez esteja nessa ideia aí. Eu iria por esse lado, cara, micro vitórias e alinhamento constante ali com o gestor e tudo mais, perguntando se está fazendo sentido, se não está, ou se não está, cara, me ajuda aí, o que que você acha então que a gente tem que fazer, ou como, ou qual é a sua ideia, você não precisa nem me dizer como fazer, que talvez nem você saiba, mas me fala o final, o que que você pensa do final disso aqui, pra eu tentar te dar uma direção também, e a gente conseguir chegar num lugar, eu acho que essa troca de ideia ela é muito enriquecedora. Por experiência própria, por exemplo, aqui na Full Cycle a gente faz muito isso, cara. Às vezes eu sento com o Wesley, com o Luiz aqui, com outras pessoas também, com o Eula, e a gente tem muitas ideias. Só que a gente não sabe nem por onde começar e como começar. Ou muitas vezes são coisas que a gente nunca viu e... Por exemplo, a gente tem uma faculdade agora, então assim, a gente vem aprendendo muita coisa. Então vira e mexe, eu toco junto com ele, falo, cara, e aí, como é que é isso aqui? Me explica melhor, você acha que esse caminho aqui é bom? Aí ele fala, pô, não é interessante, cara. Pô, vamos pra esse então? Ah, esse aí não é tão caminho que eventualmente nem ele mesmo passou pra aquela situação e a gente desenvolveu algo novo, sabe? Eu ia dessa forma. Show. E você acha que uma consultoria pra dar uma, vamos dizer assim, uma alavancada, quase que uma muleta mesmo pra validar as propostas que tiver, porque às vezes vem devaneio, né, falar não, pra não cair no na armadilha do hype, né, dó não, isso aqui tá todo mundo falando, vamos fazer isso aqui, entendeu? Exatamente. Então a consultoria poderia ajudar com isso. Cara, consultoria ajuda, é... assim, ajuda, né, tem sempre os aspas ali no meio muito grande, depende muito da consultoria depende qual o objetivo que você está buscando essa consultoria porque tem consultoria que vai mais atrapalhar do que ajudar mesmo com o intuito de ajudar, né mas de forma geral sim, tende a ajudar show, show maravilha, obrigadão, gente. Valeu. Alguma coisa aí, Dante? Você falou alguma coisa? Rapaz, tudo perfeito. É isso aí, gente. Mica entregues. MVP. Uma coisa que o Zili falou pra mim há muito tempo, ele foi meu gestor, era tipo, você quer uma Ferrari, mas o cara anda a pé. Vamos dar uma bicicletinha pra ele depois a gente dá uma fusquinha uma moto, depois dá uma fusquinha e vai evoluindo até onde ele tem a Ferrari mas é isso aí show, bom é isso, Dantas, mais uma vez cara, muito obrigado aí tá, seja sempre bem vindo quando precisar eu que agradeço pessoal, muito obrigado por ter paciência em me escutar, foi um bate-papo seja sempre bem-vindo quando precisar. Eu que agradeço, pessoal. Muito obrigado por ter paciência em me escutar. Foi um bate-papo maravilhoso. Excelentes perguntas, tá? Muito bom mesmo. É sempre um prazer. Qualquer coisa, quem está ali, podemos conversar.