4 mitos em engenharia de software com Edu Matos

Mito 1: "Uma Linguagem X É Lenta"

A ideia de que linguagens como JavaScript ou Python são "lentas" por natureza ignora um ponto crucial: o desempenho real depende do contexto de uso. Aplicações geralmente se enquadram em duas categorias:

• CPU-bound: Tarefas intensivas em processamento (ex.: transcodificação de vídeo).
• I/O-bound: Operações que dependem de entrada/saída (I/O) (ex.: acesso a banco de dados, chamadas de rede).

Na prática, aplicações web são majoritariamente I/O-bound. Nessas situações, otimizar operações de I/O (como consultas a bancos de dados ou acesso a mensgens em um message-broker) traz ganhos muito maiores do que trocar de linguagem. Linguagens como Go ou Node.js facilitam concorrência para I/O, mas em cenários de CPU intensiva, Rust ou C podem ser mais eficientes. A "lentidão" raramente está na linguagem, mas na arquitetura e falta de otimizações.

Mito 2: "Microsserviços São Melhores que Monolitos" (e Vice-Versa)

Nenhuma abordagem é universalmente superior. A escolha depende do momento e necessidades do negócio:

• Monolitos são ideais para começar: simplificam desenvolvimento, reduzem complexidade e aceleram entregas iniciais.
• Microsserviços (ou sistemas distribuídos) ganham relevância quando:
  • Partes específicas exigem escalabilidade independente.
  • Falhas pontuais não podem derrubar todo o sistema.
  • Custos de escalar um monolito tornam-se proibitivos.

A chave é começar com um monolito bem estruturado (componentes isolados, contratos claros) e migrar para microsserviços apenas quando houver uma "dor" real, como por exemplo dificuldade de evoluir features ou escalar. A complexidade de sistemas distribuídos (latência, falhas de rede) não deve ser subestimada.

Mito 3: "Bancos de Dados SQL Não Escalam"

Bancos relacionais como Postgres ou MySQL escalam sim (pelo menos até um certo ponto), mas exigem estratégias adequadas:

• Para leitura:
  • Índices bem desenhados.
  • Réplicas de leitura para distribuir carga.
  • Caches (ex.: Redis) para dados pouco alterados.
  • Desnormalização ou views materializadas para consultas complexas.
• Para escrita:
  • Batching (agrupar inserções em lotes).
  • Processamento assíncrono (filas para diluir operações).
  • Transações otimizadas.

A ideia de que bancos SQL não escalam geralmente surge de problemas de configuração (ex.: índices faltantes) ou uso inadequado. Soluções como data warehouses (BigQuery, Snowflake...) complementam casos analíticos, mas o SQL permanece robusto para maioria das aplicações.

Mito 4: "Trunk-Based Development É a Solução Definitiva"

A prática de usar branches curtas e integrar código rapidamente à main tem méritos, mas não é isenta de trade-offs:

• Vantagem: Entregas pequenas reduzem riscos em produção.
• Riscos:
  • Uso excessivo de feature flags torna o código complexo e propenso a bugs "adormecidos".
  • Funcionalidades fragmentadas podem não gerar valor até estarem completas.

O foco deve ser entregas menores com valor independente (ex.: uma funcionalidade útil por si só), não apenas quebrar tarefas grandes em pedaços artificiais. Feature flags são úteis para desacoplar deploy de release, mas seu custo de manutenção deve ser ponderado.

Conclusão

Mitos surgem de generalizações, mas a engenharia de software é feita de nuances. Linguagens, arquiteturas, bancos de dados e práticas de desenvolvimento têm contextos onde brilham e outros onde falham. A reflexão crítica e a adaptação às reais necessidades do projeto são sempre melhores guias que "verdades" absolutas.