Clean Code (Código limpo) – Design Emergente

Limpeza por meio do design emergente

As quatro regras de Design Simples de Kent Beck são de grande ajuda na criação de um software bem projetado.
De acordo com ele, um design é considerado “simples” se seguir as seguintes regras:

  • Executa todos os testes unitários;
  • Não contém duplicação;
  • Expressa a intenção do programador;
  • Minimiza o número de classes e métodos;
  • Regra 1 de design simples: executa todos os testes

    Um sistema pode ser perfeito no papel, mas se não houver uma maneira simples de verificar se o sistema realmente funciona conforme planejado, todo o esforço no papel é questionável.

    Um sistema que não pode ser verificado nunca deve ser implantado

    Tornar nossos sistemas testáveis nos leva a um projeto em que nossas classes são pequenas e têm um único propósito. É apenas mais fácil testar as classes que estão em conformidade com o SRP. Quanto mais testes escrevermos, mais simples nosso código ficará e mais simples para manter. Portanto, garantir que nosso sistema seja totalmente testável nos ajuda a criar designs melhores.

    Acoplamento rígido torna difícil realizar testes unitários. Portanto, da mesma forma, quanto mais testes escrevemos, mais usamos princípios como DIP e ferramentas como injeção de dependência, interfaces e abstração para minimizar o acoplamento. Deixando assim nossos projetos melhores.

    Finalmente, podemos dizer que, escrever testes leva a designs melhores.

    Regras 2 até 4 de design simples: Refatoração

    O fato de termos testes unitários deve eliminar o medo de que fatorá-lo pode quebrá-lo!

    Durante esta etapa de refatoração, podemos aumentar a coesão, diminuir o acoplamento, separar os interesses, modularizar os interesses do sistema, reduzir nossas funções e classes, escolher nomes melhores e assim por diante. É aqui que aplicamos as três regras finais do design simples: Elimine a duplicação, assegure a expressividade e minimize o número de classes e métodos.

    Sem Duplicação

    A duplicação é o principal inimigo de um sistema bem projetado. Representa trabalho adicional, risco adicional e complexidade desnecessária.

    Linhas de código que parecem exatamente iguais são, é claro, código duplicado. As linhas de código que são semelhantes normalmente podem ser trabalhadas para ficarem ainda mais semelhantes ao ponto de serem totalmente refatoradas.

    Vamos analisar o código da classe SampleColectionClass

        public class SampleColectionClass
        {
            public int Size()
            {
                // Size implementation
            }
    
            public bool IsEmpty()
            {
                // IsEmpty implementation
            }
        }
    

    Neste caso, poderíamos ter implementações separadas para cada método, ou podemos eliminar essa duplicação vinculando IsEmpty à definição de tamanho, ficando da seguinte maneira.

        public class SampleColectionClass
        {
            public int Size()
            {
                // Size implementation
            }
    
            public bool IsEmpty()
            {
                return Size() == 0;
            }
        }
    

    Refatorar melhora a visibilidade, podendo facilitar para pessoas da equipe abstrair ainda mais um novo método e reutilizá-lo em um contexto diferente. Essa “reutilização dos pequenos” pode fazer com que a complexidade do sistema diminua drasticamente.

    Expressivo

    É fácil escrever um código que nos autores entendemos, porque, no momento em que o escrevemos, temos um profundo conhecimento do problema que estamos tentando resolver. Outros mantenedores do código não terão um conhecimento tão profundo, e mesmo sendo o autor, quando voltamos alguns meses depois no código, podemos ficar preso em uma lógica que no momento, não faz o mesmo sentido que já fez.

    – O código deve expressar claramente a intenção de seu autor. Quanto mais claro o autor puder tornar o código, menos tempo os outros terão de despender para entendê-lo. Isso reduzirá os defeitos e diminuirá o custo de manutenção.

    – Você pode se expressar escolhendo bons nomes. Queremos ser capazes de ouvir o nome de uma classe ou função e não nos surpreender quando descobrirmos suas responsabilidades.

    – Você também pode se expressar mantendo suas funções e classes pequenas. Classes e funções pequenas geralmente são fáceis de nomear, escrever e entender.

    – Você também pode se expressar usando a nomenclatura padrão. Os padrões de projeto, por exemplo, são em grande parte sobre comunicação e expressividade.

    Testes unitários bem escritos também são expressivos. O principal objetivo dos testes é atuar por exemplo, como documentação. Alguém lendo nossos testes deve ser capaz de obter uma compreensão rápida do que uma determinada classe ou método faz.

    Mas a forma mais importante de ser expressivo é tentar. Com muita frequência, passamos para o próximo problema sem pensar o suficiente se o código atual que funciona esta fácil para próxima pessoa ler. Lembre-se de que a próxima pessoa com maior probabilidade de ler o código será você.

    Apenas tome cuidado com o que você criou. O cuidado é um recurso precioso.

    Métodos e classes mínimas

    Devemos sempre evitar o dogmatismo sem sentido. Considere, por exemplo, um padrão de codificação que insiste em criar uma interface para cada classe. Ou considere os desenvolvedores que insistem que os campos e o comportamento devem sempre ser separados em classes de dados e classes de comportamento. Deve-se resistir a tal dogma e adotar uma abordagem mais pragmática.

    Nosso objetivo é manter nosso sistema geral pequeno, enquanto também mantemos nossas funções e classes pequenas. Lembre-se, entretanto, de que essa regra é a prioridade mais baixa das quatro regras do Design Simples. Portanto, embora seja importante manter a contagem de classes e funções baixas, é mais importante ter testes, eliminar a duplicação e se expressar de forma clara.

    Conclusão

    Existe um conjunto de práticas simples que podem substituir a experiência? Claro que não.

    Por outro lado, as práticas descritas neste capítulo e nesse grupo de artigos são uma forma cristalizada das muitas décadas de experiência. Seguir a prática do design simples pode encorajar e capacitar os desenvolvedores a aderir a bons princípios e padrões que, de outra forma, levam anos para aprender.

    Qualquer dúvida ou dicas, entre em contato: leandrolt@gmail.com

    Referência
    – Clean Code: A Handbook of Agile Software Craftsmanship (English Edition) – Robert C. Martin – Capítulo 12

    Leave a Reply

    Your email address will not be published. Required fields are marked *