Código Limpo – Parte 05

Oi pessoal, tudo bem?

Realmente faz tempo que não postava algo, mas é por que o projeto de bloco da Pós-Graduação está tomando muito tempo. Então está complicado criar os posts.

Vamos continuar falando sobre Código Limpo? Os antigos posts você encontra aqui: Parte 01, Parte 02, Parte 03, Parte 04.

  • Copiar e Colar (mesmo em códigos não OO) -> Evitem isso ao máximo. Ao realizar uma tarefa existe uma enorme facilidade em copiar código de um lugar, e aplicar onde precisamos alterar. Com essa replicação de código estamos aumentando a dificuldade de manutenção, quebrando bons padrões de programação e talvez até propagando bugs.

    Imagine que existe um método com um complexo cálculo, onde é necessário aplicá-lo a outras partes do sistema. Ao invés de fazer alterações bem pensadas para deixar o método mais genérico, alguns desenvolvedores, acabam por escolher o mais fácil que seria copiar, colar. Após copiar e colar basta fazer pequenos ajustes. Imagine agora que após certo tempo nota-se que existe um erro no cálculo e alteramos o método inicial e o que foi replicado, mas o antigo programador não falou que esse código foi replicado mais 3x. Imaginou? Seria mais fácil ter criado apenas um método que fosse invocado em todas as partes do sistema.Reflita nisso. Quando você pensar “Eu já fiz esse código antes…”, quer dizer que é hora de parar, pensar e ver que está acontecendo uma provável duplicação:
    • Códigos não OO -> Crie apenas uma função e utilize-a de qualquer lugar do sistema.
    • Códigos OO -> Hora de aplicar super classes, classes abstrata, etc.
  • Remover código desnecessário -> Já reparou a quantidade códigos comentados existem em programas legados? Por exemplo:
    // user.setCreditCardByDate(credidCard, new Date());
    user.setCreditCard(credidCard);
    list.add(user);
    //for(int a = 0; i < list.size(); i++){
        //daoUser.deleteCredidCardHistory(list.get(i));
        //Logger.debug("im here!!!!");
    //}
    daoUser.deleteCredidCardHistory(list);

    Se esse método já está ultrapassado, por que mantê-lo? As vezes é normal deixar o código antigo enquanto se faz testes, mas salvá-los? Se você está incerto de sua alteração, é melhor pensar duas vezes antes de salvá-la por definitivo.
    Se tivermos um versionador qual seria o propósito de salvar um código comentado? Uma vez que temos essa ferramenta para consultar o antigo código sempre.

    O código salvo tem que ser um código limpo, que seja fácil de entender, objetivo. Quando um código apresenta vários códigos antigos comentados, o código atual perde um pouco do foco pois o desenvolvedor pode querer entender o código antigo comentado.

    Olhe como ficaria mais limpo o código:

    user.setCreditCard(credidCard);
    list.add(user);
    daoUser.deleteCredidCardHistory(list);
  • Conhecimento da linguagem -> Procure sempre aprimorar seu conhecimento na linguagem. Algumas vezes a própria linguagem já contém métodos prontos e já funcionais para você. “Não existe a necessidade reinventar a roda”. Mantenha-se informado sobre sua linguagem de desenvolvimento, se informe das novidades. Quando você receber uma tarefa que exige algo que você não fez ainda, pesquise.
    Um exemplo que uma vez encontrei, e virou piada na empresa, está no pedaço de código abaixo:

    for(int i = 0; i < 10; i++){
        //... Do stuff
        // Get inside the if when finds the condition
        if (...){
            i = 13;
        }
        // Do stuff
    }

    Vocês podem ver que ao invés de usar a palavra break, o desenvolvedor alterou o valor do contador. Sendo que poderia ser feito de forma mais fácil e com mais estilo:

    for(int i = 0; i < 10; i++){
        //... Do stuff
        // Get inside the if when finds the condition
        if (...){
            break;
        }
        // Do stuff
    }

    Talvez você pense: “Bem, estava funcionando não estava?” Eu te responderei que sim, mas também acrescento que você não irá virar piada se você estiver sempre querendo conhecer sua ferramenta de trabalho. Outra coisa a se pensar é, e se realmente fosse necessário alterar o valor do contador? Se o total subisse para 100 ao invés de 10? Teria que aumentar o valor do contador junto com o valor total de loops. Não vale a pena.

  • TODO – As IDEs de hoje nos ajudam muito com esse lembrete. Facilmente podemos escrever “// TODO” (em português “A Fazer”), e ver essas referências que estão por todo classe/sistema. Realmente é muito simples colocar esse lembrete em meio ao nosso código, pode nos lembrar de tudo que realmente está pendente.TODO
    O problema é que assim como é fácil criar é fácil esquecer. Uma vez que isso vire prática na empresa, milhares de TODOs poderão aparecer na view de Tasks em pouco tempo, com isso, vão ficar poluídos a view e seu código.
    Uma saída seria evitar esse tipo de abordagem, uma vez que você sabe que não existe previsão para realizar a alteração marcada no TODO. (Para mais informações dessa abordagem: Watch out for TODO comments! By Alexandre Gazola).
    Outra saída seria criar tags personalizadas. Para isso, a tag TODO poderia ter seu uso definido apenas para ações rápidas e que serão finalizadas antes do código ser salvo no versionador. Poderíamos criar, por exemplo: “// REMAKE …” ou então “// REFACTOR …” E pelas IDEs é possível filtrar por tags customizadas.
  • Perca seu orgulho – Creio que uma das maiores barreiras do ser humano é essa, perder o orgulho. Talvez você tenha uma tarefa a fazer, tenha 30 anos como desenvolvedor e com isso acaba por não comentar com ninguém ou trocar idéias sobre sua tarefa. Orgulho é algo que apenas prejudica o ser humano. A melhor coisa a se fazer é ter um bate papo rápido com algumas pessoas da equipe para coletar idéias, mescle todas, e pode ter certeza que seu código tem tudo para ter bons padrões de projeto, as corretas tecnologias e uma boa modelagem OO.
    Não é só por que alguém acabou de entrar na equipe que ele não irá ter conhecimento algum. Conversar e trocar idéias irá levar seu projeto a um novo patamar.
    Deixe seu orgulho de lado, ele não irá te levar a lugar algum.

Por hoje é só qualquer observação basta colocar. Não sei quando irei postar novamente por causa da Pós-Graduação, mas em breve terei várias tutoriais para colocar aqui.

Até mais! o_

8 thoughts on “Código Limpo – Parte 05

  1. O melhor dos posts na minha opinião como estou iniciando tem gente antiga que não troca informação mesmo :D

    Abraço.

    • Realmente, esse assunto ajuda a melhorar e muito a qualidade do nosso código.

      Infelizmente muitas pessoas não se importam e acabam fazendo um código de má qualidade.

      Fico feliz por você estar começando e já vejo que está a começar de um bom modo.

      Volte sempre. [=

  2. Adorei os posts sobre código limpo. Parabéns por dedicar parte de seu tempo para compartilhar conhecimento. Irei ler mais posts.

    Até mais! o_

Leave a Comment