3

Gostei muito de poder entender um pouco sobre como alguém que acompanhou a evolução da programação como você enxerga essa nova tecnologia que tem impactado tanto o nosso cotidiano.

Fiquei especialmente pensando na parte sobre:

dominar a arquitetura, o ecossistema e a regra de negócio

Hoje utilizamos IA para conduzir diversas atividades, inclusive para sugerir ou até definir arquiteturas. Como alguém que começou a programar mais recentemente, já na era dos frameworks consolidados e da clara separação entre frontend e backend, sinto certa dificuldade em arquitetar soluções melhores ou até mesmo em distinguir uma boa solução de algo apenas "aceitável" gerado pela IA.

Já ouvi desenvolvedores mais experientes dizerem que, para entender de verdade por que determinadas arquiteturas e padrões existem, é preciso primeiro sentir a ausência deles — convivendo com código ruim, sistemas difíceis de manter e decisões que geram problemas ao longo do tempo.

No meu dia a dia, trabalhando com IA, muitas vezes me vejo refém do resultado gerado. Se funcionou, sigo em frente; se não funcionou, penso que talvez outra abordagem ou arquitetura fosse mais adequada. O problema é que nem sempre consigo identificar o motivo.

Vocês têm alguma dica para melhorar esse processo de aprendizado?

Já li alguns livros sobre arquitetura e engenharia de software, mas tenho a impressão de que a experiência prática de ver algo dar errado e, a partir daí, projetar uma solução melhor ensina muito mais do que apenas estudar a teoria.

Carregando publicação patrocinada...
3

Excelente reflexão, Vini.
Você tocou exatamente na ferida mais profunda e assustadora da nossa área hoje.

Sabe qual é o maior perigo dessa era de frameworks consolidados, separação limpa de camadas e, agora, IAs gerando soluções prontas? É que vocês foram inseridos em uma realidade onde o "como fazer" foi totalmente automatizado, mas o "por que fazer" foi esquecido.

Quando eu comecei era o BASIC, passei pelo C++, Java, Visual Basic e depois eu me encontrei na web com ASP Clássico (que era um framework da microsoft) que usava predominantemente o VBScript (baseado no Visual Basic) em conjunto com HTML. Fui para o PHP e voltei para o C# (evolução do antigo Asp clássico da plataforma .NET) e um pouco de Swift, que depois foi substituindo pelo Objective-C. Aqui não tinha framework, você precisava entender o que passava pela veia do sistema e o que comunicava com as outras partes do seu código.

Os frameworks vieram bem depois, sempre foram úteis para resolver algum problema. Mas não aprender os paradigmas basilares tem seus trade-offs, como tudo na vida. O framework já resolve problemas que não precisa se preocupar em resolver, mas quando existe um problema profundo vai ser no conhecimento da raiz que vai entender como resolve-los. Entende?

Quando eu comecei, lá nos anos 80, a gente não tinha o luxo de errar sem pagar um preço altíssimo. Se você errasse a modelagem de um banco ou a estrutura de um loop, o sistema inteiro travava, o cliente perdia dados e você passava três a cinco noites sem dormir escovando bit para consertar. A gente aprendia na dor física e mental do prejuízo. Era brutal! Hoje, a IA cospe um boilerplate limpinho, com Docker configurado, padrões de projeto aplicados e, se funcionar no primeiro teste, o desenvolvedor dá git push e segue a vida. É vraaau!

Hoje você vira refém dos resultados porque a IA te entrega o destino final sem te mostrar o mapa da viagem. Não pegou um atalho (que já é ruim), você é teletransportado direto para o fim.

Dizer "é preciso sentir a ausência dos padrões para entender por que eles existem" é o caminho da razão. A teoria dos livros é linda, mas ela só faz sentido quando você olha para uma linha de código tenebrosa e pensa: "Caramba, se eu aplicar o padrão X aqui, eu resolvo essa bagunça".

Como você não tem tempo (e nem quer) ver a empresa onde trabalha falir só para aprender errando, você precisa induzir o erro de forma controlada. Se você quer mesmo sair do risco de cair no balaio da mediocridade e parar de aceitar o "aceitável" da IA para dominar a arquitetura na prática, mude sua postura com algumas atitudes:

1 - Inverta o jogo com a IA com engenharia reversa. Quando ela te der uma solução que funciona, questione os pontos fracos. Pergunte o "Por que essa estrutura e não a X?", "Onde essa arquitetura quebra se o volume de dados triplicar?" ou "Quais são os trade-offs dessa escolha?". Force a máquina a te ensinar os fundamentos. Exija que ela explore os riscos, as limitações e as brechas que podem se abrir principalmente no quesito segurança.

2 - Abrace o código ruim (o legado). Os livros dão a teoria, mas o aprendizado real vem do atrito. Peça para mexer naquele sistema antigo e problemático da empresa que todo mundo tem medo. Tentar refatorar ou isolar uma regra de negócio em um código macarrônico vai te ensinar mais sobre padrões de projeto do que mil páginas lidas. O importante vai ser entender como conseguiu dar cada passo, sem atalhos, para construir uma solução para o problema x.

3 - Sempre provoque o erro controlado. No seu ambiente local ou num docker, monte um projeto simples misturando tudo, o banco de dados, o front, a lógica no controller. Tente evoluir esse sistema. Quando você sentir a dor real da manutenção difícil, reescreva do jeito certo. A diferença vai fixar na sua cabeça para sempre. E lógico, chame seu techlead ou um dev senior para acompanhar o que fez localmente e apresente sua solução. Geralmente o tiozão cansado não viu o que viu e rola até um upgrade na carreira.

A IA é uma excelente assistente, mas uma péssima mentora se você for passivo. Não seja apenas um "aprovador de código". Quem domina a base e entende o ecossistema é quem dita as regras do jogo e. vai mais longe, ganha mais e cresce.

Sucesso na sua jornada!