Adeus, código limpo (2020)
Esforços para aplicar rigorosamente princípios de “código limpo”, como DRY e abstração agressiva, podem sair pela culatra, argumentam muitos engenheiros, quando reduzem a flexibilidade e tornam mudanças futuras mais difíceis, em vez de mais fáceis. Os comentaristas contrastam código duplicado, porém direto e específico do domínio, com versões abstratas que enredam casos não relacionados, aumentam a carga cognitiva e frequentemente refletem tentativas prematuras de generalizar a partir de poucos exemplos. Um tema recorrente é que a manutenibilidade depende tanto de bom julgamento, comunicação e trade-offs conscientes do contexto quanto de quaisquer regras de estilo ou dogmas de design específicos.
Código Limpo, DRY e Abstração
- Muitos argumentam que a refatoração falhou porque criou uma má abstração, e não porque “código limpo” seja inerentemente ruim.
- DRY é visto como uma diretriz: é valioso quando vários pontos devem sempre mudar juntos; prejudicial quando força casos não relacionados a seguir um único caminho.
- Vários comentários enfatizam “abstrair de baixo para cima, não de cima para baixo”: primeiro deixe os casos de uso concretos se acumularem e, então, extraia helpers simples e óbvios.
- Uma heurística recorrente: duplicação de conhecimento ou comportamento merece abstração; semelhança superficial na forma do código, muitas vezes não.
Quando a Duplicação é Preferível
- Vários participantes dizem que “a duplicação é mais barata do que a abstração errada”. Abstrações erradas se tornam frágeis, acrescentam condicionais e casos especiais, e são difíceis de desfazer.
- Para domínios em evolução (gráficos, produtos financeiros, lógica de negócio complexa), manter caminhos de código separados, ainda que parecidos, muitas vezes preserva a flexibilidade para divergências futuras.
- Alguns observam que editar a mesma lógica em alguns lugares raramente é o verdadeiro fator de custo; depurar uma abstração enredada, sim.
Avaliando o Cânone de “Código Limpo”
- Alguns criticam o estilo de “Código Limpo” por ser dogmático, pouco cauteloso e atraente para juniores que aplicam regras mecanicamente (por exemplo, “muitas funções pequenas”, DRY a qualquer custo).
- Outros observam que os textos originais tratam as recomendações como controversas e não autoritárias, e insistem que o uso indevido é erro do leitor, não do livro.
- Há preocupação de que linters e equipes tenham transformado diretrizes flexíveis em doutrina rígida.
Dinâmica de Equipe e Processo
- Muitos veem o erro central como social/processual: reescrever à noite o trabalho recém-feito de um colega e commitar sem discussão ou revisão.
- As opiniões se dividem entre “o código pertence à equipe; qualquer um pode refatorar” e “contexto e etiqueta importam; reescritas unilaterais prejudicam a confiança”.
- Alternativas sugeridas: comentários em revisão, extração incremental de helpers, PRs separados com o autor original incluído no loop.
Perspectivas de Linguagem e Paradigma
- Alguns elogiam linguagens funcionais (por exemplo, com leis de Applicative/Monad) por abstrações padronizadas e reutilizáveis, reduzindo abstrações específicas de projeto.
- Outros destacam o trade-off oposto do Go: menos abstrações no nível da linguagem, mais duplicação, mas um modelo mental mais simples.
- Há debate sobre hierarquias orientadas a objetos para geometria (por exemplo, quadrados vs retângulos) e como a mutabilidade quebra abstrações ingênuas.
Testes, Manutenibilidade e Pragmatismo
- Um grupo argumenta que testes pesados teriam permitido “refatoração sem medo” e tornado a mudança incontestável.
- Outros respondem que testes não resolvem a complexidade cognitiva nem os problemas sociais; código esteticamente ou estruturalmente ruim pode ser totalmente testado e ainda assim ser prejudicial.
- Há amplo consenso: manutenibilidade, clareza da lógica de negócio e facilidade de mudança superam estética ou redução da contagem de linhas.