Clean Code costuma ser vendido como uma questão de estética: nomes bonitos, funções curtas, código "elegante". Depois de mais de 400 projetos entregues, discordo dessa moldura. Clean Code não é sobre parecer bonito — é sobre quanto vai custar para alguém (inclusive eu, seis meses depois) entender e mudar aquele código sem quebrar nada.
O teste que uso
Antes de considerar um trecho "limpo", eu me pergunto: se eu voltar aqui daqui a um ano, sem lembrar de nada, quanto tempo levo para entender o que essa função faz e por quê? Nome de variável, tamanho de função, ausência de efeitos colaterais escondidos — tudo isso existe para reduzir essa resposta a minutos, não horas.
Isso vira prático em coisas simples: uma função que se chama processar() não me diz nada sobre o que ela processa nem por quê. Uma função chamada calcularRankingSemanalDoAluno() já responde metade das perguntas antes mesmo de eu ler o corpo dela. O tempo que gasto escolhendo um nome melhor é sempre menor do que o tempo que economizo não precisando reler o código inteiro depois.
Onde isso paga mais
Em projetos mantidos por uma pessoa só, como o Simulado Solidário, isso importa ainda mais: não existe um segundo desenvolvedor para "saber onde mexer". Clean Code, nesse contexto, não é luxo — é o que permite que uma única pessoa continue entregando funcionalidades novas ano após ano sem que o código vire um risco.
Clean Code não substitui arquitetura
Um erro comum é achar que só nomear bem e escrever funções curtas resolve tudo. Clean Code cuida da legibilidade local; arquitetura cuida da organização global. Uso os dois juntos — o que fazer dentro de cada camada eu decido com Clean Code, onde cada camada mora eu decido com Arquitetura Hexagonal e princípios de SOLID.
