Clean Code e SOLID sem dogma: o que aplicar de verdade
Código limpo não é estética. É a diferença entre mudar uma regra em uma tarde e passar duas semanas com medo de tocar em um arquivo. Os princípios que ficaram conhecidos por Robert C. Martin, e as práticas de refatoração descritas por Martin Fowler, existem para reduzir esse medo — não para produzir arquivos pequenos por obrigação.
Legibilidade é economia, não capricho
Código é lido muitas vezes mais do que é escrito. Nomes precisos, funções com uma responsabilidade clara e ausência de surpresa reduzem o tempo que qualquer pessoa leva para entender o que já existe — e esse tempo é o principal custo de manutenção.
O teste prático é simples: alguém que não escreveu aquele trecho consegue prever o que ele faz apenas pelo nome e pela assinatura? Se precisa ler a implementação inteira para ter certeza, há espaço para melhorar.
- Nomes que revelam intenção, não implementação.
- Funções curtas o suficiente para caber na cabeça, não em uma métrica arbitrária.
- Efeito colateral explícito, nunca escondido em um nome inofensivo.
SOLID explicado pela dor que evita
Responsabilidade única evita que uma mudança de relatório quebre o cálculo de imposto. Aberto/fechado evita cascata de alterações quando surge um novo tipo. Substituição de Liskov evita que uma implementação alternativa quebre quem usa a abstração. Segregação de interface evita obrigar quem implementa a preencher métodos que não fazem sentido. Inversão de dependência evita que a regra de negócio dependa de detalhe de banco ou de fornecedor.
Nenhum desses princípios pede camada extra por padrão. Todos pedem atenção ao ponto onde a mudança costuma doer.
Quando não aplicar
Abstração criada cedo demais custa caro: ela congela uma hipótese antes de existir evidência. Duplicar uma vez costuma ser mais barato do que abstrair errado. A terceira repetição, aí sim, é um bom sinal de que o padrão real apareceu.
Kent Beck resume bem a sequência prática: faça funcionar, faça certo, faça rápido. Inverter essa ordem é a origem de boa parte da complexidade desnecessária que encontramos em bases antigas.
Refatoração é rotina apoiada em teste
Refatorar significa mudar estrutura sem mudar comportamento — e isso só é verificável com teste. Sem rede de segurança, o que parece refatoração é reescrita com risco. Pequenas melhorias contínuas, feitas junto com cada entrega, evitam o projeto de reforma que nunca é aprovado.
Em resumo
Aplique princípio onde a mudança dói, não onde o checklist manda. Código limpo é o que permite alterar com confiança amanhã.
Casos de uso
Base legada sem testes
Testes de caracterização primeiro, para congelar o comportamento atual antes de qualquer mudança estrutural.
Regra de negócio espalhada
Consolidação em um módulo de domínio, com a interface dependendo dele e não o contrário.
Integração com fornecedor
Isolamento atrás de uma abstração fina, permitindo trocar o fornecedor sem tocar na regra.
Erros comuns
- Criar interface para tudo, sem nenhuma segunda implementação prevista.
- Dividir funções por contagem de linhas em vez de responsabilidade.
- Tratar SOLID como checklist de revisão em vez de critério de decisão.
- Adiar refatoração até virar projeto separado.
Boas práticas
- Deixe o código um pouco melhor do que encontrou, a cada alteração.
- Abstraia na terceira repetição, com evidência.
- Escreva teste antes de refatorar trecho crítico.
- Prefira composição a herança quando houver dúvida.
Livros recomendados
Clean Code — Robert C. Martin
Critérios objetivos de legibilidade e responsabilidade em nível de função.
Refactoring — Martin Fowler
Catálogo de transformações seguras apoiadas em testes.
A Philosophy of Software Design — John Ousterhout
Contraponto valioso sobre profundidade de módulos e custo da fragmentação excessiva.
Para aprofundar
Perguntas frequentes
- SOLID ainda faz sentido hoje?
- Sim, como critério de decisão sobre acoplamento e dependência. Como regra decorada aplicada a tudo, gera complexidade sem benefício.
- Qual o tamanho ideal de uma função?
- O suficiente para expressar uma responsabilidade clara. Contagem de linhas é indício, não critério.
- Quando refatorar?
- Continuamente, junto com a entrega, e sempre com teste cobrindo o comportamento que não pode mudar.
- Como convencer o time a investir em qualidade?
- Traduzindo em prazo: mostre o tempo perdido por retrabalho e por medo de mudar áreas críticas.
Referências
- Robert C. Martin — princípios de responsabilidade e dependência
- Martin Fowler — refatoração e cheiros de código
- John Ousterhout — complexidade e design de módulos
Conteúdo original da equipe i9 Conecty. Conceitos clássicos são explicados com palavras próprias e creditados aos seus autores.