Clean Code — o livro que todo dev precisa ler com ceticismo
Clean Code foi o primeiro livro técnico que li com seriedade. Aprendi muito. E aprendi ainda mais quando comecei a questionar o que ele pregava como lei absoluta.
Clean Code foi o primeiro livro técnico que eu li do início ao fim com atenção real.
Até então, eu lia documentação, tutoriais, Stack Overflow. Livros técnicos de verdade — com exemplos extensos, com argumentos construídos ao longo de capítulos — eu nunca tinha terminado nenhum. Clean Code foi diferente.
O que aprendi foi valioso. O que aprendi depois — questionando o que o livro apresenta como verdade universal — foi ainda mais valioso.
O que Clean Code acerta:
Nomes importam mais do que a maioria dos devs no início de carreira imagina. d não é um nome de variável. daysSinceModification é. Quem vai ler esse código depois de você — incluindo você mesmo em seis meses — vai agradecer pelo nome explicativo. O tempo gasto escolhendo um bom nome é recuperado várias vezes em tempo de leitura.
Funções pequenas com um único propósito são mais fáceis de testar, de entender, de reusar. Uma função que faz três coisas é mais difícil de nomear (você vai acabar com and no nome), mais difícil de testar (você precisa configurar contexto para três comportamentos), e mais difícil de mudar (mudança em um comportamento pode afetar os outros).
Comentários que explicam o quê são frequentemente desnecessários se o código for bem escrito. Comentários que explicam o porquê — a razão de uma decisão não óbvia, um workaround para um bug específico de uma dependência — são valiosos.
O que Clean Code exagera:
A regra de que funções devem ter "no máximo vinte linhas" e idealmente "entre quatro e seis" é prescritiva demais. Existem algoritmos que são mais claros como uma unidade coesa de quarenta linhas do que como oito funções de cinco linhas cada, com nomes que precisam ser lidos em sequência para entender o que acontece.
A aversão a comentários vai longe demais em alguns capítulos. Existem contextos — algoritmos complexos, workarounds para comportamentos não óbvios de sistemas externos, decisões de design com trade-offs não aparentes no código — onde um comentário bom é a melhor documentação possível.
Os exemplos de refatoração mostram código antes/depois onde o "depois" é apresentado como objetivamente melhor. Mas alguns dos "depoi" são mais complexos de seguir do que os "antes". A abstração adicional não é sempre um ganho.
O problema maior com Clean Code não é o conteúdo — é como ele é frequentemente ensinado e adotado.
Como conjunto de heurísticas para pensar sobre qualidade de código, ele é útil. Como conjunto de regras a aplicar mecanicamente em qualquer contexto, ele produz código que obedece as regras mas não necessariamente resolve o problema melhor.
Vi devs rejeitarem contribuições em code review citando Clean Code como autoridade — "funções com mais de vinte linhas são bad practice, o livro diz" — sem considerar se a função em questão era mais clara do jeito que estava do que seria depois de fragmentada em cinco funções menores.
Nenhum livro técnico deve ser seguido como lei. Cada princípio tem contexto onde se aplica e contexto onde não se aplica. A habilidade de engenheiro não é saber aplicar os princípios — é saber quando aplicá-los.
A lista de livros que recomendo ler depois de Clean Code, justamente para questionar e expandir o que ele ensina: Designing Data-Intensive Applications (DDIA) para entender sistemas distribuídos e os trade-offs reais que eles impõem. The Pragmatic Programmer para uma visão mais equilibrada e menos prescritiva de boas práticas. A Philosophy of Software Design, de John Ousterhout, que defende abertamente uma posição diferente da de Clean Code em alguns pontos-chave.
Essa semana: se você ainda não leu Clean Code, leia — é um ponto de partida valioso. Se já leu, escolha um princípio que você aplica automaticamente e questione: "em qual contexto esse princípio piora o código em vez de melhorá-lo?"