Clean Code, para que serve?

Clean Code

As técnicas do Clean Code apareceram pela primeira vez no livro “Clean Code: A Handbook of Agile Software Craftsmanship“, lançado em 2008.

Ele conseguiu perceber que o gargalo principal no desenvolvimento de software estava justamente na manutenção.

E um dos motivos pode ser justificado no seguinte dado: a proporção média de leitura e escrita de códigos fonte é de 10 para 1. Isso significa que as pessoas passam mais tempo tentando entender os códigos existentes do que efetivamente escrevendo novos códigos.

Basicamente clean code é aplicar determinadas técnicas para facilitar a escrita e leitura de um código.

Se você é desenvolvedor há algum tempo ou iniciou faz pouco já deve ter entrado em uma empresa onde o código do sistema era tão bagunçado que você se sentia perdido, e com o tempo você acha que vai melhorar mas quando o tempo passa parece que esta no começo e você continua sem entender como as coisas funcionam, você só sabe que funciona, parece que cada um programa as coisas de forma aleatória, classes gigantescas com milhares de linhas de código, e muitas vezes só uma pessoa sabe mexer nessa classe gigante causando assim um gargalo no desenvolvimento e um gargalo pra ele próprio que vai ter que ficar anos dando manutenção em um código legado gerando uma grande insatisfação.
As classes não surgem no sistema com mais de 1000 linhas do nada, é um dia apos o outro escrevendo código e quando passa de um determinado ponto não tem mais volta pois a complexidade foi acumulada, não tem testes, duplicação de código, sem padrões, mexe em um arquivo e da bug do ouro lado, medo do deploy na sexta-feira...
Tudo isso gera custo porque qualquer botão a mais vai ser uma dificuldade tremenda.
Se o time ou a empresa ou o gerente acha que qualidade de código é besteira, esta perdendo dinheiro, o tempo de manutenção fica alto, o dev passa mais tempo procurando/analisando do que realmente desenvolvendo e isso gera insatisfação, se a demanda do time de suporte esta alta o time de desenvolvimento esta faltante.
Qual a métrica para medir a qualidade do código? é quando você abre seu editor, se você xingar quem fez aquilo é porque a qualidade ta ruim...
Uma boa maneira de começar a escrever código de qualidade utilizando os princípios do clean code é fazendo pair programming, assim você tem menos interrupções e por consequência se concentra mais, com isso você aumenta a qualidade, compartilha conhecimento, faz nivelamento técnico.

Chega de lero lero, abaixo estão os princípios do clean code:

Regra do escoteiro

Há um princípio do escotismo que diz que, uma vez que você sai da área em que está acampando, você deve deixá-la mais limpa do que quando a encontrou.

Trazendo a regra para o mundo da programação, a regra significa deixar o código mais limpo do que estava antes de mexer nele.

Regras de design

Mantenha dados de configuração em alto nível

Tente sempre deixar estas configurações ou o parse delas em um nível mais alto possível.

Evite sobrescrever configurações em métodos dentro de Controllers ou algo do tipo.

Polimorfismo no lugar de IFs

Um IF ou condicional, como o nome diz, traz uma tomada de decisão a nossa aplicação, o que implica no aumento da complexidade da mesma. No geral devemos evitar o uso excessivo destes.

Evite configurações desnecessárias

Utilize injeção de dependência

Sempre que possível utilize injeção de dependência, ele vai tornar seu código mais limpo e desacoplado.

Lei de Demeter

A Lei de Demeter (LoD) ou princípio do menor conhecimento é um princípio que prega os seguintes pontos.

• Cada unidade deve ter conhecimento limitado sobre outras unidades: apenas unidades próximas se relacionam.
• Cada unidade deve apenas conversar com seus amigos.
• Não fale com estranhos, apenas fale com seus amigos imediatos

Regras sobre entendimento do código

Seja consistente

Se você executa algo de uma forma, execute todo o resto desta mesma forma. Seja consistente na forma com que aplica o código. Siga sempre o padrão definido.

Utilize variáveis concisas

Opte por variáveis concisas, mesmo que resultem em um nome maior. Elas devem ser auto-explicativas, sem a necessidade de comentários ou informações adicionais.

Obsessão primitiva

No dia-a-dia tendemos a nos focar apenas em tipos primitivos (Built-in), causando uma obsessão pelos mesmos. Podemos criar e usar objetos de valor (Value Objects) para suprir melhor esta necessidade.

Evite dependências lógicas

Não escreva métodos cujo funcionamento correto dependa de algo contido em sua classe.

class Student 
{
    public IsSubscriber: boolean; 

    public Xpto(): void 
    {
        if(this.IsSubscriber)
            ... // Só executa se for assinante   
    }
}

Evite condicionais negativas

A negação é dada por um sinal de exclamação (!) que muitas vezes pode ser imperceptível, ocasionando na má leitura do código.

Regras de nomes

Escolha nomes descritivos

Esolher bons nomes para classes, variáveis e métodos é essencial para um código limpo.

Faça distinções significantes

Utilize sempre nomes nos quais quem estiver lendo seu código possa diferenciar seu significado de outros possíveis nomes.

Utilize nomes pronunciáveis e buscáveis

Evite utilizar nomes difíceis de pronunciar ou inventar nomes e conveções para variáveis, classes e métodos. Lembre-se sempre da linguagem ubíquoa e da importância dela no código.

Evite uso excessivo de strings

Quem nunca perdeu horas procurando um BUG que era apenas um problema de comparação de string? Evite digitar a mesma string várias vezes, utilize constantes para isto.

Não use prefixo ou caracteres especiais

Não utilize prefixo com o tipo da variável, classe ou método e NUNCA use espaços ou caracteres especiais nestes itens.

// Evite
class clsCustomer { ... }

// Evite
const strNome: string = "Fulano";

Regras para funções ou métodos

Pequenas e com apenas um objetivo

Mantenha suas funções ou métodos o menor possível. É mais fácil ter métodos menores e reutilizáveis do que tudo dentro de um método só.

Opte por poucos parâmetros

Cuidado com efeitos colaterais

Evite que uma função altere valores de outra classe sem ser a dela. Isto é chamado de efeito colateral(side effect).

Não tome decisões desnecessárias

Não utilize os famosos "flags" para tomar decisões dentro dos métodos, divida-os em vários métodos ou até mesmo outras classes.

// Evite
class UserRepository 
{
    public CreateOrUpdate(user: User, create: boolean): Promise<User>
    {
        if(create)
            ...
        else
            ...
    }
}

Regras de comentários

Um código bom é expressivo

Teoricamente, se você precisa comentar uma parte do seu código, é por que algo está errado com ele, ele não está expressivo o suficiente.

Não seja redundante

Evite comentários que não fazem sentido algum ao contexto ou cenário.

Não feche os comentários

Não há necessidade de fechar os comentários. como se fosse tag

// Evite

// Comentário // <- Desnecessário
public execute() { ... }

Evite códigos comentados

Não deixe sujeira em seu código, ao invés de deixar algo comentado, remova ele. Hoje temos versionadores de código, você pode "voltar no tempo" facilmente.

Estrutura do código

Separe conceitos verticalmente

Mantenha uma estrutura de pastas saudável e organizada. Não precisa criar uma pasta para cada arquivo, mas pode haver uma separação por contexto ou feature.

Declare variáveis próximas de seu uso

Não crie todas as variáveis juntas, no começo da class ou método, defina-as próximas de onde serão utilizadas.

// Utilize
public CreateCustomer(): void { ... }

public CreateOrder(): void { ... }

public UpdateCustomer(): void { ... }

let total = 0;
public CalculateTotal(): void
{ 
    total = 250;
}

Agrupe funcionalidades similares

Se uma função pertence a um grupo dentro de um objeto, mantenha-as sempre por perto.

Declare funções de cima para baixo

Ordenar as funções também é importante. Além da sua ordem de grandeza, suas assinaturas também devem ter uma boa oganização.

Mantenha poucas e curtas linhas

Evite funções com linhas longas ou muitas linhas. Não existe um número correto, mas com certeza quanto mais código em uma função, mais difícil de mantê-la será.

Não use alinhamento horizontal

// Evite
const user     = 'fulano'
const userName = 'ciclano'

Use os espaços em branco corretamente

Utilize espaço em branco para associar ou não itens relacionados. Uma boa IDE já fará este trabalho por você.

Não quebre a identação

Testes

Um assert por teste

Utilize um e apenas um assert por teste. Mais de um assert pode confundir você e comprometer a escrita do seu teste.

Legível

Trate seus testes como parte fundamental do seu código, não secundária. Os testes tem que ser organizados e bem escritos assim como o resto do seu software.

Independentes

Os testes não devem depender de entidades externas, nem de outros testes. Neste exemplo, volto a salientar o uso do DI e DIP.

Repetitível

Devemos ter a possibilidade de repetir o mesmo teste, mas com parâmetros diferentes.

Links Pesquisados
https://balta.io/blog/clean-code
https://www.hostgator.com.br/blog/clean-code-o-que-e/
https://www.sydle.com/br/blog/clean-code%20-602bef23da4d09680935509b/