Code Smell foi um termo criado por Kent Beck quando ele ajudava Martin Fowler a escrever seu best seller Refactoring, Improving the Design of Existing Code. O termo smell, que pode ser traduzido livremente para cheiro, foi escolhido porque um odor é algo perceptível. De igual forma, possíveis problemas no código de um programa podem ser percebidos com facilidade.
Na verdade, quando esse termo foi usado pela primeira vez se tinha em mente que nem todo odor é ruim. Igualmente, se o código causa certa estranheza, ela pode ser apenas uma impressão. De qualquer forma, vale a pena fazer uma análise mais profunda ao menor sinal de problema e os Code Smells são exatamente isso: um indicador de que há um problema maior na aplicação.
Conhecendo os tipos de smells
Desde que o termo foi usado pela primeira vez, os Code Smells vêm sendo catalogados e atualmente podemos dividi-los em seis grupos que serão detalhados a seguir.
Código muito grande (Bloaters)
São códigos que cresceram demais, na maioria dos casos porque suas responsabilidades não foram bem delimitadas durante o planejamento da aplicação. O termo Bloater, que nos remete a palavra inchado, vem do fato do código consumir responsabilidades de outras classes. Métodos e classes muito longos, bem como longas listas de parâmetros são alguns exemplos de Code Smells nesta categoria.Violação a orientação a objetos (Object-Orientation Abusers)
Como visto em Os pilares da Programação Orientada a Objetos, este paradigma se apoia em quatro fundamentos que devem ser utilizados para que os benefícios de sua adoção possam ser percebidos pelo programador. Dois dentre esses benefícios são a facilidade de manutenção e reutilização de código, mas existem muitos outros. Contudo, a aplicação incorreta ou parcial da abstração, herança, polimorfismo ou encapsulamento pode gerar problemas no código.Um dos indicadores mais comuns desse problema é a presença de muitos ifs aninhados ou switchs complexos. Geralmente, quando precisamos modificar código escrito dessa forma, precisamos também modificar/rearranjar cada bloco if/switch relacionado a ele. Nesses casos, uma possível correção pode ser mover o código realizado por essas estruturas para métodos de classes.
Inibidores de modificação (Change Preventers)
Lembra daquele velho termo “código espaguete”? Ele vem do fato de que ao puxar um fio em um prato de macarrão, geralmente outros fios estão conectados a ele e acabam sendo puxados juntos. O código espaguete é aquele no qual, para alterar um ponto, precisamos também fazer alterações em diversos outros, o que torna a manutenção uma dor de cabeça. Uma vez que fazer pequenas correções no código é uma tarefa corriqueira, ela também deve ser de fácil realização e, portanto, códigos com esse sintoma devem ser reescritos a fim de tornar o crescimento da aplicação possível.Código dispensável (Dispensables)
Algumas vezes abrir mão de um certo trecho pode tornar o código mais claro. Isso é facilmente percebido quando existem trechos de código duplicados, comentários excessivamente longos ou quando funcionalidades são removidas da aplicação, tornando alguns algoritmos dispensáveis, por exemplo. Nesses casos é melhor remover o código sem utilidade atualmente em lugar de deixar a aplicação maior desnecessariamente.Acopladores (Couplers)
Esta categoria está diretamente relacionada ao problema do acoplamento e do relacionamento entre as classes da aplicação. Você já deve ter ouvido em uma de suas aulas de orientação a objetos que uma aplicação de qualidade tem alta coesão e baixo acoplamento, mas o que vem a ser isso? Acoplamento é a forma que temos de medir o quão dependente uma classe é de outras para realizar as suas próprias ações.Geralmente, dizemos que uma classe está acoplada a outra quando o relacionamento entre ambas é desnecessário ou quando a tarefa a ser desempenhada é delegada a uma terceira classe. Esse smell, de nome Middle Man, nos faz refletir sobre a necessidade de manter no projeto as classes que existem apenas para delegar suas responsabilidades a outras.
Conclusão
Apesar de não serem bugs, Code Smells certamente podem condenar uma aplicação, se não forem tratados a tempo. Portanto, uma vez que estamos sempre revisitando código antigo, ou para manutenção ou expansão, aproveite esse momento para refletir sobre sua qualidade e considerar a possibilidade de refatora-lo. Lembre-se que não é preciso ser um gênio da matemática para ser um bom programador, basta que sejam cultivados bons hábitos.
