Arquitetura Limpa – Clean Code

O que é Clean-code?

Clean Code, ou Código Limpo, é uma filosofia de desenvolvimento de softwares que consiste em aplicar técnicas simples que facilitam a escrita e a leitura de um código, tornando-o, assim, de fácil compreensão. Código limpo é igual a ter um texto bem escrito, de fácil leitura. As técnicas do Clean Code apareceram pela primeira vez no livro Clean Code: A Handbook of Agile Software Craftsmanship. Ele foi escrito por Robert Cecil Martin, conhecido na comunidade como Uncle Bob (Tio Bob).

Por que aplicamos Clean Code?

Ao não aplicarmos os conceitos de Clean Code durante o desenvolvimento, a qualidade do código não será boa o suficiente, e ficará com pendências que você terá que retornar futuramente para ajustar, e essas “pendências” nos geram retrabalho futuro.

Como resolver os problemas de códigos mal-feitos e sem qualidade?
Resposta: A tão temida REFATORAÇÃO (processo que tem como objetivo melhorar o código sem alterar seu comportamento final). Nada mais é do que fazermos uma faxina no código, para uma melhor leitura.

Para que aplicamos Clean Code?

O erro de muitos programadores é se preocupar apenas com a entrega do código, que ele esteja funcionando e que a entrega seja bem sucedida, sendo assim, não precisará de manutenção ou revisitar esse código entregue. Porém, vale lembrar que o campo de desenvolvimento de software sofre muitas atualizações contínuas, ou seja, o que você entregou hoje que está funcionando e atualizado, em seis meses pode estar obsoleto. Logo, o Clean Code seria uma solução para um código bem escrito, evitando gastos desnecessários e tornando o software pronto para novas atualizações.

Principais conceitos de Clean Code:

1. Variáveis

É muito importante o nome que colocamos ao declarar uma variável. Tenha sempre em mente nomes expressivos, de fácil entendimento referente ao que ela faz, e que sejam diretos, para que ao lermos entendamos o que aquela variável representa.

Exemplos:

Ao declarar variáveis não as declare com nomes curtos e insignificantes, onde temos que decifrar o que ela faz, porque ficará a interpretação de cada desenvolvedor, e isso pode ser um problema.

2. Classes e métodos

Assim como temos que nos atentar em que nome dar as variáveis que criamos, temos que nos atentar às nossas classes e métodos que desenvolvemos. E que o nome dessa classe e dos métodos que irão dar vida a ela, tenha clareza e coerência.

Dicas de desenvolvimento:

Recomenda-se que cada método tenha de 1 a 3 parâmetros sendo passados a eles.
Em caso de mais de 3 parâmetros, é instruído que se construa um data class enviando apenas um parâmetro.
Se o método é coerente com o nome dado a ele, não há necessidade de incluir comentários explicativos.
A simplicidade é fundamental.
Métodos sem complexidades com um tamanho reduzido.
Cada método, deve ter menos de 20 linhas de código para que se tenha uma boa interpretação, e um código limpo.
Evitar usos excessivos de if/else, troque por if ternários ou switch case.

O que não fazer em uma classe?

Não atribuir muitas responsabilidades a uma classe, no futuro isso pode causar problemas.
Não colocar comentários desnecessários. O uso de comentários é somente para explicar o porquê de uma determinada abordagem. Naturalmente, pelo próprio nome do método como dito anteriormente, já é possível identificar o que o método/classe faz, sem a necessidade de comentários desnecessários.
Dar preferência a classe com única responsabilidade, por exemplo, temos uma classe User, inserir apenas informações sobre o User como: nome, idade, data de nascimento. Dados de endereço, podemos criar uma nova classe Address e inserimos rua, bairro, cidade, número, complemento, país etc, que será associada ao User.

Estrutura das Classes

Propriedades estáticas
Propriedades públicas
Propriedade privadas
Construtores estáticos
Construtor
Métodos estáticos
Métodos públicos
Métodos privados
Métodos de instâncias ordenadas de maior para menor importância
Getter e Setter

Bônus

Sempre que você estiver desenvolvendo algo, pense se seu código é DRY ou WET.

Mas, o que é o DRY e WET?

DRY é Don’t Repeat Yourself (traduzindo, não se repita), cujo o objetivo é reduzir a repetição de código. É importante lembrar de:

Evitar duplicidade de código
Simplificar sempre
Centralizar processos

Vantagens do uso do DRY:

Manutenibilidade
Código limpo de fácil leitura.
Reuso do código sem a necessidade de ficar duplicando.
Custo, tendo uma qualidade de código, não teremos custo com outras pessoas, pois quanto mais código, mais bugs e manutenção são necessárias.
Usar o DRY, raramente terá a necessidade de refatoração.

WET é Write Everything Twice (traduzindo, escreva tudo duas vezes), que é o oposto do DRY, é o código que não aplica os princípios do DRY.

Code Smells

Compreender o que é um code smell é fundamental para termos um código rodando em perfeitas condições.

Mas o que é um Code Smell?

Vamos lá, traduzindo code smell, temos cheiro de código, isso quer dizer que dependendo do cheiro do seu código, temos um problema. Code smell, nada mais é do que uma metáfora que indica bem o problema, sendo fácil de detectar se o código está com um bom ou mau cheiro, principalmente para bons farejadores de cheiros, ou melhor, bons desenvolvedores que estão sempre atentos à qualidade do código. Se temos um mau cheiro, YOU’RE CODE ARE STUPID.

Definição da sigla STUPID:

S: SINGLETON

Contexto global.
Pode ser modificado a qualquer momento.
Não é rastreável.
Difícil de atestar devido sua localização.

T: TIGHT COUPLING (alto acoplamento)

Mudança em um módulo que pode provocar um efeito dominó, tendo que alterar vários pontos de outras classes, módulos, métodos etc.
Agrupamento de módulos, pode necessitar mais esforço e tempo, devido a quantidade de dependência entre eles.
Quando um único módulo mostra ser mais difícil de usá-lo, prova-se que devemos incluir módulos independentes.

U: UNTESTING (código sem teste)

Código de alta complexidade.
Código com muita dependência.
Dependências globais (Singleton).
Os testes fazem parte do desenvolvimento do software, a falta deles são um problema.

P: PREMATURES OPTIMIZATION (otimizador prematuro)

Não antecipar os requisitos e abstrações desnecessárias, isso pode gerar complexidade acidental (quando implementamos uma solução complexa ao mínimo).

I: INDESCRIBABLE NAMES

Variáveis mal nomeadas.
Nomes de classes genéricos.
Nomes de funções mal colocados.

D: DUPLICATE (duplicar código, não aplicar o DRY)

O não uso do DRY
Código idêntico que cumpre a mesma função aumentando a probabilidade de erro humano.
Mudar uma função que é usado em vários pontos do código, tendo efeito dominó e, consequentemente, tendo que alterar as outras funções que fazem parte da função alterada.

Extra:

Um método enorme com mais de 30 linhas, podemos quebrá-lo em sub-métodos onde cada um faz uma operação específica.
Classes enormes com muitas funções/métodos, podemos quebrá-las também em sub-classes que fazem a mesma operação.
Evite dependência de código, cada classe faz o seu, cada uma tem sua responsabilidade.
Quando um método de uma classe, faz muita referência a outros métodos de outras classes, devemos considerar que o desenvolvimento não foi tão bom e
temos que refatorar.
Classes bem desenvolvidas, devem saber que quanto menos dependência de outras classes, é mais fácil de manter e utilizar.
Uma classe com uma única responsabilidade que chama métodos de outra classe, não devem existir.

Conclusão:

O uso do Clean Code (traduzindo, Código Limpo) e todas as suas técnicas como DRY, WET e Code Smells são essenciais. Em um desenvolvimento de software independente se é uma simples função, uma classe, um método, um módulo ou um projeto (exclusivamente se for um iniciado do zero) desenvolvido com clean code seguindo os passos deste artigo sua entrega terá boa qualidade, será compreensível para uma revisão de código, escalável, exemplo para outros desenvolvedores e terá o alcance de objetivo. Além de ser uma das boas práticas de programação, é possível ter uma garantia de que você entregou um código
bom e legível ao cliente, e que não haverá falhas pois foi desenvolvido com testes. Importante mencionar que um código bem escrito não terá uma interpretação equivocada ao ser lido, e terá facilidade em fazer possíveis melhorias e manutenção ou adaptações futuras de um software.

Fontes:

Todo o material escrito neste artigo, foi inspirado no aprendizado do curso de Principios de SOLID e Clean Code: https://www.udemy.com/share/106hO43@5VQywKJy71arup4ZxdSNGV0I8_XVLKMvqr93zdhiohFVhRIT5SFFquUB4MCsUQ9A/
Para mais informações da definição de Code Smell, acesse: https://coodesh.com/blog/dicionario/o-que-e-code-smell/
Para mais informações sobre DRY ou WET, acesse: https://dzone.com/articles/is-your-code-dry-or-wet