Eu entrei na programação de cabeça no finalzinho de 2022. Não foi um caminho gradual, do tipo "vou dar uma olhadinha e ver se gosto", foi mais um "preciso muito seguir esse caminho" dito em voz alta pra mim mesma. Comecei pelo básico: HTML, CSS, JavaScript.
Fui me aprofundando nos conceitos, caí num bootcamp muito bom do Boticário, daqueles que ainda abriam a porta pra você trabalhar lá dentro (confesso que gostaria de ter aproveitado ainda mais aquela oportunidade), mas foi por ali que consegui meu primeiro emprego e comecei a atuar de fato na área.
E aí começa a parte que eu quero contar de verdade: como eu aprendi a aprender e por que isso mudou completamente.
Antigamente, aprender programação era mais ou menos assim: você travava num problema, ia pro Stack Overflow, pesquisava muito e rezava um pai-nosso pra alguém já ter resolvido aquilo antes. Se tivesse resolvido, ótimo. Se não, você improvisava.
O resultado eram códigos meio Frankenstein, feitos de pedaços colados com um toque generoso de lógica de negócio no meio. Funcionava? Funcionava. Era bonito? Nem sempre. Mas foi assim que eu e boa parte de quem começou naquela época aprendeu que essa era a forma de aprender: pesquisar, quebrar a cabeça, testar, errar, repetir.
Esse processo lento tinha um valor escondido que eu só fui entender depois: ele me obrigava a realmente entender o problema. Não dava pra pular etapa.
Aí chegou a inteligência artificial. Comecei a usar ativamente em 2024, e confesso que foi um salto. Ainda não era boa o suficiente pra tudo, mas ali eu percebi uma coisa: eu não precisava mais gastar dias inteiros numa única feature.
Só que teve um detalhe importante. Eu ainda me sentia muito júnior no sentido de que estava aprendendo a pesquisar sobre os meus próprios problemas. E como eu ainda não sabia formular bem o que estava enfrentando, os resultados da IA não eram lá muito expressivos. Porque naquela época, e eu sinto que até hoje, vivências ainda contavam muito. A IA te dá o que você sabe pedir, e eu ainda estava aprendendo a pedir.
A IA não ia me salvar de não entender o que eu estava fazendo. Ela ia, no máximo, acelerar a minha ignorância se eu deixasse.
E foi essa percepção que me fez correr atrás do tempo perdido: buscar conhecimento sobre arquitetura e entender de verdade o negócio em que eu estava atuando na época.
Essa é a pergunta que eu mais ouço, e a resposta é mais direta do que parece: a IA não resolve.
A IA não tem a capacidade de pensar sobre um problema. Se ninguém pensou nele antes, ela não vai pensar por você, não é assim que ela funciona. Ela é excelente em preencher lacunas, sugerir caminhos, otimizar o que já existe. Mas alguém precisa ter desenhado o problema, entendido a regra de negócio e decidido como aquilo começa e como termina.
E é exatamente por isso que eu acredito que o futuro é sobre arquitetura. Sobre entender como as peças se encaixam antes de escrever a primeira linha. Sobre saber desenhar mentalmente onde o problema nasce e onde você acredita que ele deveria morrer.
Quando eu falo em "estudar arquitetura", não é decorar nome bonito pra impressionar em entrevista. É entender a ideia por trás de cada abordagem, porque cada uma resolve um tipo diferente de dor. Aqui vão as principais que eu acho que todo dev deveria ao menos entender o conceito:
Talvez a que mais combina com o meu ponto. DDD é uma abordagem que coloca o domínio do negócio no centro de tudo. A ideia é que devs e especialistas do negócio falem a mesma língua (a linguagem ubíqua), pra que o código reflita a realidade do problema, e não só a cabeça do programador. Conceitos como bounded contexts, entidades, value objects e agregados servem pra organizar a complexidade do negócio. Se você não entende o negócio, você não faz DDD, e é por isso que ela é tão relevante nesse novo cenário.
Popularizada pelo Robert C. Martin (o "Uncle Bob"), a Clean Architecture organiza o sistema em camadas concêntricas. No centro ficam as regras de negócio mais puras; nas bordas, os detalhes como banco de dados, framework e interface. A regra de ouro é a dependency rule: as dependências sempre apontam pra dentro. Na prática, isso significa que sua lógica de negócio não deveria nem saber qual banco de dados você usa. Troca de banco, troca de framework, troca de UI, o coração continua intacto.
Prima da Clean Architecture, criada pelo Alistair Cockburn. A ideia é isolar o núcleo da aplicação do mundo externo por meio de ports (interfaces) e adapters (implementações). Quer testar sem banco de verdade? Cria um adapter fake. Quer trocar de serviço externo? Troca só o adapter. O núcleo nem percebe. É maravilhosa pra testabilidade e pra manter o negócio desacoplado da tecnologia.
A clássica. Divide a aplicação em camadas horizontais: apresentação, aplicação/negócio, persistência e dados. É simples, é fácil de entender e ainda é a porta de entrada de muita gente. Nem tudo precisa ser sofisticado; às vezes a camada bem-feita já resolve.