Boas práticas de programação não existem: existem tradeoffs bem ou mal escolhidos

Um artigo publicado na comunidade DEV, de autoria de dchueri, levantou um ponto que eu defendo há tempos em conversas com outros devs: toda “boa prática” de programação nasceu de uma decisão de tradeoff que alguém tomou em um contexto específico — e que, ao ser generalizada como regra universal, perde justamente o que a tornava boa: o raciocínio por trás dela.

O contexto: por que viramos obcecados por “boas práticas”

Se você trabalha com desenvolvimento, já ouviu (ou repetiu) frases como “sempre use injeção de dependência”, “nunca deixe função com mais de 20 linhas”, “cobertura de testes tem que ser acima de 80%”. Esse tipo de recomendação vira dogma em times, em code review, em entrevista técnica. O problema é que a maioria dessas regras foi extraída de um caso de uso — geralmente sistemas grandes, times grandes, produtos de longa duração — e depois foi promovida a verdade absoluta, sem o contexto que a justificava.

O YouTube está cheio de vídeos ensinando “boas práticas” como se fossem uma lista de compras: siga esses dez itens e seu código será automaticamente melhor. E artigos técnicos, como os da DevMedia sobre testes, reforçam algo real e importante — testes automatizados evitam regressão e dão segurança para refatorar — mas raramente discutem o custo de implementar aquilo em um MVP que pode ser descartado em três meses.

Minha análise: regra sem contexto é dogma, não engenharia

Depois de anos migrando de Delphi para arquiteturas mais modernas e agora estudando IA aplicada ao desenvolvimento, cheguei a uma conclusão que uso como filtro pessoal: toda boa prática é a resposta correta para um problema específico, tomada por alguém que fez uma troca consciente. Quando você aplica essa mesma prática em outro contexto sem entender o tradeoff original, você não está seguindo uma boa prática — está copiando uma decisão alheia sem saber o preço que ela cobra.

Um exemplo direto: arquitetura em camadas com múltiplas abstrações é excelente quando você tem um time grande, múltiplos times consumindo a mesma base de código e um produto com vida útil de anos. Mas aplicar isso num sistema interno pequeno, mantido por duas pessoas, é pura sobrecarga cognitiva. Você paga o custo de indireção e complexidade sem nunca colher o benefício que justificava a prática. O mesmo vale para cobertura de testes: 100% de cobertura em um protótipo que será jogado fora é desperdício de tempo; a mesma cobertura em um sistema financeiro crítico é proteção indispensável.

O que me incomoda nesse discurso de “boas práticas” genéricas é que ele tira do desenvolvedor a responsabilidade de pensar. Vira mais fácil citar um princípio de livro do que justificar uma decisão baseada no problema real que você tem na mão. E isso é perigoso principalmente para quem está começando: o júnior aprende a regra, mas não aprende o motivo — e sem o motivo, ele não sabe quando quebrar a regra é a decisão certa.

Isso também se aplica diretamente ao uso de IA no desenvolvimento, tema que tenho acompanhado de perto. Ferramentas de geração de código tendem a sugerir padrões “canônicos” — camadas, testes, abstrações — porque foram treinadas em repositórios que seguem essas convenções. Isso não significa que a sugestão da IA está errada, mas significa que ela não conhece seu contexto de negócio, seu prazo, seu tamanho de time. Aceitar a sugestão sem questionar o tradeoff embutido é o mesmo erro de sempre, só que automatizado.

Meu ponto não é dizer que boas práticas não servem para nada — SOLID, testes automatizados, clean code, tudo isso tem valor real e eu mesmo aplico boa parte no meu dia a dia. O ponto é que a pergunta certa nunca é “estou seguindo a boa prática?”, e sim “esse tradeoff específico faz sentido para o problema que tenho agora?”. Um código mais acoplado, mais direto, sem camadas extras, pode ser a decisão tecnicamente mais correta para um projeto pequeno — mesmo que isso pareça “má prática” no manual.

Dica do Mestre: tradeoff é a ideia de que toda decisão técnica troca um ganho por uma perda — por exemplo, você ganha flexibilidade com mais abstrações, mas perde simplicidade e velocidade de entendimento do código. Não existe decisão sem custo; existe decisão cujo custo você aceitou conscientemente ou não.

Se você quer discutir esse tipo de decisão técnica com outros desenvolvedores que também estão questionando dogmas do mercado — e entender como aplicar isso na prática, inclusive usando IA como apoio nas decisões de arquitetura — venha para a Comunidade Dev’s AI. É lá que eu compartilho esse tipo de reflexão de forma mais aprofundada, com espaço para debate real.

Conclusão

Boa prática não é sinônimo de verdade absoluta — é sinônimo de decisão bem documentada sobre um tradeoff específico. O desenvolvedor sênior que eu tento ser todos os dias não é aquele que decora a lista de regras do mercado, mas aquele que entende o motivo por trás de cada uma delas e sabe, com segurança, quando é hora de segui-las e quando é hora de abrir mão delas em nome do problema real que está na sua frente.