Código Limpo foi um dos livros que mais mexeu com a forma como eu escrevo e reviso software. Depois da leitura, comecei a prestar mais atenção em intenção, nomes, tamanho de função, duplicação, testes, acoplamento e principalmente no custo que um código confuso cria para quem precisa manter o sistema depois.
Ao mesmo tempo, a leitura também me ajudou a perceber uma coisa importante: bons princípios não devem virar religião. Em projeto real existem prazo, legado, regra de negócio mal documentada, sistema em produção, equipe com ritmos diferentes e decisões que precisam ser tomadas com o contexto disponível.
O que eu realmente levei para o dia a dia
O principal aprendizado foi escrever código pensando em manutenção. Não é sobre deixar tudo bonito por vaidade. É sobre reduzir ruído para a próxima pessoa entender a regra, corrigir um problema ou evoluir uma tela sem medo de quebrar outra parte do sistema.
- Nomes melhores: variável, função e componente devem explicar intenção antes de explicar implementação.
- Funções menores: quando uma função faz coisa demais, o erro costuma ficar escondido no meio do fluxo.
- Refatoração contínua: melhorar aos poucos costuma ser mais viável do que esperar uma reescrita perfeita.
- Testes como proteção: teste não é só cobertura; é confiança para alterar código que já atende alguém.
Um exemplo simples de intenção
Um dos pontos que mais levei para a prática foi evitar código que exige adivinhação. Quando uma função chama `processarDados`, ela pode estar fazendo qualquer coisa. Quando chama `calcularTotalDaVenda` ou `validarCaixaAberto`, a intenção aparece antes mesmo de abrir a implementação. Esse cuidado parece pequeno, mas faz diferença em telas com regra de negócio, como produtos, vendas, reservas ou financeiro.
processar() → validarEstoqueDisponivel()
salvar() → registrarVendaComBaixaDeEstoque()
Onde eu aprimorei alguns pontos
Depois de aplicar esses conceitos em sistemas reais, comecei a olhar menos para regra isolada e mais para equilíbrio. Nem toda função longa é automaticamente ruim. Nem toda abstração deixa o sistema melhor. Às vezes, uma duplicação pequena e explícita é mais fácil de manter do que uma abstração genérica criada cedo demais.
Em frontend, por exemplo, componentizar é essencial, mas componentizar antes de entender as variações reais pode criar componentes difíceis de usar. Em backend, separar camadas ajuda muito, mas excesso de indireção pode esconder a regra de negócio. O ganho está em organizar sem perder clareza.
Hoje eu penso mais em legibilidade do fluxo do que em aplicar uma regra isolada. Um arquivo pode ter mais linhas e ainda ser fácil de manter se a ordem das decisões estiver clara. O contrário também é verdadeiro: código muito fragmentado pode parecer limpo na superfície, mas obrigar o desenvolvedor a pular por muitos arquivos para entender uma regra simples.
Onde eu discordo na prática
Minha principal discordância não é com a intenção do livro, mas com a aplicação rígida de algumas ideias. No dia a dia, nem sempre a melhor decisão é a mais elegante tecnicamente. Às vezes, o melhor passo é estabilizar uma regra, criar teste, isolar um trecho legado e só então refatorar com mais segurança.
Também não acredito que exista um formato único de código limpo. Um sistema de PDV, uma plataforma de reservas, uma automação em Python e uma API corporativa têm pressões diferentes. O mesmo princípio precisa ser aplicado de formas diferentes.
Também passei a tomar mais cuidado com abstrações criadas cedo demais. A intenção de evitar duplicação é boa, mas abstração sem necessidade real pode prender o sistema em uma estrutura difícil de mudar. Às vezes, repetir um trecho pequeno por um tempo ajuda a entender melhor o padrão antes de criar uma solução comum.
O que ficou como prática pessoal
Hoje eu tento escrever código com uma pergunta simples em mente: se eu voltar nesse arquivo daqui a três meses, vou entender a decisão sem precisar reconstruir tudo mentalmente? Quando a resposta é não, é sinal de que o código precisa de nome melhor, divisão melhor, teste, comentário pontual ou uma regra mais explícita.
Isso também mudou minha forma de revisar código. Eu procuro entender se a pessoa que vai manter aquele trecho terá pistas suficientes: nomes, validações, mensagens de erro, testes e uma separação razoável entre interface, regra e acesso a dados. Quando essas pistas existem, o código envelhece melhor.
clareza primeiro → abstração quando ajuda → teste para mudar com confiança → refatoração incremental
Conclusão
Código Limpo valeu muito para minha evolução, principalmente por mudar meu senso de responsabilidade com manutenção. Mas a maturidade vem quando a gente para de aplicar regra no automático e começa a decidir com base no impacto real da mudança.