Discutir o que é um código bom ou ruim pode ser subjetivo, variando de pessoa para pessoa. O que você considera um código bom hoje pode não parecer tão bom daqui a cinco anos. Essa visão muda conforme ganhamos maturidade e experiência. Por isso, não existe uma definição gravada em pedra sobre o que é bom ou ruim. Ainda assim, é mais fácil identificar sinais de um código ruim do que determinar o que é um código bom.
Um dos livros mais famosos sobre o assunto é Clean Code de Robert C. Martin, o Uncle Bob. Ele apresenta ideias importantes para identificar e evitar códigos ruins. Ao longo do tempo, fui formulando minhas próprias dicas com base em experiências práticas, e concordo com muitas das ideias do livro. Mas, acima de tudo, é fundamental reconhecer que escrever um bom código é uma jornada de aprendizado.
Código funcional NÃO significa Código Bom
Um mito comum que quero desmistificar é o que ouço muito por aí:
“Código bom é aquele que funciona”
Na minha visão, isso não é verdade. Um código funcional pode atender às regras de negócio e realizar sua função, mas pode ser pouco performático, difícil de entender ou de manter. Mesmo que funcione, isso não significa que ele não possa ser melhorado. Usar esse argumento como justificativa para um código ruim é apenas uma desculpa.
Outro ponto recorrente é a ideia de que “não temos tempo para fazer direito agora”. Essa é outra muleta comum. Em muitos casos, o tempo necessário para escrever um código desacoplado e bem estruturado é praticamente o mesmo que seria gasto para fazer algo mal feito. O esforço investido inicialmente compensa no longo prazo, reduzindo o tempo gasto com manutenção e retrabalho.
Obviamente, aqui estou focando no aspecto da qualidade de código, mas existem cenários onde precisamos entregar com maior velocidade, comprometendo a qualidade, desde que de forma consciente. Isso é muito comum em startups no início da vida, tendo que validar seus produtos, colher feedbacks, etc… e nada de errado com isso. Inclusive, nesse vídeo, eu falo um pouco mais sobre isso: https://www.youtube.com/watch?v=fR0SKWXBraA
A importância de Código Legível e Autoexplicativo
Um bom código deve ser legível e fácil de entender. Se você tem que gastar muito tempo tentando descobrir o que um trecho de código faz, ele não é bom o suficiente. Um exemplo claro é refatorar métodos e variáveis com nomes que reflitam exatamente o que eles fazem. Comentários devem ser usados apenas quando realmente necessários, como em regras de negócio complexas. Idealmente, o código deve ser tão autoexplicativo que dispense comentários em situações simples.
Exemplo simples da diferença de legibilidade
Um exemplo simples ilustra a importância de escrever código expressivo. Considere um trecho de código que calcula o fatorial de um número, mas que usa variáveis e métodos sem nomes descritivos. O que ele faz não é óbvio à primeira vista. Refatorar esse código, utilizando nomes claros para métodos e variáveis, faz toda a diferença. Em vez de comentar que o código calcula o fatorial, é muito mais eficaz ajustar os nomes para que o próprio código se explique.
Considere este exemplo inicial:
public class Class1
{
public int Metodo1(int a)
{
int resultado = 1;
for (int i = 1; i <= a; i++)
{
resultado *= i;
}
return resultado;
}
}
O que esse código faz? Sem contexto ou comentários, é difícil saber. Agora, veja o mesmo código refatorado:
public class OperacoesMatematicas
{
public int CalcularFatorial(int numero)
{
if (numero <= 1)
return 1;
return numero * CalcularFatorial(numero - 1);
}
}
Com nomes mais descritivos, fica evidente que o código calcula o fatorial de um número. Essa simples mudança melhora drasticamente a legibilidade e reduz a necessidade de comentários.
O código acima ainda pode ser melhorado em termos de eficiência ao eliminar a recursão. No entanto, o objetivo é demonstrar a legibilidade do código. Refatorando-o um pouco mais, ele poderia ficar assim:
public class OperacoesMatematicas
{
public int CalcularFatorial(int numero)
{
int resultado = 1;
for (int i = 2; i <= numero; i++)
resultado *= i;
return resultado;
}
}
Por que escrever Código de Qualidade?
Escrever código de qualidade traz inúmeros benefícios, tanto profissionais quanto técnicos:
- Evolução profissional: Um código de qualidade aumenta suas chances de ser reconhecido em boas empresas ou destacar-se em projetos.
- Facilidade de manutenção e evolução: Um código bem escrito reduz o esforço necessário para corrigir bugs ou implementar novas funcionalidades.
- Trabalho em equipe: Você escreve não apenas para você, mas para outros desenvolvedores. Um código limpo facilita o trabalho colaborativo.
- Segurança e confiabilidade: Códigos claros e testáveis aumentam a confiança na aplicação, garantindo maior estabilidade.
- Escalabilidade: Um código bem planejado e desacoplado é mais fácil de escalar e adaptar a novos requisitos.
Uma analogia útil é comparar um código ruim a uma instalação elétrica mal planejada: Se precisar de manutenção ou expansão, os problemas estruturais vão consumir muito mais tempo e esforço.
Sinais de um Código Ruim
Agora, vamos falar sobre os sinais que indicam que um código pode estar se tornando ruim. Esses sinais são como feedback que o código nos dá para entendermos onde devemos melhorar:
- Dificuldade de compreensão: Revisitar o código após algum tempo e ter dificuldades para entender o que foi feito é um sinal claro. Isso também acontece quando outra pessoa acessa o código e precisa de ajuda para decifrá-lo. Muitas vezes, essa dificuldade é resultado de uma escrita complexa demais ou da falta de comentários onde eles seriam necessários.
- Adaptações e “Gambiarras”: Quando você precisa criar soluções alternativas para contornar decisões ruins no código original. Por exemplo, uma função escrita de forma que impede o uso de abstrações pode limitar sua capacidade de implementar melhorias ou novas funcionalidades.
- Baixo desempenho: Rotinas que deveriam ser simples tornam-se custosas em termos de performance. Se operações comuns, como buscas ou cálculos, consomem muitos recursos, é um sinal de que o código precisa ser otimizado.
- Código duplicado: A duplicação de código em diferentes partes do sistema é um problema recorrente. Quando você percebe que está repetindo a mesma lógica em vários lugares, é hora de unificar esse comportamento em uma única implementação reutilizável. Existem casos onde as duplicações são intencionais e tem um motivo, trato isso nesse vídeo: https://www.youtube.com/watch?v=pl5FEmSHKmQ.
- Manutenção demorada: Se cada pequena alteração no código exige uma análise extensa e consome muito tempo, isso indica que o código não está tão bem estruturado. Esse tipo de dificuldade torna a manutenção desgastante e ineficiente.
- Novas implementações complexas: Assim como na manutenção, implementar novas funcionalidades deve ser relativamente simples. Se expandir o sistema exige muito esforço, é provável que o código esteja mal planejado.
- Sensação de “preguiça”: A “preguiça” de mexer em um trecho de código específico pode ser um indicativo de que ele está confuso ou mal escrito. O sentimento de aversão ao código geralmente aponta que ele merece uma refatoração ou reestruturação.
Conclusão: A certeza da manutenção
Se há uma certeza no desenvolvimento de software, é a manutenção. Todo código será revisitado, ajustado e expandido. Por isso, após suas eventuais PoCs ou MVPs, investir em qualidade do projeto “oficial” desde o início é indispensável. Um sistema com código ruim acaba gerando um ciclo de retrabalho e problemas que consomem mais tempo do que se fosse feito corretamente desde o começo. Escrever código de qualidade é, acima de tudo, um compromisso com o futuro do software e com todos que trabalharão nele.
E sem qualidade…
