"Código" Limpo, Desempenho Horrível (2023)

Artigo original ↗ Discussão no Hacker News ↗

Críticas ao design orientado a objetos no estilo “Clean Code” argumentam que a ênfase em métodos minúsculos, hierarquias polimórficas profundas e internals ocultos pode levar a mau desempenho ao contrariar caches de CPU e adicionar indireção. Os comentaristas contrapõem que esses padrões foram pensados para melhorar a legibilidade e a manutenibilidade, e que os gargalos reais muitas vezes estão em outro lugar (por exemplo, I/O de rede, frameworks pesados) em vez do despacho virtual. O tema mais amplo é que “princípios” de programação como DRY, funções pequenas e interfaces são úteis apenas quando aplicados com julgamento a domínios e restrições específicas, e não seguidos como dogma.

Valor e limitações do Clean Code

  • Muitos veem o livro como um andaime útil para desenvolvedores em início de carreira que precisam de estrutura.
  • Outros argumentam que ele ensina práticas ruins ou estreitas (“código OO limpo” apenas) e é ativamente prejudicial, até para iniciantes.
  • Reclamação comum: ele incentiva regras dogmáticas (funções minúsculas, polimorfismo, evitar comentários) e uma postura moralista que rotula a discordância como “não profissional”.
  • Alguns mencionam uma edição mais nova, destinada a corrigir interpretações equivocadas, mas sua qualidade é descrita como incerta.

Desempenho vs. manutenibilidade

  • Debate central: abstrações “limpas” (especialmente OO e polimorfismo) frequentemente prejudicam o desempenho, mas podem facilitar a manutenção e a extensibilidade.
  • Vários defendem que o desempenho deve ser guiado por medições: escreva código simples e depois otimize os pontos críticos.
  • Outros contrapõem que certos estilos (polimorfismo dinâmico pesado, camadas profundas de abstração) podem tornar um sistema globalmente lento, e não apenas nos pontos críticos.

OO, polimorfismo e alternativas

  • Muitos observam que o exemplo clássico usa polimorfismo em tempo de execução e vtables, que são conhecidos por ser mais lentos do que dados planos e switch, especialmente em loops apertados.
  • Alguns destacam que compiladores modernos fazem inline de funções pequenas muito bem; a principal custo é o despacho dinâmico, não o “clean code” em si.
  • Alternativas mencionadas: tipos soma com match exaustivo, despacho procedural (switches ou tabelas), polimorfismo estático e abstrações de custo zero em linguagens mais novas.

Tamanho e estrutura de funções

  • Forte desacordo sobre regras de comprimento de funções.
  • Alguns preferem funções muito pequenas, de propósito único, por clareza; outros consideram esse estilo fragmentado e mais difícil de acompanhar.
  • Funções longas, mas lineares, podem ser aceitáveis se fizerem “uma coisa coerente”; a divisão artificial pode prejudicar a legibilidade.

Princípios vs. dogma

  • Vários comentaristas enfatizam que princípios como DRY, SRP e “clean code” são ferramentas de baixo nível com trade-offs, não leis universais.
  • A aplicação excessiva leva a acoplamento morto, fragmentação, baixa coesão e problemas de desempenho.
  • Tema consensual: use julgamento; o contexto (complexidade do domínio, necessidades de desempenho, tamanho da equipe, extensibilidade) deve orientar o design.

Críticas ao artigo e aos exemplos

  • Alguns acham que a crítica ataca um exemplo de brinquedo, sem foco em desempenho, e portanto equivale a um espantalho.
  • Outros respondem que o exemplo veio do próprio livro e demonstra concretamente como o estilo promovido pode degradar o desempenho, o que é um ponto válido mesmo que a intenção original fosse pedagógica.

Queixas mais amplas do ecossistema

  • Vários comentários sugerem que, em apps do dia a dia, os piores problemas de desempenho vêm menos de padrões OO e mais de stacks pesadas (por exemplo, Electron, “web tech” no desktop) e de latência de rede, não apenas do tamanho de funções ou do polimorfismo.