Início > Atitude, Programação > Ame Teu Código Como a Ti Mesmo

Ame Teu Código Como a Ti Mesmo

Nas últimas semanas, começamos um trabalho de levantamento do que ficou pendente – ou melhor, do que foi empurrado com a barriga desde o começo – para finalizarmos o projeto. As pendências incluem requisitos parcialmente atendidos e tarefas técnicas. Me surpreende – às vezes não – o tipo de código que vejo em certos módulos. Vendo o histórico das alterações nas linhas de um método, parece que todo mundo que já passou pelo projeto colocou a mão ali mais de uma vez, mas ninguém se preocupou sequer em fazer alguns pequenos refactorings que melhorariam a legibilidade daquele código.

Acho que um código limpo mostra comprometimento com a equipe e preocupação com a qualidade. Às vezes, basta alterar o nome de uma variável e já temos um bom ganho em clareza. Há ocasiões em que a aplicação de alguns patterns ajudariam bastante. Fico bastante chateado quando concluo que o que faltou foi um entendimento de orientação a objetos, fundamentos de programação ou conhecimento da API. Pouco conhecimento de negócio, dependendo do que for e da postura para procurar saber, é aceitável, pois essa aplicação é bastante complexa. Por isso, vou usar um exemplo fictício de outra área de negócio, mas que contém elementos que garimpei do nosso código:

private int calculateDiscounting(int c){
     // Se o cliente for uma pequena fazenda, não tem desconto
     int dis = 0;
     // Se o cliente for uma grande fazenda, tem um desconto especial
     if(c == 1){
         dis = 1;
     }
     return dis;
}

Esse método, mesmo sendo pequeno, apresenta vários problemas. Vale lembrar que para fazer um refactoring não é só o tamanho de um método que deve ser levado em consideração. A picada da aranha armadeira, um bicho minúsulo, pode te matar. O vírus da AIDS, invisível a olho nú, destrói o sistema imunológico e abre caminho para aniquilação do organismo. É assim que encaro um código ruim: um pequeno inimigo muito perigoso que precisamos combater.

Não vou fazer todas as alterações que gostaria de fazer nesse código. Vamos apenas aumentar a clareza. Se um dia surgisse um requisito que necessitasse de intervenção em código, partiríamos de uma implementação “refactoring friendly“.

Pelo nome, calculateDiscounting(…) afirma que faz um cálculo de desconto, mas o que vemos é uma decisão quanto à categoria de desconto. Os nomes do parâmetro e das variáveis também estão ruins. O que são “c” e “dis”? Vamos supor que pelo menos os tipos estão corretos e seus valores não podem ser alterados, pois são conhecidos fora do método. A propósito, o que são esses “números cabalísticos” testados? Outra coisa que chama a atenção são os comentários in-line. Esse é o chamado “mau cheiro de código” e geralmente marca pontos candidatos a refactoring.

public enum DiscountingCategory(){
     WITHOUT_DISCOUNTING,
     ESPECIAL_DISCOUNTING;
}

public enum CustomerType(){
    SMALL_FARM,
    BIG_FARM;
}

private DiscountingCategory findDiscountingCategory(CustomerType customerType){
     DiscountingCategory discountingCategory = WITHOUT_DISCOUNTING;
     if (customerType == BIG_FARM) {
         discountingCategory = ESPECIAL_DISCOUNTING;
     }
     return discountingCategory;
}

Sinal verde: os testes passaram e agora as coisas fazem mais sentido. Troquei as constantes por tipos enumerados e alterei os nomes do parâmetro e das variáveis. Os “números cabalísticos” podem ser recuperados de fora pelo ordinal() do enumerado, ou seja, não modifiquei a dependência para os valores 0 e 1. Isso fica para o próximo refactoring. Acho que vou parar por aqui.

Conclusão

Em A Melhor Solução é a Simples, citei uma passagem do livro Modelagem Ágil, de Scott W. Ambler. Nesse trecho, ele aponta os problemas decorrentes de se modelar demais para tentar resolver todos os problemas imagináveis. Portanto, não perca tempo inventando requisitos: pare quando a luz verde acender e seu código estiver claro o suficiente.

Anúncios
Categorias:Atitude, Programação
  1. 17/07/2011 às 12:09 PM

    Achei uma frase de Sêneca que se aplica a quem fica projetando demais:

    “O homem que sofre antes de ser necessário, sofre mais que o necessário.”

  1. 14/07/2011 às 7:23 PM

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: