Tudo bem se o seu código for apenas bom o suficiente
Equilibrar código “bom o suficiente” com qualidade de longo prazo é uma tensão recorrente na engenharia de software. Os comentaristas ponderam o valor de entregar rapidamente código bagunçado, mas funcional — especialmente em startups ou protótipos — contra os custos de manutenção, bugs e lentidão no desenvolvimento de funcionalidades que surgem quando legibilidade, testes e design claro são negligenciados. Muitos argumentam que a qualidade aceitável depende fortemente do contexto (de sistemas de vida crítica a aplicativos CRUD), mas que as equipes devem concordar explicitamente sobre padrões de qualidade e evitar tanto o perfeccionismo quanto práticas por modismo que adicionam complexidade sem benefício real.
Tempo de vida do código e realidades do legado
- As experiências variam muito: algum código morre em poucos anos, enquanto código dos anos 1990 ainda roda sem mudanças.
- Vários observam um paradoxo: “gambiarras rápidas” muitas vezes sobrevivem mais tempo, enquanto “obras-primas” cuidadosamente elaboradas são substituídas.
- Alguns argumentam que código que não é tocado está “morto”; outros dizem que código intocado e funcionando é sucesso, não fracasso.
O que “bom o suficiente” significa depende do contexto
- Muitos concordam: fora de sistemas críticos de segurança, o “bom o suficiente” que entrega e resolve problemas de usuários geralmente é o caminho certo.
- Outros contestam: “bom o suficiente” pode ser usado indevidamente para justificar spaghetti, bugs e engenharia ruim.
- Os contextos diferem:
- Startup sem usuários: velocidade e aprendizado superam estrutura, testes e abstrações.
- Sistemas de missão crítica: confiabilidade e QA dominam, mesmo com enorme custo de produtividade.
- Aplicativos empresariais típicos: buscar equilíbrio, idealmente decidido explicitamente pela equipe.
Qualidade do código vs qualidade do produto
- Usuários não veem o estilo do código, mas veem bugs, lentidão e recursos ausentes.
- Um lado: internals ruins inevitavelmente desaceleram o trabalho em funcionalidades e aumentam bugs, então qualidade é uma necessidade econômica.
- Outro lado: overengineering, código “limpo” com muitas abstrações e regras dogmáticas (DRY, padrões) podem prejudicar mais a usabilidade e a entrega do que ajudar.
Manutenibilidade, colaboradores e processo
- Há múltiplos relatos de bases de código bagunçadas causando lentidão no desenvolvimento de funcionalidades, apagando incêndios e frustração para mantenedores futuros.
- Práticas leves — testes, estrutura clara, designs simples — são vistas como muitas vezes não mais caras do que trabalho descuidado, quando você já tem habilidade.
- Normas de PR e CI são destacadas: código que nem sequer roda é amplamente visto como inaceitável para revisão.
Abstração, DRY vs WET e legibilidade
- Sobre-abstração e DRY extremo são reclamações comuns; eles escondem comportamento, aumentam a carga cognitiva e tornam a depuração mais difícil.
- Outros ficam “aterrorizados com código WET” porque lógica de negócio duplicada é fácil de atualizar de forma inconsistente.
- Um compromisso emergente: abstraia apenas quando as coisas realmente precisarem mudar juntas; priorize a localidade do comportamento e a facilidade de rastrear a partir do código do cliente.
Perfeccionismo, aprendizado e profissionalismo
- Alguns gostam de buscar quase a perfeição como ofício ou vantagem competitiva.
- Outros alertam que “apenas bom o suficiente” como mentalidade estagna o crescimento de habilidade e rebaixa os padrões do setor.
- Há amplo consenso: seja pragmático, discuta metas de qualidade antecipadamente e alinhe o esforço com risco, domínio e tempo de vida.