PILARES DO CLEAN CODE

LEGIBILIDADE 📝

Um código deve ser legível por outros programadores, como um livro. Nós somos os autores e nossa equipe são os leitores. Se o código não é legível, a equipe terá dificuldade para entender e dar manutenção.

ESCALABILIDADE 📈

Para obter um software escalável, é essencial respeitar os princípios do Clean Code. Um código bem estruturado e organizado facilita o crescimento e a adaptação do software às novas necessidades.

MANUTENIBILIDADE 🔧

Um código bonito e organizado de nada adianta se não for fácil de manter. Para alcançar esse estado, é preciso seguir os seguintes preceitos:

1. Modularidade: Divida o código em módulos independentes.
2. Comentário e Documentação: Documente funções e classes para facilitar a manutenção.
3. Refatoração Regular: Revise e melhore o código continuamente.

CONFIABILIDADE ✅

O código precisa ser confiável para que outros programadores possam dar suporte a ele. Para isso, é importante seguir boas práticas de programação e garantir que o código esteja livre de bugs e vulnerabilidades.

TESTABILIDADE 🧪

Para ajudar na manutenção e confiabilidade, é crucial desenvolver testes:

• E2E (End-to-End): Testa a aplicação de ponta a ponta.
• INT (Integration): Testa a integração entre diferentes partes do sistema.
• UNIT: Testa unidades individuais de código.

PREVISIBILIDADE 🔍

O código deve ser previsível e sem efeitos colaterais. Por exemplo, uma função que cria um usuário não deve, ao mesmo tempo, criar um token. Funções devem fazer uma única coisa e bem.

Clean Code no Código

Nomenclatura de Variáveis 🏷️

• Sempre em inglês
• Sempre descritiva
• Explique por que existe, como usar e o que retorna.
• Classes são substantivos e funções são verbos.

Exemplo:

Enviar notificação ao autor do post:

• Classe: Author
• Função: SendNotificationToAuthorPost

Seguindo esses pilares, garantimos que nosso código seja mais fácil de ler, manter e escalar, além de ser confiável e testável. A prática contínua dessas técnicas nos ajuda a nos tornarmos melhores desenvolvedores e a produzir software de alta qualidade.

booleanos

uma ideia interesante dos boleanso é deixalos eles com sufixos e palavras chaves como : is, has, does, not ,have como se fosse uma sentença e se completasse com if

good example

if(user.is_authenticated){
    //altas coisas
}

if(hasATicket){
    //altas coisas
}

if(isParkOpen){
    //altas coisas
}

if(isAllowed){
    //altas coisas
}

bad example

if(authenticated){
    //altas coisas
}

if(ticket){
    //altas coisas
}

if(park){
    //altas coisas
}

if(allowed){
    //altas coisas
}

SOLID

5 preceitos famosos na programação para elevar a escabilidade e desenvolvimento do nosso software

S (single of responsibility principle)

principio nda responsabilidade unica , uma classe,função,modulo,arquivo... deve fazer somente uma coisa e deve cumnprir isso de forma perfeita

class GetOrderDiscount {
    execute(amount: number) {
        //altas coisinhas aqui
    }
}

O (open of closed responsibility principle)

principio de aberto e fechado , diz que uma uma classe,função,modulo,arquivo...deve estar ffechada para alteração e aberta para extenção

fechada para alteração

interface PaymentMethod {
    getDiscount(amount: number): number;
}

class GetOrderDiscount {
    execute(
        amount: number, 
        paymentMethod: PaymentMethod) {
        return this.paymentMethod.getDiscount(amount);
    }
}

aberto para extenção

class PaymentByDebit implements PaymentMethod {
    getDiscount(amount: number) {
        return amount * 0.05;
    }
}

class PaymentByBillet implements PaymentMethod {
    getDiscount(amount: number) {
        return amount * 0.1;
    }
}

execução:

const getOrderDiscount = new GetOrderDiscount()

getOrderDiscount.execute(1000, new PaymentByDebit())

L (liskov substitution responsibility principle)

principio da substituição de classe diz que deve ser possivel alterar as denpendencias de uma determinada funcionalidade sem alterar seu resultado respeitando assim tambem o O do SOLID

exemplo

tendo em mente o código acima do open closed principal

const getOrderDiscount = new GetOrderDiscount()

getOrderDiscount.execute(1000, new PaymentByDebit())
getOrderDiscount.execute(1000, new PaymentByBillet()) 

I (interface segregation responsibility principle)

responsabilidade da segregação de interfaces diz que devemos dividir interface para melhor modularização de expectativas de certas interfaces, isso ajuda evitar campos opcionais

exemplo

interface PaymentMethod {
    getDiscount(amount: number): number;
}

interface PaymentCredit {
    number: number;
    expires: number;
    installments: number;
}

class PaymentByCredit implements PaymentMethod, PaymentCredit {}

D (dependency inversion responsibility principle)

responsabilidade de inverção de dependencias diz que nossa :classe,função,modulo,arquivo... deve ter suas dependecias inferidas na hora de execução , se conecta muito com L e O do SOLID

exemplo

class GetOrderDiscount {
    private paymentMethod: PaymentMethod;

    constructor(paymentMethod: PaymentMethod) {
        this.paymentMethod = paymentMethod;
    }

    execute(amount: number) {
        return this.paymentMethod.getDiscount(amount);
    }
}