C# - Refatoração : Code Smell ou 'código que cheira'

Hoje vamos continuar tratando da refatoração tendo como objetivo obter um código limpo.

Continuando o artigo anterior , hoje vamos apresentar os principais 'code smell' que identificam um código como ruim fazendo o código 'cheirar mal' e indicar que precisa ser refatorado.

Vamos recordar o que significa o termo 'Code Smell'.

O termo code smell (código que cheira) é aplicado quando o código fonte de qualquer programa indica algum problema.

Não pense que um código que cheira é um código com bugs, não, o código aparenta estar tecnicamente correto e não impede o programa de funcionar. Na verdade o code smell indica que o projeto de software não foi bem feito e que vai apresentar uma alta taxa de manutenção com riscos de apresentar bugs catastróficos no futuro.

Podemos identificar um code smell em nosso código usando as seguintes práticas:

• Inspecionar o código procurando por violação das boas práticas;
• Realizar a análise heurística;

A seguir vou apresentar uma relação com os principais 'code smells':

1. Usar uma nomenclatura abstrata, inconsistente e confusa

Qual é o pior nome de uma variável ?

R: Aqui temos vários candidatos: dados, temp , val, result, s, button, etc.

Qual o segundo pior nome e o terceiro pior nome ?

R: dados2, dados_2, val1, result1, temp_1, dados3, s1, button1, etc...

Assim:

• Usar nomes vagos e de significado geral ou nomes abstratos que podem ser interpretados de diversas formas independente do contexto;
• Abreviar os nomes ou usar sufixos numéricos para diferenciação entre os nomes;
• Usar nomes abreviados: Ex:  val, sal, res, etc.;
• Usar símbolos para definir nomes. Ex:  >=>, @, [ , etc.;
• Usar palavras vagas. Ex: GerenciarPedido, Imposto, etc.;

Vai tornar o seu código bem esotérico e obscuro, sendo difícil de ler e de entender.

Conhece aquela : "Quando eu escrevi este código eu e Deus entendiam o código, agora, após um ano, só Deus..." 

2. Usar os famigerados números mágicos

Números mágicos são números que você usa no seu código e que estão soltos e não possuem nenhuma semântica.

Ao ler o código que usa números mágicos fica difícil interpretar o seu significado. Veja:

O que significa 0.05 neste código ?

A princípio você pode até inferir o seu significado mas você não tem certeza do seu impacto nas regras de negócio do projeto.

Além disso essa abordagem estiver sendo usada em outras partes do código, havendo a necessidade de alterar o valor isso terá que ser feito em mais de um lugar.

3. Usar classes e/ou métodos muito longos ou com uma longa lista de parâmetros

Uma classe muito longa vai conter muitos campos, métodos e linhas de código. Geralmente a classe começa pequena e vai crescendo conforme vamos implementando funcionalidades em um projeto. O mesmo podemos dizer dos métodos longos.

Assim, uma classe ou um método muito longo geralmente possui uma complexidade maior e provavelmente vai violar o princípio SRP pois vai conter mais de uma responsabilidade.

Além disso uma classe ou um método longo é difícil de ser reutilizado e também de ser testado.

Exemplo:

        public decimal Calcular(decimal valor, int tipo, int anos)
        {
            decimal resultado = 0;
            decimal desc = (anos > 5) ? (decimal)5 / 100 : (decimal)anos / 100;
            if (tipo == 1)
            {
                resultado = valor;
            }
            else if (tipo == 2)
            {
                resultado = (valor - (0.1m * valor)) - desc * (valor - (0.1m * valor));
            }
            else if (tipo == 3)
            {
                resultado = (0.7m * valor) - desc * (0.7m * valor);
            }
            else if (tipo == 4)
            {
                resultado = (valor - (0.5m * valor)) - desc * (valor - (0.5m * valor));
            }
            return resultado;
        }

Podemos incluir aqui também a utilização de uma longa lista de parâmetros usados em métodos. Isso é um sintoma que em geral acompanha os métodos longos.

Em geral uma longa lista de parâmetros ocorre depois que vários tipos de algoritmos são mesclados em um único método e a lista de parâmetros foi criada para controlar qual algoritmo será executado e como.

4. Abusar no uso de comentários no código

Comentar o código é uma polêmica que pode se arrastar sem uma conclusão final.

Os comentários geralmente são criados com a melhor das intenções, quando o autor percebe que seu código não é intuitivo ou óbvio.

Mas de forma geral, se o seu código for claro e fácil de entender ele não vai precisar ser comentado. Não é mesmo ???

Um grande problema dos comentários é que na manutenção se o código for alterado e os comentários não, isso pode levar a erros de interpretação futuras.

Assim os comentários devem ser bem sucintos e objetivos e usados com parcimônia.

5. Utilizar Código duplicado

Duplicar código pode ser considerado um 'pecado mortal' no desenvolvimento de software.

O código duplicado ocorre quando temos dois fragmentos de código idênticos com o mesmo objetivo e mesmo resultado, sendo que muitas vezes isso não é facilmente identificável.

A duplicação geralmente ocorre quando vários programadores estão trabalhando em diferentes partes do mesmo programa ao mesmo tempo. Como estão trabalhando em tarefas diferentes, eles podem não saber que seu colega já escreveu um código semelhante que poderia ser reaproveitado para suas próprias necessidades.

Também há uma duplicação mais sutil, quando partes específicas do código parecem diferentes, mas na verdade executam o mesmo trabalho. Esse tipo de duplicação pode ser difícil de localizar e corrigir.

Às vezes, a duplicação é proposital. Quando se apressam para cumprir prazos e o código existente é “quase certo” para o trabalho, os programadores novatos podem não ser capazes de resistir à tentação de copiar e colar o código relevante. E, em alguns casos, o programador é simplesmente preguiçoso demais e acha mais fácil copiar e colar.

6. Usar uma abordagem que dificulta a manutenção do código

Aqui temos um problema que se manifesta de formas distintas e até opostas.

Um sintoma desse problema ocorre quando você tem que alterar muitos métodos não relacionados ao fazer alterações em uma classe. Como resultado, o desenvolvimento do programa se torna muito mais complicado e caro.

Outro sintoma é quando ao ter que realizar qualquer alteração no código te obriga a realizar pequenas alterações em muitas classes diferentes. Esse sintoma indica que uma única responsabilidade foi dividida e espalhada em outras classes.

7. Usar código que causa um forte acoplamento entre classes

Os sintomas dessa prática podem se manifestar da seguinte forma:

• Os métodos tendem a acessar dados de outro objeto mais do que os seus próprios métodos;
• As classes usam os campos internos e métodos de outra classe;
• Existe o encadeamento de mensagens onde um cliente solicita outro objeto e esse objeto solicita outro e assim por diante. Assim o cliente vai depender da navegação ao longo de uma estrutura de classes dificultando a manutenção.
• Se uma classe definida para realizar uma tarefa, delegar esse trabalho para outra classe. Por que ela existe então ?

Relacionei 7 tópicos que indicam que um código pode estar cheirando mal.

Com certeza existem outros fatores que podem causar o mesmo problema e que não constam desses tópicos, mas creio que esses podem ser considerados os principais.

Aguarde que voltaremos ao assunto.

"17 Quando o vi (Jesus), caí aos seus pés como morto. Então ele colocou sua mão direita sobre mim e disse: "Não tenha medo. Eu sou o primeiro e o último. 18 Sou aquele que vive. Estive morto mas agora estou vivo para todo o sempre! E tenho as chaves da morte e do Hades."
Apocalipse 1:17,18