O dilema das estruturas

Como desenvolvedor, frameworks geralmente são a primeira coisa que você pega quando quer acelerar as coisas e mantê-las confiáveis. As pessoas geralmente falam sobre frameworks como se fossem a solução perfeita que pode resolver todos os seus problemas, tornando o desenvolvimento mais rápido, fácil e eficiente. No entanto, se você tem alguma experiência, sabe que frameworks não são uma solução única para todos. Escolher o certo pode agilizar seu trabalho, mas a escolha errada pode levar a dores de cabeça no futuro, atrasando você justamente quando você precisa agir rápido.

Nesta postagem do blog, vamos mergulhar nos desafios e estratégias reais que vêm com a escolha e o uso de frameworks. Analisaremos as armadilhas potenciais, como evitá-las e maneiras de manter sua base de código flexível — mesmo quando um framework está em jogo.

O relacionamento que você não sabia que estava entrando

Comprometer-se com um framework é um pouco como entrar em um relacionamento de longo prazo. E não é algo para se encarar levianamente. Diferentemente de uma biblioteca simples ou de um pequeno utilitário, frameworks vêm com opiniões — muitas delas. Eles impõem estrutura e metodologia ao seu aplicativo, quer você goste ou não.

É crucial lembrar que os criadores de frameworks têm suas próprias prioridades. Eles estão resolvendo SEUS problemas, não os seus. Eles não lhe devem nada (a menos, é claro, que você tenha um amigo na equipe interna do framework, nesse caso, sorte sua). Se as coisas derem errado, especialmente no fundo do seu projeto, você pode se dar mal. Agora você está preso consertando-o, ou pior, arrancando-o completamente.

Não é divertido, certo?

Então, antes de se amarrar a uma estrutura, certifique-se de que ela realmente se encaixa no que você precisa. Caso contrário, você está rolando os dados.

Problemas FAANG

O autor não tem ideia se FAANG se tornou MAANG, MANGÁ ou se agora estamos todos apenas em um anime.

É aqui que a experiência realmente conta. Quando as empresas crescem rapidamente, elas frequentemente enfrentam desafios que nenhuma solução pronta para uso pode lidar. A escala desses problemas as força a criar suas próprias ferramentas — bancos de dados personalizados, mecanismos ETL, ferramentas de BI — o que você quiser. Gigantes da Big Tech como Google, LinkedIn, Spotify e Netflix lideraram o caminho, construindo e disponibilizando ferramentas de código aberto com as quais o resto de nós agora pode brincar.

Mas aqui está a questão: essas ferramentas não foram criadas para serem universalmente aplicáveis. Elas foram criadas para resolver problemas específicos que a maioria das empresas nunca encontrará. Engenheiros que trabalharam nessas grandes empresas estão acostumados a lidar com esses tipos de desafios — eles criaram soluções que operam em uma escala que a maioria de nós só consegue imaginar. Então, quando eles mudam para empresas menores, as decisões de estrutura e ferramentas que eles tomam são baseadas em uma compreensão profunda tanto do poder quanto das armadilhas dessas tecnologias.

Resistência contra estruturas

Ultimamente, tem havido uma pequena rebelião se formando — as pessoas estão ficando cansadas de frameworks. Especialmente no mundo JavaScript, os desenvolvedores estão fartos da rotatividade constante. Você provavelmente já viu: toda vez que uma atualização importante cai, você tem que reescrever partes significativas da sua base de código apenas para permanecer relevante. E nem me faça começar a falar sobre o ciclo interminável de mudanças drásticas.

Essa frustração deu origem a um renascimento de pilhas mais simples e estáveis. Coisas como HTML vanilla, CSS, jQuery, PHP e SQLite estão voltando entre os desenvolvedores que priorizam fazer as coisas em vez de permanecer na vanguarda da tecnologia. Sim, pode parecer um pouco "old-school", mas está longe de ser obsoleto. Com uma pilha mais simples, você pode iterar rápido e entregar ainda mais rápido. Claro, frameworks mais novos como React, Node.js e Flask têm seu lugar, mas às vezes você não precisa de todas as coisas sofisticadas. Às vezes, manter o que funciona pode lhe poupar muita dor de cabeça.

O Complexo Industrial Estrutural?

Os frameworks estão se tornando... superestimados? É difícil não notar que alguns frameworks parecem mais ferramentas projetadas para atrair financiamento de VC do que para resolver problemas reais de desenvolvedores. É como se houvesse um ecossistema inteiro empurrando os desenvolvedores para esses frameworks, apenas para eles perceberem mais tarde que, uma vez que escalam, estão presos a plataformas caras. Claro, frameworks como Databricks são de código aberto e gratuitos para começar, mas conforme você cresce, você é empurrado para suas soluções empresariais. E de repente, seus custos de hospedagem e operação estão nas alturas, enquanto um simples VPS poderia ter sido suficiente.

Parece um pouco uma armadilha, não é?

Atraso na decisão-quadro

Aqui vai um conselho que eu juro: não tenha pressa em escolher um framework . Não se comprometa até que sua arquitetura esteja completamente desenvolvida.

A estrutura deve ser a última coisa com que você se preocupa, não a primeira.

Primeiro, certifique-se de que sua arquitetura é sólida. Conheça seus principais componentes e como eles vão interagir. Depois de ter isso, você pode avaliar frameworks com uma compreensão clara de onde eles podem se encaixar — ou se eles se encaixam.

Essa abordagem garante que seu design seja sólido e adequado às suas necessidades específicas. Quando chegar a hora de considerar uma estrutura, você poderá ver claramente onde ela pode aprimorar sua arquitetura sem limitá-la.

Antes de começar a usar qualquer framework, pergunte a si mesmo: você realmente, verdadeiramente precisa dele? Claro, frameworks podem adicionar camadas de automação e conveniência, mas eles também vêm com seu próprio conjunto de limitações. Se seu aplicativo tem requisitos exclusivos, frameworks podem não funcionar bem com eles.

Pense muito bem sobre os benefícios a longo prazo em comparação com as limitações.

Tornando os Frameworks Dispensáveis

Se você decidir que uma estrutura vale o risco, certifique-se de que ela seja fácil de substituir. Sim, você ouviu direito. Crie alguma flexibilidade para que, se precisar abandoná-la mais tarde, não seja uma tarefa monumental. Veja como:

Resumo de suas dependências

Mantenha as mãozinhas sujas do framework longe do seu código principal. Use interfaces para abstrair a funcionalidade do framework para que sua lógica de negócios não dependa do framework diretamente.

Digamos que você esteja usando o TensorFlow para machine learning. Em vez de incorporar o código TensorFlow em todo o seu aplicativo, defina interfaces para manter as coisas organizadas e abstratas:

 from abc import ABC, abstractmethod import tensorflow as tf class ModelTrainer(ABC): @abstractmethod def train(self, data): pass class TensorFlowTrainer(ModelTrainer): def train(self, data): # TensorFlow-specific training logic model = tf.keras.models.Sequential([...]) model.compile(optimizer='adam', loss='sparse_categorical_crossentropy') model.fit(data, epochs=5) return model

Ao fazer isso, sua lógica central não fica fortemente acoplada ao TensorFlow. Se você precisar mudar para outra estrutura de machine learning, é só uma questão de trocar a implementação.

Injeção de dependência (DI) é sua amiga

Em seguida, vamos falar sobre Injeção de Dependência (DI). Essa técnica permite que você injete implementações específicas de suas interfaces em suas classes, mantendo sua base de código desacoplada e modular.

 class TrainingPipeline: def __init__(self, trainer: ModelTrainer): self.trainer = trainer def execute(self, data): return self.trainer.train(data) # Inject the TensorFlowTrainer implementation pipeline = TrainingPipeline(TensorFlowTrainer())

Agora seu código é flexível, fácil de testar e pronto para qualquer coisa que o futuro lhe reserva.

Adote a Inversão de Controle (IoC)

Para o máximo em flexibilidade, eleve as coisas a um nível superior com Inversão de Controle (IoC). Este padrão permite que você especifique implementações em um arquivo de configuração ou um local centralizado no seu código. É a cereja do bolo da sua arquitetura agnóstica de framework.

Aqui está um exemplo de como isso pode funcionar com uma abordagem baseada em configuração:

 # config.py class Config: TRAINER = 'my_project.trainers.TensorFlowTrainer' # main.py import importlib class TrainingPipeline: def __init__(self, trainer_class: str): module_name, class_name = trainer_class.rsplit('.', 1) module = importlib.import_module(module_name) trainer_cls = getattr(module, class_name) self.trainer = trainer_cls() def execute(self, data): return self.trainer.train(data) # Inject the trainer specified in the configuration from config import Config pipeline = TrainingPipeline(Config.TRAINER)

Agora, se você precisar substituir o TensorFlow por outro framework de machine learning, basta atualizar a configuração e continuar. Sem problemas, sem drama.

Conclusão

Lembre-se, frameworks devem servir a SUA arquitetura, não ditá-la. Com planejamento cuidadoso e abstração estratégica, você pode colher os benefícios dos frameworks sem ficar preso em dependências de longo prazo. O truque é manter o controle. Então, da próxima vez que você estiver prestes a mergulhar em um framework, dê um passo para trás e lembre-se: você dá as cartas aqui.

Obrigado pela leitura!

Alguma pergunta? Deixe seu comentário abaixo para começar discussões fantásticas!

Dê uma olhada no meu blog ou venha dizer oi 👋 no Twitter ou inscreva-se no meu canal do Telegram . Planeje o seu melhor!