Um artigo publicado na comunidade DEV, de autoria de dchueri, levantou um ponto que eu defendo h\u00e1 tempos em conversas com outros devs: toda “boa pr\u00e1tica” de programa\u00e7\u00e3o nasceu de uma decis\u00e3o de tradeoff que algu\u00e9m tomou em um contexto espec\u00edfico \u2014 e que, ao ser generalizada como regra universal, perde justamente o que a tornava boa: o racioc\u00ednio por tr\u00e1s dela.<\/p>\n
Se voc\u00ea trabalha com desenvolvimento, j\u00e1 ouviu (ou repetiu) frases como “sempre use inje\u00e7\u00e3o de depend\u00eancia”, “nunca deixe fun\u00e7\u00e3o com mais de 20 linhas”, “cobertura de testes tem que ser acima de 80%”. Esse tipo de recomenda\u00e7\u00e3o vira dogma em times, em code review, em entrevista t\u00e9cnica. O problema \u00e9 que a maioria dessas regras foi extra\u00edda de um caso de uso \u2014 geralmente sistemas grandes, times grandes, produtos de longa dura\u00e7\u00e3o \u2014 e depois foi promovida a verdade absoluta, sem o contexto que a justificava.<\/p>\n
O YouTube est\u00e1 cheio de v\u00eddeos ensinando “boas pr\u00e1ticas” como se fossem uma lista de compras: siga esses dez itens e seu c\u00f3digo ser\u00e1 automaticamente melhor. E artigos t\u00e9cnicos, como os da DevMedia sobre testes, refor\u00e7am algo real e importante \u2014 testes automatizados evitam regress\u00e3o e d\u00e3o seguran\u00e7a para refatorar \u2014 mas raramente discutem o custo de implementar aquilo em um MVP que pode ser descartado em tr\u00eas meses.<\/p>\n
Depois de anos migrando de Delphi para arquiteturas mais modernas e agora estudando IA aplicada ao desenvolvimento, cheguei a uma conclus\u00e3o que uso como filtro pessoal: toda boa pr\u00e1tica \u00e9 a resposta correta para um problema espec\u00edfico, tomada por algu\u00e9m que fez uma troca consciente. Quando voc\u00ea aplica essa mesma pr\u00e1tica em outro contexto sem entender o tradeoff original, voc\u00ea n\u00e3o est\u00e1 seguindo uma boa pr\u00e1tica \u2014 est\u00e1 copiando uma decis\u00e3o alheia sem saber o pre\u00e7o que ela cobra.<\/p>\n
Um exemplo direto: arquitetura em camadas com m\u00faltiplas abstra\u00e7\u00f5es \u00e9 excelente quando voc\u00ea tem um time grande, m\u00faltiplos times consumindo a mesma base de c\u00f3digo e um produto com vida \u00fatil de anos. Mas aplicar isso num sistema interno pequeno, mantido por duas pessoas, \u00e9 pura sobrecarga cognitiva. Voc\u00ea paga o custo de indire\u00e7\u00e3o e complexidade sem nunca colher o benef\u00edcio que justificava a pr\u00e1tica. O mesmo vale para cobertura de testes: 100% de cobertura em um prot\u00f3tipo que ser\u00e1 jogado fora \u00e9 desperd\u00edcio de tempo; a mesma cobertura em um sistema financeiro cr\u00edtico \u00e9 prote\u00e7\u00e3o indispens\u00e1vel.<\/p>\n
O que me incomoda nesse discurso de “boas pr\u00e1ticas” gen\u00e9ricas \u00e9 que ele tira do desenvolvedor a responsabilidade de pensar. Vira mais f\u00e1cil citar um princ\u00edpio de livro do que justificar uma decis\u00e3o baseada no problema real que voc\u00ea tem na m\u00e3o. E isso \u00e9 perigoso principalmente para quem est\u00e1 come\u00e7ando: o j\u00fanior aprende a regra, mas n\u00e3o aprende o motivo \u2014 e sem o motivo, ele n\u00e3o sabe quando quebrar a regra \u00e9 a decis\u00e3o certa.<\/p>\n
Isso tamb\u00e9m se aplica diretamente ao uso de IA no desenvolvimento, tema que tenho acompanhado de perto. Ferramentas de gera\u00e7\u00e3o de c\u00f3digo tendem a sugerir padr\u00f5es “can\u00f4nicos” \u2014 camadas, testes, abstra\u00e7\u00f5es \u2014 porque foram treinadas em reposit\u00f3rios que seguem essas conven\u00e7\u00f5es. Isso n\u00e3o significa que a sugest\u00e3o da IA est\u00e1 errada, mas significa que ela n\u00e3o conhece seu contexto de neg\u00f3cio, seu prazo, seu tamanho de time. Aceitar a sugest\u00e3o sem questionar o tradeoff embutido \u00e9 o mesmo erro de sempre, s\u00f3 que automatizado.<\/p>\n
Meu ponto n\u00e3o \u00e9 dizer que boas pr\u00e1ticas n\u00e3o servem para nada \u2014 SOLID, testes automatizados, clean code, tudo isso tem valor real e eu mesmo aplico boa parte no meu dia a dia. O ponto \u00e9 que a pergunta certa nunca \u00e9 “estou seguindo a boa pr\u00e1tica?”, e sim “esse tradeoff espec\u00edfico faz sentido para o problema que tenho agora?”. Um c\u00f3digo mais acoplado, mais direto, sem camadas extras, pode ser a decis\u00e3o tecnicamente mais correta para um projeto pequeno \u2014 mesmo que isso pare\u00e7a “m\u00e1 pr\u00e1tica” no manual.<\/p>\n
Dica do Mestre:<\/strong> tradeoff \u00e9 a ideia de que toda decis\u00e3o t\u00e9cnica troca um ganho por uma perda \u2014 por exemplo, voc\u00ea ganha flexibilidade com mais abstra\u00e7\u00f5es, mas perde simplicidade e velocidade de entendimento do c\u00f3digo. N\u00e3o existe decis\u00e3o sem custo; existe decis\u00e3o cujo custo voc\u00ea aceitou conscientemente ou n\u00e3o.<\/p><\/blockquote>\n