Seu código funciona. Mas ele está bem escrito?

Quando a gente está começando a programar, existe uma sensação muito boa quando finalmente roda o código e… funciona.

Não deu erro.

O resultado apareceu.

Missão cumprida, certo?

Bom… nem sempre.

Conforme fui estudando mais sobre Java, comecei a perceber uma coisa: fazer o código funcionar é só uma parte do trabalho.

Porque aquele código que hoje parece super óbvio pode virar um verdadeiro quebra-cabeça quando você precisar voltar nele daqui a alguns meses.

E foi aí que conceitos como Clean Code, refatoração e SOLID começaram a fazer muito mais sentido para mim.

Código funcionando não significa código bom

Imagina que você criou uma funcionalidade e colocou praticamente tudo dentro de um único método.

Ele:

• recebe os dados;
• valida;
• faz um cálculo;
• salva no banco;
• trata algum erro;
• e ainda decide o que devolver.

Pode funcionar perfeitamente.

O problema começa quando você precisa alterar alguma coisa.

Você mexe em uma parte e quebra outra.

Precisa testar tudo novamente.

E começa aquele medo clássico:

“Melhor não mexer muito porque está funcionando.”

Quando chegamos nesse ponto, talvez o problema não seja a funcionalidade. É a forma como o código foi organizado.

E onde entra a refatoração?

Uma coisa que eu não entendia muito bem era por que mexer em um código que já estava funcionando.

Hoje eu vejo a refatoração de outra forma.

Refatorar não significa mudar o que o sistema faz. Significa melhorar como o código faz aquilo.

Por exemplo, imagine algo assim:

public void processarPedido(Pedido pedido) {
  // valida o pedido
  // calcula o valor
  // aplica desconto
  // salva no banco
  // envia uma notificação
}

Talvez funcione.

Mas esse método está assumindo várias responsabilidades.

Uma refatoração poderia separar essas tarefas:

validarPedido(pedido);
calcularValor(pedido);
aplicarDesconto(pedido);
salvarPedido(pedido);
enviarNotificacao(pedido);

A funcionalidade continua praticamente a mesma.

Mas agora ficou muito mais fácil entender o que está acontecendo, alterar uma regra e até testar cada parte.

Clean Code não é deixar o código “bonito”

Essa foi outra coisa que comecei a entender melhor.

Clean Code não significa simplesmente organizar espaços, diminuir linhas ou escolher nomes bonitos.

A ideia é escrever um código que outra pessoa , ou você mesma daqui a alguns meses, consiga entender sem precisar investigar metade do projeto.

Algumas coisas simples já ajudam bastante.

1. Dê nomes que expliquem a intenção

Em vez de:

double v = 1500;

podemos ter:

double saldoDevedor = 1500;

Parece uma mudança pequena, mas quando existem dezenas de variáveis dentro de uma aplicação, faz muita diferença.

2. Evite métodos gigantes

Se você precisa rolar várias vezes a tela para descobrir o que um método faz, talvez seja um sinal de que existem responsabilidades demais ali.

Separar pequenas responsabilidades pode deixar o código muito mais fácil de entender e testar.

3. Não tenha medo de melhorar um código que já funciona

Esse talvez seja o ponto que mais mudou minha forma de pensar.

Antes, se estava funcionando, minha vontade era:

“Não encosta. haha”

Só que refatorar faz parte do desenvolvimento.

Claro que não significa sair modificando tudo sem necessidade. Mas quando encontramos duplicações, métodos enormes, responsabilidades misturadas ou nomes difíceis de entender, talvez exista uma oportunidade de melhorar.

E o SOLID nisso tudo?

Quando comecei a ver SOLID, parecia apenas mais um conjunto de siglas para decorar.

Mas a ideia por trás dele é bem mais interessante.

SOLID reúne cinco princípios que ajudam a criar códigos mais fáceis de manter e evoluir:

S — Single Responsibility Principle

Uma classe deveria ter uma responsabilidade principal.

O — Open/Closed Principle

O código deveria permitir extensões sem exigir alterações desnecessárias no que já funciona.

L — Liskov Substitution Principle

Uma implementação deveria poder substituir outra do mesmo contrato sem causar comportamentos inesperados.

I — Interface Segregation Principle

É melhor ter interfaces menores e específicas do que obrigar uma classe a implementar coisas que ela não precisa.

D — Dependency Inversion Principle

O código deve depender mais de abstrações do que de implementações concretas.

Só que tem um detalhe importante:

não adianta decorar S, O, L, I e D se você não consegue perceber o problema que cada princípio tenta evitar.

Por isso, para mim, começou a fazer mais sentido observar primeiro o código e perguntar:

Essa classe está fazendo coisa demais?

Se eu precisar alterar essa regra amanhã, vou mexer em quantos lugares?

Consigo testar essa parte separadamente?

Outra pessoa conseguiria entender esse código rapidamente?

Essas perguntas acabam tornando SOLID muito menos abstrato.

3 coisas que comecei a observar antes de considerar meu código “pronto”

Hoje tento fazer pelo menos estas três verificações:

1. Ler o código como se eu não tivesse escrito

Se eu precisar explicar demais o que uma variável ou método faz, talvez o próprio código possa deixar isso mais claro.

2. Procurar responsabilidades misturadas

Uma classe calcula, salva, envia e-mail, valida e ainda monta resposta?

Talvez seja hora de separar algumas coisas.

3. Pensar na próxima alteração

Se amanhã a regra mudar, será simples alterar?

Essa pergunta é ótima porque um código bem estruturado não serve apenas para funcionar hoje. Ele precisa conseguir evoluir amanhã.

No fim, código bom é código que conseguimos manter

Ainda estou aprendendo bastante sobre Clean Code, SOLID e refatoração, mas uma coisa já mudou na minha forma de programar:

não quero mais olhar apenas para o resultado do código. Quero olhar também para a forma como cheguei nele.

Fazer funcionar continua sendo importante.

Mas escrever algo que conseguimos entender, testar, alterar e evoluir também faz parte do trabalho.

Talvez essa seja uma das maiores mudanças quando começamos a sair do simples:

“Funcionou!”

para começar a perguntar:

“Funcionou… mas será que eu conseguiria melhorar?”

E você? Quando termina uma funcionalidade, costuma voltar no código para refatorar ou, se funcionou, prefere não mexer?

___

Indicação de livro

Se você quiser se aprofundar nesse assunto, uma ótima leitura é:

Clean Code: A Handbook of Agile Software Craftsmanship.  Robert C. Martin (Uncle Bob)

O livro aborda justamente vários dos pontos que falei aqui: nomes mais claros, funções, organização do código, responsabilidades e boas práticas para escrever um código mais fácil de entender e manter.

É uma leitura que combina muito com aquele momento em que a gente começa a perceber que fazer funcionar é importante, mas saber escrever um código que outras pessoas consigam entender também é.