Criado por Kent Beck, engenheiro de software americano e criador do Extreme Programming e Test Driven Development, o “Code smell” é um termo para dizer que algo no código “não está cheirando bem”.
Um code smell costuma ser uma evidência de que há um problema no código-fonte de uma aplicação. Porém, ele não é necessariamente um bug no sistema, e sim um indicativo de que as boas práticas de design não foram aplicadas neste sistema. Isso pode impactar negativamente todo o desenvolvimento e dificultar qualquer alteração futura que precise ser feita.
O termo foi cunhado em 1990, mas ganhou popularidade em 1999, no livro de Martin Fowler: “Refatoração: aperfeiçoando o design de códigos existentes”, no qual o autor utiliza o code smell como uma forma padronizada de detectar e aplicar refatorações no código.
Apesar de nada superar uma intuição bem treinada para saber quando realizar uma refatoração necessária, ter conhecimento do code smell auxiliará a ter um rumo quando eles ocorrerem. Tendo isto em vista, trouxemos alguns dos principais code smells com os quais vocês podem se deparar e alguns exemplos de como resolvê-los.
Mysterious Name (Nome Misterioso)
Enquanto programadores, eu diria que dar nome a algo é uma das tarefas que mais realizamos na nossa profissão, mas dar bons nomes, apesar de em alguns casos ser difícil, se mostra crucial para um código bem escrito.
Alguns programadores ainda consideram que aplicar refatoração em nomes seja uma perda de tempo. Entretanto, ter uma classe, função ou variável com nomes claros quanto ao seu objetivo e função pode evitar horas de dor de cabeça para entender o intuito de algo no código.
Duplicate Code (Código Duplicado)
Um dos code smells mais comuns e mais fácil de ser reconhecido é o código duplicado. Em sua essência, ele é um trecho de código que faz a mesma coisa, ou praticamente a mesma coisa, existindo em dois lugares diferentes do seu sistema. Veja o exemplo:
O problema em ter código duplicado acontece quando é preciso alterar algo em seu funcionamento. Assim, é preciso encontrar e realizar a alteração na cópia duplicada do código, se quiser que ambos tenham o mesmo comportamento.
Entretanto, é simples resolver a duplicidade de código: mantenha em apenas um lugar no código, fazendo uso de funções ou loops.
Comments (Comentários)
Comentários por si só não são um code smells. Muito pelo contrário, comentários são recomendados, eles te auxiliam a descrever o que está acontecendo ou explicar por que você fez algo, auxiliando no bom entendimento (tanto para você quanto para alguém que vai passar por ele depois).
O problema acontece quando comentários são utilizados para disfarçar código ruim, sendo utilizados de maneira supérflua em casos em que uma refatoração poderia render um melhor resultado.
No exemplo, podemos notar que o código por si só não é capaz de explicar o que está sendo feito. Por isso, são utilizados comentários. Assim, uma simples refatoração nos nomes das variáveis podem ajudar o código a nos contar melhor a história.
God Object (Classe Grande)
Outro code smell muito comum são as classes grandes. Isto é, classes que possuem muitos métodos ou propriedades que, apesar de parecer fazer sentido estarem juntos, acabam por criar classes com muitas responsabilidades e que podem ser perigosas para o seu sistema.
Essas classes surgem pois é muito mais simples atribuir um novo método a uma já existente do que criar uma nova. Diante disso, fica a dica: faça um esforço e separe bem as responsabilidades de cada classe.
Todavia, devemos analisar e refatorar essa classe, seja extraindo as funções que não lhe pertencem e criando a partir delas uma nova classe, ou identificando métodos pouco utilizados e extraindo para uma subclasse que só será necessária nesses raros casos.
Long Parameter List (Lista Longa de Parâmetros)
Apesar de não haver um padrão escrito, considera-se que 3 ou 4 parâmetros para uma função já estejam de bom tamanho. Ter muitos parâmetros dificulta para quem está lendo o código entender o que aquela função ou método faz. Além de ser difícil lembrar a ordem em que cada parâmetro deve ser disposto.
Algumas refatorações simples podem ser aplicadas em casos como estes. Dessa forma, é preciso apenas analisar o que está acontecendo.
Caso alguns dos argumentos sejam resultados de uma chamada de métodos de outras classes, remova-os como parâmetros e faça a chamada dos métodos dentro da função. Se muitos dos parâmetros são propriedades de um objeto, considere passar o objeto inteiro como parâmetro. Porém, caso sejam diversas propriedades de diversas fontes, é possível criar um novo objeto que servirá como parâmetro desta função.
Após refatorar uma lista longa de parâmetros, você terá um código mais limpo e de fácil leitura. Além disso, durante o caminho é possível que você identifique algumas duplicações de código que são comuns em casos como este.
Ferramentas
Agora que você já conhece alguns dos principais code smells, vamos conferir algumas ferramentas que irão te auxiliar a perceber aqueles odores que passaram despercebidos pelo seu olfato:
PMD
PMD é um programa open-source que atua como um analisador de código-fonte, identificando e relatando problemas encontrados. Apesar de já ter um conjunto de regras pré-definidos, ele apresenta também suporte a regras personalizadas.
O objetivo do PMD não é relatar problemas durante a compilação do código, mas sim ineficiências ou maus hábitos de programação. Por exemplo, variáveis não utilizadas, objetos criados desnecessariamente, dentre outros que, apesar de não impedirem o sistema de funcionar, podem reduzir o desempenho e dificultar a manutenção (caso se acumulem).
SonarQube
SonarQube é um programa open-source desenvolvido pela SonarSource que realiza uma inspeção contínua na qualidade do código e gera relatórios com análise de bugs, cobertura de código e code smells em 29 linguagens de programação. Este programa oferece relatórios para duplicação de código, padronização de código, cobertura de código por testes, comentários, bugs e recomendações de segurança.
Conclusão
Tendo o conhecimento do que é um code smell, como identificá-los e tratá-los, que tal dar uma busca naquele seu código que você não mexe há um tempo. Ou até mesmo no que você está escrevendo agora e já começar a pôr em ação essas novas boas práticas? Tenho certeza que vai te poupar muito tempo lá na frente!
Veja também:
Boas práticas de commits assinados e proteção de branches
Autor: Higor Koakovski.
