O livro Clean Code foi um marco no desenvolvimento de software, mas, sinceramente, ele envelheceu mal. Robert C. Martin, com sua obsessão por regras, criou um manual que acaba tornando o código quase uma peça de museu: bonito de olhar, mas nem sempre prático de usar. A ideia de que seguir à risca todos os princípios propostos vai levar ao "código perfeito" é ilusória. Na prática, essa abordagem pode transformar um projeto em um festival de burocracia, onde até tarefas simples se tornam uma jornada pelo excesso de abstrações.
Além disso, a ênfase exagerada em detalhes como a escolha de nomes e a fragmentação do código pode ser um tiro no pé. Afinal, o código é para ser compreendido por pessoas, não para ganhar medalha de "limpeza". E convenhamos, um método com três linhas ou uma classe fragmentada em mil pedaços não garante código de qualidade — muitas vezes, faz justamente o contrário.
O mais irritante é como o livro parece ter parado no tempo. Hoje, trabalhamos com paradigmas que vão muito além da orientação a objetos e das metodologias ágeis da década passada. O mundo evoluiu, e o Clean Code (do livro) não acompanhou. É como se tentássemos usar ferramentas antigas em um mundo onde práticas como programação funcional, DevOps e microserviços são a norma.
Não sou contra a orientação a objetos; muito pelo contrário, é a base do meu trabalho diário. Gosto de SOLID. Mas não podemos fechar os olhos para outras formas de desenvolver, como a programação funcional, que oferece alternativas interessantes e soluções para problemas complexos. No fim, a melhor prática é aquela que se adapta ao contexto do projeto, sem se prender a dogmas "ultrapassados".
Resumindo, o Clean Code não é a bíblia do bom código que muitos pensam. É um conjunto de regras que precisa ser encarado com ceticismo. Se seguirmos cegamente essas recomendações, corremos o risco de cair em armadilhas de excesso de padronização e perda de foco no que realmente importa: entregar soluções eficientes e sustentáveis. Não estou dizendo para não usar nada ofertado no livro, muito pelo contrário! Use! Mas use com moderação. Use sabendo o contexto a ser empregado.
PS: A ideia desse artigo surgiu de uma thread que fizeram no BlueSky sobre livros. Encontrei diversos programadores postando o livro como referência e diversos criticando. Resolvi dar a minha visão a respeito e fiz isso em português (para não distorcerem a minha critica). Relutei muito em postar, pois isso é um assunto bem polêmico.
Top comments (3)
Poderia manda o link dessa thread sobre livros, fiquei curioso com quais foram as sugestões.
Segue: bsky.app/search?q=quatro+livros
Os livros da bolha dev estão ai no meio...
Concordo. Sempre usei as ideias do livro como um balizador e não um roteiro gravado a ferro e fogo.