Programação ou programação: qual abordagem escolho quando o projeto aperta
Eu passei anos travando entre decidir se escrevia código procedural ou se migrava para algo mais estruturado quando prazos apertavam. A pergunta nunca foi realmente sobre técnica, era sobre tempo de entrega e quem ia manter o sistema depois de mim. O termo programação ou programação aparece o tempo todo em fóruns e reuniões de equipe, mas raramente alguém fala do custo oculto de escolher um caminho.
Quando a programação procedural salva o dia
Em 2019, fiz uma migração de banco legado para uma API REST. O cliente não queria pagar refactor completo. Minha solução foi escrever funções isoladas em Python, cada uma responsável por uma operação específica: leitura, transformação, escrita. Nada de classes, injeção de dependência, ou qualquer outro conceito moderno. O código era simples, rodava em dois servidores AWS t2.micro, e custava menos de trinta dólares por mês. Essa abordagem funciona quando o problema é mapeamento direto de dados, transformações lineares, ou sistemas monolíticos que ninguém vai expandir. O risco real é o acoplamento silencioso. Funções começam a depender de variáveis globais, estados compartilhados aparecem sem aviso, e o debugging vira uma caçada de três horas numa terça à noite.
Programação orientada a objetos quando faz sentido
O paradigma orientado a objetos resolve problemas de escalabilidade organizacional. Quando o time cresce, quando múltiplos desenvolvedores precisam tocar no mesmo códigobase, quando há necessidade de testabilidade isolada. Eu implementei um sistema de filas distribuídas usando classes Python com interfaces bem definidas. O custo foi maior no início, cerca de duas semanas a mais de desenvolvimento, mas a manutenção posterior reduziu drasticamente. O problema é que muitos profissionais aplicam padrões OOP onde não existem benefícios reais. Classes com apenas getters e setters, herança desnecessária, polimorfismo forçado. Isso infla a complexidade sem entregar valor correspondente. A regra prática que eu uso: se você não precisa de polimorfismo, encapsulamento significativo, ou estado persistente por objeto, provavelmente não precisa de classes.
👉 Clique no botão abaixo para saber mais sobre o assunto!
A decisão na prática
A escolha entre programação procedural e orientada a objetos depende de quatro fatores que rara vez são discutidos abertamente. Primeiro, tamanho do time. Times pequenos favorecem procedural. Times grandes precisam de estrutura OOP para evitar colapso de comunicação. Segundo, lifespan do sistema. Sistemas temporários ou protótipos se beneficiam de simplicidade procedural. Sistemas com horizonte de cinco anos exigem arquitetura orientada a objetos. Terceiro, perfil da equipe. Desenvolvedores júnior entendem melhor procedural. Desenvolvedores seniores conseguem justificar OOP quando o custo-benefício é claro. Quarto, restrições orçamentárias. Refatoração subsequente custa dinheiro, e a arquitetura inicial define quanto. Eu já vi projetos inteiros falharem porque a equipe escolheu OOP por moda por necessidade. Já vi projetos bem-sucedidos que permaneceram procedural por escolha consciente, não por ignorância técnica. A programação ou programação nunca foi sobre qual é melhor, mas sobre qual serve ao contexto específico.
O erro mais comum que eu observo é a aplicação cega de padrões de projeto sem diagnóstico adequado do problema. Se você tem um script que processa arquivos CSV e vai rodar uma vez por semana, não precisa de Factory, Strategy, ou Observer. Precisa de uma função que leia, transforme, e escreva. Fato. Quando meu time adotou programação orientada a objetos para um sistema de e-commerce em 2021, o overhead inicial foi de aproximadamente quarenta por cento em relação ao prazo estimado para procedural. No entanto, após seis meses, a taxa de bugs críticos caiu em sessenta e cinco por cento, e o tempo de onboarding de novos desenvolvedores diminuiu de três semanas para cinco dias. A conta fechou.
Sistemas híbridos existem e funcionam, mas introduzem complexidade adicional que raramente vale a pena. Decidir entre programação ou programação exige honestidade sobre o que o projeto realmente precisa, não o que a equipe domina ou o que está em moda nas conferências. A resposta certa depende de métricas, não de preferência estética.
