Como menciona o diretor de tecnologia Jean Pierre Lessa e Santos Ferreira, existe uma geração inteira de desenvolvedores que aprendeu a construir aplicações web sem entender o que acontece por baixo das abstrações que usam todos os dias. Sabem configurar rotas em um framework de backend, mas não sabem o que é uma conexão TCP. Sabem usar um ORM para consultar banco de dados, mas nunca escreveram uma query SQL complexa sem assistência de ferramenta. Sabem colocar uma aplicação em produção com um comando de deploy, mas não conseguem depurar um problema de performance porque não entendem como o servidor web que hospeda a aplicação aloca recursos.
Continue lendo e descubra por que entender o que está por baixo do framework não é nostalgia técnica; é o que separa desenvolvedores que depuram sistemas complexos dos que rezam para o problema sumir sozinho.
Como a cultura de frameworks e abstrações moldou uma geração de desenvolvedores tecnicamente dependentes?
O crescimento dos frameworks de desenvolvimento foi, em grande medida, uma resposta legítima a um problema real: o custo de construir as mesmas partes comuns de sistemas diferentes do zero era alto, propenso a erros e sem valor diferencial para o produto final. Frameworks que abstraem autenticação, roteamento, validação, comunicação com banco de dados e renderização de interface permitem que times foquem nos problemas específicos do seu domínio em vez de reinventar infraestrutura já resolvida. Como destaca Jean Pierre Lessa e Santos Ferreira, esse é um ganho real de produtividade que não deveria ser romanticamente descartado.
O problema não está no uso de frameworks; está na forma como eles são ensinados e adotados. Cursos, bootcamps e tutoriais que ensinam desenvolvimento por meio de frameworks raramente incluem uma explicação adequada sobre o que o framework está fazendo por baixo das abstrações que expõe. Um desenvolvedor que aprendeu React sem entender o DOM virtual e sem compreender o modelo de renderização do navegador pode construir interfaces funcionais, mas vai ter dificuldade genuína para otimizar performance, para depurar problemas de renderização ou para avaliar se React é a ferramenta certa para um caso de uso específico. O framework se torna a lente pela qual o desenvolvedor enxerga todos os problemas, o que é limitante da mesma forma que qualquer outra visão de mundo excessivamente estreita.
Segundo Jean Pierre Lessa e Santos Ferreira, o mercado de trabalho agrava o problema ao valorizar, especialmente em triagens iniciais, a familiaridade com tecnologias específicas em detrimento da compreensão de fundamentos. Anúncios de vaga que listam cinco ou seis frameworks como requisitos, sem mencionar nenhum conceito fundamental, enviam uma mensagem clara sobre o que é valorizado.
Desenvolvedores que recebem essa mensagem investem seu tempo de desenvolvimento profissional aprendendo ferramentas, não princípios, criando um ciclo que reproduz exatamente o perfil que, quando o sistema escala ou quebra de formas inesperadas, não tem a bagagem técnica necessária para resolver o problema.
Quais são as consequências práticas da falta de compreensão de fundamentos na qualidade dos sistemas construídos?
A consequência mais imediata e mais visível é a degradação de performance em sistemas que crescem além do contexto para o qual foram inicialmente desenvolvidos. Um desenvolvedor que não entende como queries de banco de dados são executadas pelo motor de banco de dados não consegue identificar que um ORM está gerando um problema de N mais um queries até que o sistema esteja lento em produção com dados reais. Um desenvolvedor que não entende como o garbage collector da linguagem funciona não consegue identificar que um padrão de código aparentemente inofensivo está causando pausas de coleta que impactam a latência de requisições. Esses problemas são depuráveis por quem tem o conhecimento de fundamentos para saber onde olhar, e são misteriosos para quem não tem.
Conforme Jean Pierre Lessa e Santos Ferreira, a segunda consequência é a dificuldade em tomar decisões de arquitetura que vão além das opções que o framework já oferece. Quando o sistema cresce até o ponto em que as abstrações do framework se tornam limitações, o desenvolvedor que só sabe operar dentro dessas abstrações fica preso entre duas opções igualmente problemáticas: trabalhar em torno das limitações do framework de formas que criam débito técnico crescente, ou propor uma mudança de tecnologia que o time não tem capacidade de avaliar criticamente porque nunca entendeu os fundamentos que a nova tecnologia também abstrai. O resultado frequente é a adoção da segunda opção, trocando um framework cujos problemas são conhecidos por um novo, cuja curva de aprendizado vai revelar problemas similares.
A terceira consequência, frequentemente ignorada até que seja tarde, é a vulnerabilidade de segurança criada pelo uso de abstrações sem compreensão do que elas protegem e do que elas deixam exposto. Desenvolvedores que usam queries parametrizadas de um ORM sem entender por que essa abordagem protege contra injeção de SQL são igualmente suscetíveis a construir uma query dinâmica em um caso especial que o ORM não cobre. Desenvolvedores que usam uma biblioteca de autenticação sem entender os mecanismos de segurança que ela implementa tendem a configurá-la de formas que expõem superfícies de ataque que a biblioteca foi projetada para eliminar.
Como desenvolvedores podem construir o entendimento de fundamentos que o ecossistema de frameworks não incentiva?
O caminho mais eficaz para construir compreensão de fundamentos não é abandonar os frameworks que se usa, mas desenvolver o hábito de investigar o que acontece por baixo deles em situações específicas de problema ou curiosidade. Quando um comportamento inesperado aparece, em vez de buscar a solução no Stack Overflow e seguir em frente, investir o tempo em entender por que aquela solução resolve o problema específico constrói, ao longo do tempo, um mapa mental de como as camadas de abstração interagem que nenhum tutorial consegue ensinar diretamente. Esse hábito de investigação é o que separa desenvolvedores que crescem tecnicamente de forma consistente dos que acumulam anos de experiência sem proporcional profundidade de entendimento.
Projetos pessoais deliberadamente construídos sem o framework habitual são outro caminho poderoso para expor gaps de conhecimento de fundamentos. Construir uma aplicação web simples sem framework de backend, usando apenas as bibliotecas padrão da linguagem, obriga o desenvolvedor a lidar com conceitos que o framework normalmente oculta: parsing de requisições HTTP, gerenciamento de rotas, serialização de respostas, conexão com banco de dados. De acordo com o diretor de tecnologia Jean Pierre Lessa e Santos Ferreira, esse exercício raramente produz código que deveria ir para produção, mas consistentemente produz desenvolvedores com entendimento significativamente mais profundo do que o framework que normalmente usam está fazendo por eles.
Autor: Diego Rodríguez Velázquez