Recentemente fui convidado a participar como facilitador em um workshop que tinha como intuito passar um overview sobre spring-boot e construção de APIs à um grupo de pessoas de um programa de iniciação profissional em TI. Ao ver a ementa do programa percebi que havia um descolamento entre o que foi ensinado e a necessidade da empresa, então ressucitei um projeto antigo e decidi tentar fazer este workshop de uma forma diferente: ao invés de simplesmente sair codando, abordar temas de engenharia de software para linkar os assuntos.
Alguns talvez tenham se decepcionado um pouco por não ter sido fulltime código, normal em uma turma de 50 pessoas onde alguns estão mais avançados (ou afobados dependendo do ponto de vista). E eu sinceramente curto muito código, mas com o passar do tempo a gente vai percebendo que a parte de abrir a IDE e codar é somente uma parcela pequena do todo. O que paga os boletos não é o Java, é o problema que o Java resolve. O java é uma ferramenta só! Eu até arrisco a dizer que os códigos que não fiz foram mais importantes do que os que fiz para o sucesso dos projetos que atuei. Se você não é iniciante e está aqui, sabe como alguns requisitos parecem mais programação orientada a boato.
Bom, preferi decepcionar alguns para garantir que o maior número de pessoas daquela turma quando forem criar uma API lembre das analogias que fiz com o McDonalds e coisas da vida real e façam entendendo um pouco o porquê das coisas.
Pensando nesse evento marcante em minha vida profissional, decidi trazer isso para internet e talvez ajudar outras pessoas que se sentem perdidas neste inicio de carreira.
Agora vamos a um TL;DR para que possa decidir se continua lendo este artigo ou passa para o próximo.
Ao longo de alguns artigos irei tentar ensinar sobre construção de backend Java com spring-boot mas de uma forma que seu raciocinio seja util para o mercado. Para isso faremos o seguinte:
Parte 0 (este artigo) Contexto: minha motivação, como enxergo o mercado de programação, programas de iniciação e qual é o nosso papel dentro das empresas.
Parte 1 Entender problemas: Proposta de um tema real, onde raciocinarei sobre como poderia soluciona-lo. Definindo quais são os atores envolvidos, quais são as limitações tecnológicas, alguns tópicos importantes de engenharia de requisitos e principalmente a definição de pronto do MVP (DoD)
Parte 2 Modelagem de APIs: Definição das APIs, endpoints e contratos. Talvez uma abordagem de documentação de APIs pouco usual com Swagger Editor (dependendo do meu humor).
Parte 3 Boot do projeto com Spring Boot: Iniciar o projeto com spring-boot e criar os primeiros endpoints funcionais. Uso do Postman para realizar as chamadas HTTP (até aqui sem persistência).
Parte 4 Problematização: Propositalmente problematizar o que foi feito anteriormente, para explicar a necessidade de separarmos a aplicação em camadas e garantir que cada um tenha acesso somente aquilo que lhe diz respeito.
Parte 5 Persistência: Adicionar persistência ao projeto, abordando alguns tópicos como customização de repositórios e paginação.
Parte 6 Autenticação e segurança: Como garantir que só quem tem permissão use meus endpoints?
Parte 7 Integração: Implementar integração REST com aplicações externas, estratégias de resiliência.
Parte infinita: só Deus sabe.
IMPORTANTE: propositalmente os códigos criados inicialmente terão problemas que parecerão obvios aos mais avançados, peço que deixem a ansiedade de lado e esperem até o último post para não confundir quem ainda mal sabe ligar o pc.
Necessidade das empresas versus programas de formação
Desde que comecei a programar profissionalmente observo que há uma dicotomia estranha no mercado: de um lado empresas com vagas e querendo bons profissionais, por outro lado grandes potenciais sendo perdidos por conta de metodologias de ensino desorganizadas ou descoladas da realidade. Alguns poucos conseguem se virar sozinhos e na insistência conseguem uma oportunidade.
A qualidade de profissionais sêniores já não é das melhores, visto que alguns tem dificuldade de sintetizar em palavras o que precisam fazer, imagine juniores que precisam conciliar o básico que sabem com o problema de negócio a ser resolvido? Enxergo boa parte dos candidatos a juniores como o Batman com seu cinto de utilidades incompleto tentando lutar com o coringa enquanto sua calça está caindo e a população não para de gritar “vai, bate nele”.
O iniciante está tentando entender o problema, diversas siglas de negócio, com um conhecimento superficial de tecnologia enquanto muitas vezes o resto do time não tem tempo e disposição para ajudá-lo mas o cobra igualmente. Nisso muitos corpos ficam pelo caminho, dentre eles muitos talentos.
Bom, não gosto disso nenhum pouco. Acho que alguns milhares de dinheiros são jogados no lixo ano após ano tentando formar talentos. Turmas de 10, 20, 30 ou mais onde o aproveitamento é menor que 10%. Currículos inflados e desconexos, softskills mal trabalhadas, conceitos importantes sendo ignorados e principalmente a falta de um objetivo claro.
E se eu te falar que tudo que você precisa saber já está ai, de graça e talvez tu não precise gastar 1 centavo em cursos? Pois é, bom ou mal cheguei onde cheguei sem gastar um cent com cursos. Mas isso não significa que não estudei kkk Conheço mais alguns, que assim como eu trilharam esse caminho. O segredo? Se inscreve nessa lista de espera que no dia 30/02/2026 irei fazer uma aula aberta gratuita, posteriormente vou lhe colocar em um grupo no whats onde terá acesso exclusivo à uma comunidade e a meu workshop "criando um sistema batalha de super heróis com a API da MARVEL". Zoas kkkk
Na boa? Você pode aprender APIs lendo artigos acadêmicos, livros ou RFCS isso tá por ai gratuito na internet, conteúdo não falta. Meu objetivo aqui vai ser tentar conectar os pontos, facilitar o aprendizado e criar dúvidas para que consiga de fato aprender algo que seja conectado com a realidade. Que numa entrevista, quando lhe perguntarem como resolver um problema você consiga pensar algo além de public static void main(String[] args)....
Nosso combinado é que 50% do tempo vai ser eu tentando explicar e outros 50% vai de você, com MUITA paciência focado em aprender. Uma coisa não tenho dúvidas: vagas no mercado tem, mas para consegui-las precisa ter um diferencial. Qualquer coisa, me acha no linkedin, bora lá.
Indiana Jones dos binários: a psicodelia que me faz ser apaixonado
Para entender como penso a respeito da profissão, do que o mercado precisa vamos a um breve momento de insanidade que demonstra minha paixão pela engenharia de software e por que não podemos minimizar nosso papel:
Podemos derivar que todo programa que escrevemos acaba virando uma sequência de zeros e uns que será processada pela CPU de uma máquina. Como aprendemos na matemática o universo dos números é infinito, logo toda sequência possível de zeros e uns já existe no infinito dos números binários. Sendo assim, todo programa que já foi escrito e aqueles que ainda serão escritos já existem e nosso papel não é criar algo, mas sim descobrir! Seríamos nós exploradores do universo binário? Investigadores? Hackers?
Boiou nesse devaneio? Imagine que a máquina entende somente dois algarismos zero e um. Tudo que você escreve na sua linguagem favorita, lá no fim das contas vai se tornar uma sequência de binários. Matematicamente, já existe uma sequência infinita de zeros e uns nesse universo imaginário e quando recebemos um problema para resolver com código, se pararmos para pensar a solução já existe neste universo e nosso papel como desenvolvedores é encontrá-la.
Fácil né? Pois bem, até algum tempo atrás seria basicamente receber requisitos e sair codificando para encontrar o tesouro. Porém, atualmente nós exploradores digitais temos um desafio muito mais complexo, não basta escrever código. É como se estivéssemos em um daqueles jogos de escape, onde precisamos decifrar uma série de enigmas para entender o que precisa ser codificado e depois de achar uma solução, precisamos testar várias hipóteses para garantir que essa sequência binária possui a qualidade esperada. Ou seja, não é qualquer sequência binária é a sequência binária que resolve o problema da forma mais eficiente possível!
Foi-se o tempo que saber fazer código por si só era motivo para altos salários, pelo contrário agora com a Ia se você entende muito bem os requisitos pode passar para um agente criar o código. Nosso papel como exploradores digitais tem se tornado cada vez mais sobre entender problemas e requisitos e menos sobre código.
Particularmente eu, Emiliano, valorizo muito mais aquele profissional que entende o problema, tenta explora-lo propondo soluções ao time do que o amostradinho que dá uma de herói e sai codificando igual um psicopata. Se você está iniciando, por mais estranho que seja, entenda que o tempo gasto entendendo o problema é um investimento para evitar o retrabalho!
Aprendizado sem uso é o memory leak humano
É deste devaneio, que surge a ideia que para treinar um Júnior dos dias de hoje deveríamos passar mais tempo guiando-lhes em uma jornada exploratória na solução de um problema real do que pedindo para fazerem um jogo da velha em Java no terminal, pedindo para inverter árvores ou resolver o problema do caixeiro viajante. Pelo amor de Deus né, qual a conexão disso com o mundo real? Ok, é uma demonstração de lógica e algoritmos, mas de que adianta se quando esta pessoa entrar em um time ela vai ter que lidar com APIs, JSON, sistemas distribuídos, bancos de dados e mais uma série de coisas que por si só dariam meses de estudo?
Minha experiência com programas de formação
Todos programas de formação de talentos que já acompanhei (e não foram poucos) pecam nos mesmos pontos:
- Descolamento entre a ementa dos cursos e a realidade da empresa;
- Professores que por vezes estão aprendendo junto com os alunos, sem experiência de mercado ou que simplesmente estão tentando se virar para atender à uma ementa que foi proposta por alguém.
- Falta de um objetivo claro (as pessoas se sentem à deriva, sem saber quais são os próximos passos).
- Ignoram os conceitos básicos de engenharia de software como levantamento e interpretação de requisitos, qualidade de software (baixo acoplamento e alta coesão), arquitetura de sistemas, etc.
Pode parecer que estes temas são mega complexos e alguns profissionais fazem questão de fazer parecer assim, seja para soarem fodões ou simplesmente por que as vezes nem eles entendem o que estão falando.
Pois é, tem muito profissional papagaio por aí. Que se vê na obrigação de falar sobre o que não entende só para se manter visível ou então por que o hype exige. E nessas muitos iniciantes se veem frustrados, por se sentirem incapazes de entender algo que a pessoa trata como se fosse trivial.
Minha professora de iniciação a pesquisa científica em matemática uma vez disse que tu podes se considerar um bom mentor quando tu consegue explicar um conceito a uma criança de cinco anos. Aquilo fica pulsando na minha cabeça desde então e comecei a observar isso: existem pessoas que são capazes de passar conteúdos de forma tão sutil, natural que aquilo penetra na cabeça das pessoas (talvez o Gustavo Guanabara seja o maior exemplo disso, há mais de 10 anos indico a playlist de java dele). E na computação compreender fundamentos é essencial, pois até a coisa mais moderna que existe é feita com base em um ou alguns conceitos "antigos". Vide a inteligência artificial que agora parece mágica, mas que possui décadas de estudo (antes mesmo do advento dos computadores). Então pessoas que não possuem os fundamentos, acham que é mágica e isso abre brecha para teorias da conspiração de um mundo onde seremos escravos de máquinas kkkk.
Objetivos em um texto nada objetivo (hipocrisia)
Chega de filosofia, vamos direto ao ponto: se você quer aprender algo, precisa de um objetivo! É igual quando ensinei minha filha a andar de bicicleta: teu objetivo é chegar no ponto X, e conforme ela atingia o objetivo eu afastava cada vez mais até ela conseguir andar com um trajeto criado por ela mesma.
No início, um estudante confia que seu mentor vai organizar esse trajeto. Eu costumo tentar propor a solução de um problema real (nada de criar um sudoku)! Percebam outro ponto importante, ensinar a andar de bicicleta não se trata de colocar um vídeo do YouTube com “a teoria sobre andar de bike” ou eu andando de bicicleta e ela anotando ou tentando loucamente acompanhar. Ela senta na bicicleta, ajudo a ajustar o banco para o tamanho ideal, no início à seguro enquanto aprende como o pedal influencia no movimento e aos poucos vou dando autonomia para ela pedalar cada vez mais até que solte por completo.
Engenharia de software se aprende na prática, por que se for seguir a risca as teorias, existem tantas que talvez demore anos para fazer seu primeiro “Hello world” útil.
Tópicos que considero importantes
Vamos à um briefing do que gosto de trabalhar minimamente para garantir que um júnior consiga ter um aproveitamento rápido nas squads:
Engenharia de requisitos: uma vez definido o problema entender bem quem são os atores envolvidos, quais os fluxos de negócio e principalmente delimitar qual o perímetro do que iremos resolver (Definition of Done do MVP). Se teu dev não sabe ler e interpretar requisitos como espera que ele faça algo? Todo card vai ter a classe, linha e o que deve ser feito?
Modelagem de banco de dados: não estou falando de diagramas ER, às vezes simplesmente entender “quais os cadastros que preciso ter em um banco de dados?”.
Comunicação entre aplicações: conceitos de protocolos, APIs, Rest e boas práticas, conceitos de comunicação síncrona x assincrona, mensagerias e EDA. Ninguém quer colocar em produção um sistema sem utilidade…
Design e padrão de projetos: problematizar propositalmente alguns pontos dos requisitos para mostrar na prática a utilidade de alguns padrões e boas práticas. Tirando da cabeça do indivíduo tudo aquilo que é bullshit.
Qualidade de software: nada de criar software e esquecê-lo para alguém testar! Cada vez mais o desenvolvedor precisa entender sobre qualidade de software e não somente sobre testes unitários. Gosto muito de abordar um tema negligenciado que é a qualidade de requisitos, que quando bem trabalhada evita muito retrabalho e consequentemente economia de recursos.
Tradeoffs de arquitetura: endender o porquê de algumas decisões e o preço delas.
Bom agora que consegui explicar um pouco como minha mente caótica funciona, se você chegou até aqui está livre para decidir continuar nessa imersão ou procurar outra fonte de estudos kkkk
