Uma história (quase) macabra sobre Overengineering
Acabei de assistir a aula do curso.dev:
“Uma história macabra sobre Overengineering” — do Filipe Deschamps.
E cara…
Eu me vi sentado do lado dele na história. 😅
A fase do “agora eu sou sênior”
Quando comecei a atingir um nível maior de senioridade, aconteceu algo curioso:
Eu queria colocar tudo que eu estava aprendendo dentro dos meus sistemas.
- Arquitetura hexagonal?
- Clean Architecture?
- Event-driven?
- CQRS?
- DDD?
- Filas?
- Microsserviços?
- 12 camadas de abstração?
- 48 interfaces “porque sim”?
Sim.
Resultado?
Nasciam verdadeiros Megazords arquiteturais. 🤖
Projetos pequenos viravam sistemas com:
- Complexidade acidental
- Dependências desnecessárias
- Boilerplate infinito
- Performance questionável
- E uma manutenção cada vez mais dolorosa
Tudo isso… para resolver problemas simples.
A virada de chave
Hoje eu penso diferente.
Minha principal linguagem é Go, e isso me ensinou uma coisa importante:
A stdlib resolve mais do que você imagina.
Eu passei a:
- Criar meus próprios boilerplates
- Reutilizar estruturas testadas
- Usar poucas libs
- Confiar mais na simplicidade
- Só adicionar complexidade quando ela é realmente necessária
Em projetos JS, por exemplo, hoje eu uso basicamente:
- Fastify
- Drizzle ORM
Simples. Direto. Rápido.
Se vai virar um Megazord?
Só se realmente precisar.
(E quase nunca precisa.)
Overengineering é insegurança disfarçada de excelência
Com o tempo eu percebi uma coisa desconfortável:
Muitas vezes, overengineering não é sobre técnica.
É sobre:
- Querer mostrar que sabe
- Aplicar padrões porque estudou ontem
- Fazer “bonito” para outros devs
- Medo de parecer simples demais
Só que no mundo real, o que importa é:
- Entregar valor
- Performance
- Manutenibilidade
- Clareza
- Velocidade de iteração
Código simples escala melhor do que ego técnico.
E a parte interessante…
Talvez essa seja uma das grandes diferenças entre:
- Um dev experiente
- Um iniciante
- Ou até mesmo uma IA
Quem está começando tende a complicar para provar capacidade.
Uma IA tende a gerar a solução “mais estruturada possível”.
Mas quem já apanhou o suficiente aprende que:
O melhor código é o que resolve o problema com o menor custo cognitivo possível.
Nem toda abstração é maturidade.
Às vezes é só barulho.
Hoje, se algo vai virar complexo, é porque o problema exigiu.
Não porque eu quis provar alguma coisa.
E vocês?
Já passaram pela fase do Megazord arquitetural? 😅