Código limpo, um resumo pra quem tem pressa. Pt3

Esta é a parte três da série de artigos sobre o livro código limpo, neste artigo contemplaremos testes de unidade, classes, e emergência

Para quem não viu as outras partes, segue os links :

• Pt01: https://medium.com/@isaacmeira96/c%C3%B3digo-limpo-um-resumo-pra-quem-tem-pressa-b3a5c49b5fbc
• Pt02: https://medium.com/@isaacmeira/c%C3%B3digo-limpo-um-resumo-pra-quem-tem-pressa-pt2-a282566e2891

No mais, vamos nessa.

Testes de Unidade

Nossa profissão evoluiu bastante desde os anos 90, na época, os testes unitários eram pequenos pedaços de códigos descartáveis que escrevia-se para certificar que os programas funcionavam, mas progredimos, mas ainda podemos ir mais longe. Os movimentos do Agile e do TDD tem incentivado muitos programadores a criarem testes de unidade automatizados, e muitos outros estão se unindo a cada dia. Mas nessa correria para adicionar testes ao nosso ofício, muitos programadores tem se esquecido de alguns pontos mais importantes e sutis de se escrever bons testes.

As três leis do TDD

Hoje em dia todos sabem que o TDD nos pede para criar primeiro os testes de unidade antes do código de produção. Mas essa regra é apenas o início:

• Primeira lei : Não se deve escrever o código de produção até criar um teste unitário de falhas.
• Segunda lei : Não se deve escrever mais de um teste unitário que o necessário para falhar, e não compilar é falhar.
• Terceira lei : Não se deve escrever mais códigos de produção do que o necessário para aplicar o teste de falha atual.

Essas leis colocam numa rotina que talvez durem 30 segundos, os testes e o código de produção são escritos juntos, com os testes apenas alguns segundos mais adiantados.

Se trabalharmos desta forma, criaríamos dezenas de testes a cada dia, centenas a cada mês e milhares a cada ano, cobrindo assim praticamente todo o nosso código de produção.

Como manter os testes limpos

Ter testes porcos, que não totalmente descartáveis e inconcretos é equivalente, se não pior do que não ter teste algum, além disso é algo que atrasa no desenvolvimento, quando se faz testes que não tem sentido algum, no final, você ainda tem um produto cheio de falhas e o retrabalho acontece.

O Livro aborda uma série de questões sobre como mantes os testes limpos, vou elencar as que eu achei mais importante:

1. legibilidade, legibilidade e legibilidade:

O que torna um teste legível ?

O mesmo que torna códigos legíveis: Clareza, simplicidade e consistência de expressão.

2. Ter cuidado para não violar a regra do mapeamento mental

Basicamente a regra de mapeamento mental é que quem lê teu código não deve traduzir os nomes que você escolheu para outros que eles sabem, ou seja, seja claro na escolha dos nomes de qualquer coisa dentro dos testes.

3. Único conceito por teste

Como as funções, testes devem abordar apenas coisas relacionadas a uma coisa e fazer uma coisa só, por exemplo, você tem 3 helpers na sua aplicação e quer testá-los, você não irá criar um para os três, mas um para cada.

F.I.R.S.T

Testes limpos seguem outras cinco regras que forma o acrônimo em inglês (Fast, Independent, Repeatable, Self-validating- Timely)

• Rapidez ( Fast ) : Os testes devem ser rápidos. Devem executar com rapidez
• Independência ( Independent ) : Os testes não devem depender uns dos outros. Um teste não deve configurar as condições para o próximo. Você deve ser capaz de executar cada teste de forma independente e na ordem que desejar.
• Repetitividade ( Repeatable ) : Deve-se poder repetir os testes em qualquer ambiente. Você deve ser capaz de efetura testes no ambiente de produção, no de garantia de qualidade, e no seu notebook enquanto volta pra casa de metrô sem uma rede disponível.
• Autovalidação ( Self-validating ) : Os testes não devem ter uma saída booleana. Obtenham ou não êxito, você não deve ler um arquivo de registro pra saber o resultado.
• Pontualidade ( Timely ) : Os testes precisam ser escritos em tempo hábil. Devem-se criar os testes de unidade imediatamente antes do código de produção no qual serão aplicados.

conclusão

Aqui abordamos apenas o início deste tópico, deveriamos ter um livro inteiro sobre testes limpos. Os testes são tão importantes para a saúde de um projeto quanto o código de produção.

Classes

O Livro aborda várias situações de classes, então para sermos mais dinâmicos, vou resumir os principios básicos de cada situação:

• As funções públicas devem vir após a lista de variávies. Gostamos de colocar as tarefas privadas chamadas por uma função pública logo depois desta. Isso segue a regra de cima para baixo e ajuda o programa a ser lido como um artigo de jornal.
• Perder o encapsulamento só quando não for possível mantê-lo, sempre será o último recurso.
• As Classes devem ser pequenas !
• Minimizar o máximo possível o acoplamento
• As Classes devem ser coesas

O princípio da Responsabilidade Única

Este princípio afirma que uma classe ou módulo deve ter um, e apenas um, motivo para mudar. Este princípio nos dá uma definição de responsabilidade e uma orientação para o tamanho da classe. Estas devem ter apenas uma responsabilidade e um motivo pra mudar:

Saiba Mais : https://www.toptal.com/software/single-responsibility-principle

O princípio da injeção de dependência

Ao minimizar o acoplamento, nossas classes aderem a outro princípio de projeto de classes conhecido como Princípio de injeção de dependência, (DIP sigla em inglês). Basicamente, o DIP diz que nossas classes devem depender de abstrações, não de detalhes concretos.

Saiba Mais : https://stackify.com/dependency-inversion-principle/

O livro neste momento aborda construção de sistemas, mas o mesmo aborda totalmente para linguagens totalmente orientadas, logo, não vou entrar em detalhes, só queria frizar que é sempre bom manter padrões e desenhar bem o sistema na hora de desenvolvê-lo, para facilitar tanto na manutenção quanto na integração do mesmo. Deixar a estutura de pastas bem coesas, deixar as regras bem separadas, etc, isso é fundamental.

Emergência

E se houvesse quatro regras simples que você pudesse usar para lhe ajudar na criação de bons projetos enquanto trabalhasse ?

Muitos de nós achamos que as quatro regras do projeto simples de Kent Beck sejam de ajuda considerável na criação de um software bem projetado, de acordo com Kent, um projeto é “ simples ” se seguir as seguintes regras :

• Efetuar todos os testes
• Sem duplicação de código
• Expressar o propósito do programador
• Minimizar o número de classes e métodos

Estas regras estão em ordem de relevância.

• Regra 01 : Primeira e acima de tudo, um projeto deve gerar um sistema que funcione como o esperado, um sistema que é testado detalhadamente e que passa em todos os testes é um sistema passível de testes. Isto pode parecer óbvio, mas é importante. Os sistemas que não podem ser testados não podem ser verificados, logo, jamais deveria ser implementado.
• Regra 02 : A repetição de código é o inimigo principal para um sistema bem desenvolvido, ele representa trabalho, risco e complecidade desnecessárias extras.
• Regra 03 : A maioria dos custos de um projeto de software está na manutenção ao longo prazo, afim de reduzirmos os possíveis danos conforme fazemos alteraçõs, precisamos saber o que o sistema faz, portanto, o código deve expressar claramente o propósito do seu autor.
• Regra 04 : Esta regra sugere que devemos manter a mínima quantidade de funções e classes, às vezes são apenas resultados de dogmatismos exagerados, o nosso objetivo é manter nosso sistema geral pequeno e ao mesmo tempo que também mantemos classes e funções pequenas.

Conclusão

Há uma série de práticas simples que possam substituir a experiência ? Obviamente que não. Por outro lado, as práticas descritas neste capítulo são uma forma consolidade de muitas décadas de experiência adiquiridas pelos autores.

Logo, já adianta alguns princípios e padrões que levaríamos um bom tempo para aprendermos.

Agora, resumimos até o capítulo 12 do livro, um resumo de algo de cerca de 176 páginas, sim, o livro é grande pra caramba !

Agora, nesta parte do livro em diante, o que é tratado são coisas específicas de linguagem, tal como JUnit, refatoramento de SerialDate, etc, que não faz muito sentido para o que eu queria trazer.

Ja que estou resumindo coisas pertinentes a qualquer linguagem, no livro, existem tópicos que servem somente para Java.

Se gostou e quer que o trabalhe continue, dê 1 ou 50 claps (Sim, você pode dar 50 palminhas se isso ajudou em algo rsrsrs). Como sempre, espero que eu possa ajudar a comunidade de alguma forma, então se você tem dúvidas, sugestões ou comentários, deixe-me saber !

See ya.