DEV Community: Leonardo Bonetti

SOLID com Typescript: O resumo completo com exercícios

Leonardo Bonetti — Tue, 01 Nov 2022 13:28:26 +0000

O que aprenderemos hoje?

Neste artigo, você conhecerá um conjunto de 5 princípios (S.O.L.I.D) fundamentais para o desenvolvimento de um sistema de fácil manutenção, extensão, incorporação e principalmente, compreensão.

Requisitos necessários

Para total aproveitamento do conteúdo a seguir, é indicado que você conheça o paradigma de programação orientado a objetos e tenha noções de herança e polimorfismo.

Antes de começarmos...

É muito importante entendermos primeiramente o que é Arquitetura de software, para isso, gosto de fazer um paralelo com a Arquitetura Civil, já que está em nosso dia a dia desde sempre e podemos identificar de forma rápida ao entrarmos em um ambiente bem-planejado que este foi projetado por um arquiteto, nos impressionamos com cada canto bem aproveitado, a disposição das luzes e elementos pelas paredes, assim como a conveniência de diversos recursos como pontos de energia e iluminação em cada lugar que podem se apresentar necessários. Ao viver em um ambiente como o descrito, percebemos que acima da beleza, o valor de sua obra está em sua utilidade; O mesmo acontece com sistemas computacionais, se você vai passar meses ou anos trabalhando em um determinado sistema, você vai querer que ele tenha sido em primeiro lugar bem projetado e como um bom desenvolvedor, seu papel é mantê-lo assim, independentemente do quanto ele cresça.

Como qualquer metáfora, descrever software por meio das lentes da arquitetura pode esconder tanto quanto pode revelar, pode prometer mais do que entregar e entregar mais do que o prometido.
O apelo óbvio da arquitetura é a estrutura, que domina os paradigmas e discussões sobre o desenvolvimento de software - Componentes, classes, funções, módulos, camadas e serviços, micro ou macro. No entanto, muitas vezes, é difícil confirmar ou compreender a estrutura bruta de vários sistemas de software - esquemas corporativos ao estilo soviético em vias de se tornarem legado, improváveis torres de equilíbrio se estendendo em direção a nuvem, camadas arqueológicas enterradas em um slide que parece uma imensa bola de lama. Pelo jeito, a estrutura de um software não é tão intuitiva quanto a de um prédio.
(MARTIN, R.C. Arquitetura limpa: O guia do artesão para a estrutura e design de software. [S.l.]: ALTA BOOKS, 2019.)

Na arquitetura civil existem limitações físicas que impedem os profissionais de realizarem certas ações, porém no mundo virtual os limites podem não ser tão claros, assim como Robert C. Martin descreve no trecho acima. Os paradigmas de programação vêm então com mais uma proposta do que não devemos fazer do que o que devemos fazer, escolher um paradigma é escolher os limites que o mesmo impõe, se você escolher o paradigma orientado a objetos, o SOLID é uma adição muito bem-vinda a esses limites.

Vamos aos SOLID

O SOLID foi apresentado por Robert C. Martin em um artigo dos anos 2000 com o título "Postulados de Projeto e Padrões de Projeto", mas onde ele realmente brilhou foi em seu livro "Arquitetura Limpa", por isso será citado diversas vezes neste conteúdo.

SRP (Single Responsibility Principle)

Um corolário ativo da lei de Conway: A melhor estrutura para um sistema de software deve ser altamente influenciada pela estrutura social da organização que o utiliza, de modo que cada módulo de software tenha uma, e apenas uma, razão para mudar.
(MARTIN, Arquitetura limpa. página 102)

Você está desenvolvendo um sistema de lembretes para a Apple e se depara com a seguinte classe:

class Reminder {
    public content: string;
    public id: string;
    public date: Date;
    ...

    constructor(private readonly db: Database) {}

    ...
    public async getTags() {
        let tokens = this.content.split(" ")
        return tokens.filter(t => t[0] === "#")
    }
    public async store() {
        this.db.create({content: this.content, id: this.id, date: this.date})
    }
}

Para olhos mal treinados, pode não ter nada de errado aqui, nossa classe de lembrete tem uma funcionalidade para salvar em um banco de dados e outra para retornar as hashtags do content.
Retornar as tags é uma responsabilidade única e exclusiva dos lembretes, mas salvar um conteúdo em um banco de dados não é.
Aqui temos o caso clássico de que se existe uma ação disponível a uma entidade, essa entidade deve implementar essa ação, isso esta completamente errado, pois dezenas de outras entidades podem precisar salvar seus conteúdos no banco de dados e se por algum motivo nossa implementação do banco mudar da função CREATE para SET, por exemplo, teríamos de alterar todas essas entidades, então para corrigir isso, vamos ver o exemplo abaixo:


class Reminder {
    public content: string;
    public id: string;
    public date: Date;

    ...
    public async getTags() {
        let tokens = this.content.split(" ")
        return tokens.filter(t => t[0] === "#")
    }
}

class Storage {
    constructor(private readonly db: Database) {}

    public async storeReminder(data: Reminder) {
        this.db.create(data)
    }
}

Agora temos uma nova classe chamada Storage, ela é a responsável por salvar objetos no banco, caso dezenas de classes precisem utilizar este recurso é a classe Storage quem vai lidar com isso, assim, o único motivo para Storage mudar é se mudarmos a implementação do banco de dados e o único para Reminders mudar é se mudarmos as regras de tags.

Existe uma confusão muito comum quando falamos do princípio da responsabilidade única, que muitos desenvolvedores acreditam que uma classe deve fazer apenas uma única coisa e isso também está completamente errado, uma classe deve ter apenas um motivo para mudar e isso significa que deve atender a uma única regra de um determinado ator (ator é quem interage com o sistema, podendo ser um usuário, administrador, outro sistema, stakeholder ou até mesmo outras classes.)

Sintomas do descumprimento SRP

Duplicação Acidental

Digamos que a Apple te pediu para fazer um sistema de cálculo de horários, onde o RH e o financeiro serão os clientes, então você escreve o seguinte código:

class Admin {
    calculateWorkHours() {}
}
class RH extends Admin {}
class Financial extends Admin {}

Depois de pronto, o sistema começa a dar problemas, por que o RH considera horas trabalhadas o horário que o funcionário entrou e saiu da empresa, enquanto o financeiro considera apenas o horário que ele ficou no computador, desconsiderando as pausas, se você alterar a classe admin, um dos dois times será afetado. Para resolver esta questão você precisa reimplementar as funções da seguinte forma:

class Admin {
    ...
}
class RH extends Admin {
    calculateWorkHours()
}
class Financial extends Admin {
    calculateWorkHours()
}

Nesse caso, fizemos o oposto da classe de lembretes, já que o cálculo de horas é de responsabilidade única de cada um dos atores

Fusões

Sabe quando você trabalhou dias em uma determinada funcionalidade para seu sistema e com o trabalho pronto, finalmente abre um pull request para anexá-lo a branch principal, mas recebe aquela mensagem super desagradável de um conflito que o impede?
Pois é, na maioria dos casos isso acontece quando o SRP não é respeitado, sendo assim existe uma classe que atende a mais de um ator do sistema, e são eles quem definem as tarefas, ou seja, mais de um desenvolvedor pode ser solicitado a realizar alterações/adições nesse módulo, e quando isso acontece, na hora de anexar a atividade, se depara com este conflito.

O Princípio da Responsabilidade Única visa simplesmente reduzir ao máximo a necessidade de alterar uma determinada classe e que alterações em terceiros não reflitam em outras classes.

OCP (Open-Close Principle)

Bertrand Meyer popularizou este princípio na década de 1980. Em essência, para que os sistemas de software sejam fáceis de mudar, eles devem ser projetados de modo a permitirem que o comportamento desses sistemas mude pela adição de um novo código em vez da alteração do código existente. (MARTIN, Arquitetura limpa. página 103)

Vamos utilizar a resolução do SRP com a classe Reminder e Storage e adicionando uma nova classe para entendermos melhor esse conceito.


// Nova classe
class Note {
    public content: string;
    public id: string;
    public date: Date;

    ...
    public Increment(data: string) {
        this.content += data
    }
}

class Reminder {
    public content: string;
    public id: string;
    public date: Date;

    ...
    public async getTags() {
        let tokens = this.content.split(" ")
        return tokens.filter(t => t[0] === "#")
    }
}

class Storage {
    constructor(private readonly db: Database) {}

    public async storeReminder(data: Reminder) {
        this.db.create(data)
    }

    // Alteração necessária
    public async storeNote(data: Note) {
        this.db.create(data)
    }
}

A Apple pediu que você adicionasse uma nova funcionalidade ao sistema de Lembretes, agora os usuários podem criar notas que podem ser incrementadas a qualquer momento, por isso, a mesma possui uma função chamada Increment, assim como Reminder, o conteúdo da classe Note também pode ser armazenado no banco de dados, por isso, criamos mais uma função na classe Storage para fazer tal tarefa.
Aqui criamos uma funcionalidade para nosso sistema (class Notes) e alteramos uma já existente (class Storage), vamos ver o que Martin tem a dizer sobre isso:

Um artefato de software deve ser aberto para extensão, mas fechado para a modificação. Em outras palavras, o comportamento de um atefato de software deve ser extensível sem isso modificar esse artefato. (MARTIN, Arquitetura limpa. Página 114)
Bom, agora está claro que o problema está na classe Storage, porque toda a vez que incrementarmos nosso sistema para alguma entidade que precise ser armazenada em um banco de dados, vamos precisar alterar o storage, e isso mostra a importância desse princípio, você já deve ter visto ou ouvido falar de sistemas tão grandes e legados, que quanto mais ele cresce, mais os desenvolvedores demoram para implementar novas funcionalidades.
Evidentemente, essa é a principal razão de estudarmos arquitetura de software. De forma clara, quando extensões simples nos requisitos forçam mudanças massivas no software, os arquitetos desse sistema de software estão em meio a um fracasso espetacular. (MARTIN, Arquitetura limpa. Página 115)
Vamos tentar resolver esse problema:

// Nova interface
interface CanStore {
    getContent(): {id: string, content: string, date: Date}
}

class Note implements CanStore {
    public content: string;
    public id: string;
    public date: Date;

    ...
    public Increment(data: string) {
        this.content += data
    }

    public getContent() {
        return {content: this.content, id: this.id, date: this.date}
    }
}

class Reminder implements CanStore {
    public content: string;
    public id: string;
    public date: Date;

    ...
    public async getTags() {
        let tokens = this.content.split(" ")
        return tokens.filter(t => t[0] === "#")
    }

    public getContent() {
        return {content: this.content, id: this.id, date: this.date}
    }
}

class Storage {
    constructor(private readonly db: Database) {}

    public async store(data: CanStore) {
        this.db.create(data.getContent())
    }
}

Criamos então uma interface que tem de ser respeitada por qualquer entidade que queira armazenar seus dados no banco (interface CanStore) - em muitas literaturas sobre SOLID você vai se deparar com o autor falando que pedaços de software têm de assumir um contrato, e por contrato no typescript estamos falando de interfaces e assumir o mesmo, estamos nos referindo a implementá-las - que possui uma única função chamada getContent com um retorno definido por um conteúdo que é uma string, um identificador único que é um ID e uma data que é um Date, assim qualquer classe que queira ser compatível com Storage precisa apenas implementar essa interface e criar a função de forma que o retorno seja compatível com o esperado, assim, qualquer nova implementação no sistema não precisará alterar a classe Storage e pode crescer de maneira simples sem necessidade de alterações em outros módulos.
Vamos ver se isso realmente funciona com mais um exemplo:
A Apple agora pediu para você criar uma funcionalidade onde o usuário pode adicionar links com comentários, então criamos a seguite funcionalidade:

interface CanStore {
    getContent(): {id: string, content: string, date: Date}
}

// Nova funcionalidade
class Links implements CanStore {
    public link: string;
    public coment: string;
    ...
    public getContent() {
        return {content: this.coment, id: this.link, date: new Date()}
    }
}

class Note implements CanStore {
    public content: string;
    public id: string;
    public date: Date;

    ...
    public Increment(data: string) {
        this.content += data
    }

    public getContent() {
        return {content: this.content, id: this.id, date: this.date}
    }
}

class Reminder implements CanStore {
    public content: string;
    public id: string;
    public date: Date;

    ...
    public async getTags() {
        let tokens = this.content.split(" ")
        return tokens.filter(t => t[0] === "#")
    }

    public getContent() {
        return {content: this.content, id: this.id, date: this.date}
    }
}

class Storage {
    constructor(private readonly db: Database) {}

    public async store(data: CanStore) {
        this.db.create(data.getContent())
    }
}

Percebam que adicionamos apenas a classe Links e formatamos o retorno da função getStorage, sem precisar mexer em mais nenhum lugar do sistema!

O OCP é uma das forças motrizes por trás da arquitetura de sistemas. Seu objetivo consiste em fazer com que o sistema seja fácil de estender sem que a mudança cause um alto impacto. Para concretizar esse objetivo, particionamos o sistema em componentes e organizamos esses componentes em uma hierarquia de dependência que proteja os componentes de nível mais alto das mudanças em componentes de nível mais baixo. (MARTIN, Arquitetura limpa. Página 115)

Adicionar a função getContent em todas as classes não fere o princípio SRP (de responsábildiade única)?
Não, pois armazenar o dado no banco continua sendo tarefa única e exclusiva da classe Storage, mas a formatação dos dados para ir até o Storage é de responsábilidade de cada classe que implementa CanStore, afinal de contas, cada uma terá um tipo de dado diferente que será traduzido para o formato de getContent, como a tradução será feita é responsabilidade de cada classe.

O princípio do OCP visa simplesmente prevenir a criação de sistemas super dependentes onde no inicio é muito simples implementar uma feature, mas com o passar do tempo, por mais simples que seja, novas funcionalidades se tornam uma baita dor de cabeça.

Sintomas do descumprimento

O principal sintoma do descumprimento do OCP são sistemas de difícil manutenção e evolução, é uma regra tão comumente ignorada que não é raro encontrarmos empresas que sofrem com o orçamento e o tempo para evoluírem seus sistemas, isso cria uma necessidade constante de refatoração.

Um sistema que precisa ter módulos refatorados não é necessariamente um sistema com uma arquitetura ruim, mas se essa necessidade se torna constante, temos uma prova de que um dos principais princípios do SOLID foi ignorado.

Os resultados disso no ponto de vista comercial são terríveis, pois o dinamismo do mercado é alto, sendo assim, a direção do negócio precisa ter um prazo ótimo para acompanhar suas mudanças e aproveitar oportunidades, se o cerne da empresa é a tecnologia, essa carga é passada diretamente a seus desenvolvedores e sem uma boa arquitetura fica cada vez mais inviável realizar as implementações necessárias, até que a empresa colapsa por conta de o orçamento ter de ser constantemente expandido até o momento em que se torna mais caro realizar implementações no sistema do que o retorno que as mesmas trazem.

Para qualquer empresa que dependa de tecnologia, a arquitetura de sistemas é um tópico que pode colocá-la a frente de sua concorrência ou até mesmo acabar com elas, e como dito por Robert C. Martin "O OCP é uma das forças motrizes por trás da arquitetura de sistemas".

LSP (Liskov Substitution Principle)

Para cada objeto o1 de tipo S, houver um objeto o2 de tipo T, de modo que, para todos os programas P definidos em termos de T, o comportamento de P não seja modificado quando o1 for substituído por o2, então S é um subtipo de T. (MARTIN, Arquitetura limpa. Página 123)

Essa definição do LSP feita por sua criadora, Barbara Liskov, pode muitas vezes confundir mais do que esclarecer, então vamos tentar repensar da seguinte forma:
"Classes que herdam funcionalidades de outras classes de nível mais baixo, devem conseguir utilizarem as funcionalidades da de nível inferior sem necessariamente conhecer ou alterar seu comportamento."

Para entendermos a definição anterior, vamos olhar novamente nossa classe de contagem de horas:

class Admin {
    ...
}
class RH extends Admin {
    calculateWorkHours() {}
}
class Financial extends Admin {
    calculateWorkHours() {}
}

As classes de RH e Financial tem suas próprias funções para calcular as horas de trabalho de cada funcionário e isso está certo pelo princípio de Liskov, mas vamos imaginar que para solucionar aquele problema do cálculo diferir do RH para o Financeiro, o desenvolvedor responsável decide fazer a seguinte implementação

class Admin {
    ...
    calculateWorkHours() {}
}
class RH extends Admin {}

class Financial extends Admin {
    calculateWorkHours() {}
}

No caso, o método original definido na classe Admin atendia ao RH, mas quando foi necessário que o financeiro fizesse uma conta diferente, ele simplesmente herdou a classe Admin e reescreveu a função de calcular horas, fazendo o famoso overriding super class method. Isso fere a definição acima, pois a classe Financial está estendendo Admin e não utilizando o único método útil para ele (calculateWorkHours), então literalmente não faz sentido estender Admin, pois estamos alterando sua lógica.
Voltando a nossa definição, o caso correto de se estender Admin está na classe RH, pois ela não precisa conhecer a lógica usada em calculateWorkHours do Admin, ela simplesmente sabe que o método retorna um número e isso é suficiente para ela, ou seja, RH é um subtipo correto de Admin.

Então segundo o princípio de Liskov, sempre está errado sobrescrever um método da classe que você estende?
Não, pois se Financial estivesse utilizando mais de um método de Admin da forma correta e o único caso que ele precise mudar está na função calculateWorkHours, então, tudo bem segundo Liskov, mas isso vai ferir outro princípio (ISP) que veremos a seguir.

Sintomas do descumprimento

Para entendermos ainda melhor o princípio de Liskov, vamos a um exemplo um pouco mais próximo ao que Robert C. Martin propõe:

Digamos que você criou um gateway de pagamentos sensacional, onde qualquer um que tenha um sistema que necessite receber notificações sobre transações em sua conta realiza o cadastro em seu sistema e adiciona um link para receber as notificações de movimentação em sua conta, como um WebHook.
Um dia, um investidor da sua empresa chamado Alan contrata uma equipe de desenvolvedores para criar um sistema que se integra ao seu. Após finalizada a integração eles alegam que o sistema não funciona e explorando melhor o caso, você percebe que não leram sua documentação e o sistema do cliente espera receber campos na requisição com nomes diferentes do que o seu sistema está programado.

Para ajudar, você decide criar uma classe especial apenas para disparar requisições a esse cliente em específico:

A classe Dispatch que faz as requisições
Você cria uma classe DispatchToAlan que é um subtipo de Dispatch porem altera o nome dos campos de envio. Bom, isso se resolve facilmente com um if certo? Sim, se resolve apenas com uma simples condicional, mas imagine que sua empresa comece a atrair cada vez mais investidores e de novo esse problema se repete, como você abriu um precedente com o desenvolvedor anterior, começa a criar cada vez mais subtipos de Dispatch para atender as necessidades de novos clientes.

Aqui podemos tirar algumas conclusões, a primeira é que sua documentação deve estar horrível para que ninguém entenda e programe os campos com os nomes corretos para o recebimento, mas pior ainda, é que nenhum dos Subtipos de Dispatch que você está criando é válido, pois todos eles precisam alterar a lógica da classe original para atender aos clientes.

Isso fere gravemente o princípio do OCP, pois como esses subtipos de Dispatch alteram sua lógica em algum nível, se Dispatch for alterado por alguma razão, você pode precisar alterar todos esses subtipos, o que também fere o SRP, pois essas classes passam a ter mais de uma razão para mudar (Sendo elas a primeira que é válida, caso o seu cliente mude o tipo de recebimento e a segunda inválida, caso você mude o comportamento da classe original).

O LSP pode, e deve ser estendido ao nível da arquitetura. Uma simples violação da capacidade de substituição pode contaminar a arquitetura do sistema com uma quantidade significante de mecanismos extras. (MARTIN, Arquitetura limpa. Página 123)

ISP (Interface Segregation Principle)

Este princípio orienta que os projetistas de software evitem depender de coisas que não usam. (MARTIN, Arquitetura limpa. Página 103)

Sempre é melhor criarmos várias interfaces para diferentes implementações do que apenas uma generalista.

interface Admin {
    payEmployees(): void
    updateInfo(): void
    getLatestPayments(): Payments[]
    calculateWorkHours(): number
}
class RH implements Admin {
    payEmployees() {
        throw new Error("Function not available for this actor");
    }
    updateInfo() {
        // realiza a tarefa
    }
    getLatestPayments() {
        throw new Error("Function not available for this actor");
    }
    calculateWorkHours() {
        // realiza a tarefa
    }

}
class Financial implements Admin {
    payEmployees() {
        // realiza a tarefa
    }
    updateInfo() {
        throw new Error("Function not available for this actor");
    }
    getLatestPayments() {
        // realiza a tarefa
    }
    calculateWorkHours() {
        // realiza a tarefa
    }
}

O que era nossa classe Admin se tornou uma interface a ser implementada, e essa interface declara que Administradores podem pagar funcionários, atualizar suas informações, buscar os últimos pagamentos e calcular suas horas de trabalho.
O problema aqui é que nem todos os Administradores podem realizar todas as tarefas, então no caso do RH, que não pode pagar funcionários ou buscar os últimos pagamentos, temos que disparar um erro caso a função seja chamada, o mesmo para o Financeiro que não pode atualizar as informações do profissional.
É sempre muito prejudicial depender de módulos que contenham mais do que você precisa, isso pode ocasionar bugs sérios em seus sistemas por uma falta de atenção de algum desenvolvedor que não sobrescreveu, além de problemas de segurança e muitas vezes ferir principalmente os princípios do OCP e SRP, por que, afinal de contas, se mais classes implementam Admin e você precisa alterar o Admin, vai precisar alterar as classes (que fere o OCP), ter muita coisa embarcada no Admin vai fazer com que ele tenha mais de um motivo para ser alterado (Já que vários atores o implementam e isso fere o SRP).

A solução para isso é a Segregação de interfaces, como diz o próprio nome do princípio:

    interface CanPay {
        payEmployees(): void
    }
    interface CanUpdate {
        updateInfo(): void
    }
    interface CanSearchPayments {
        getLatestPayments(): Payments[]
    }
    interface CanCalculate {
        calculateWorkHours(): number
    }

    class RH implements CanUpdate, CanCalculate {
        updateInfo() {
            // realiza a tarefa
        }
        calculateWorkHours() {
            // realiza a tarefa
        }
    }

    class Financial implements CanPay, CanSearchPayments, CanCalculate {
        payEmployees() {
            // realiza a tarefa
        }
        getLatestPayments() {
            // realiza a tarefa
        }
        calculateWorkHours() {
            // realiza a tarefa
        }
    }

Observem que dessa forma cada classe implementa apenas o que convém a ela, e além de tornar nosso código muito mais legível e intuitivo, o torna mais seguro, previne erros inesperados e que quebremos os princípios de OCP (não temos de alterar protocolos ou classes a cada nova implementação), SRP (cada classe implementa apenas o que é de sua única responsabilidade), e LSP (por não termos de sobrescrever funcionalidades).

Depender de algo que contém itens desnecessários pode causar problemas inesperados.

Sintomas do descumprimento

A dificuldade de compreensão de um sistema é um grave problema, pois o tempo de evolução do mesmo se torna muito maior e a curva de aprendizagem de novos desenvolvedores cresce com a complexidade desnecessária.
Depender de modulos desnecessários abre uma brexa de segurança muito grave, como podemos ver na citação abaixo:

Considere um arquiteto que está trabalhando em um sistema chamado S, em que deseja incluir o framework F. Agora, suponha que os próprios autores ligaram F a um banco de dados D específico. Então S depende de F que depende de D.
Agora, suponha que D contenha recursos que F não usa e que, portanto, não são essenciais a S. Qualquer mudança nesses recursos de D pode muito bem forçar a reimplantação de F e, por extensão, a reimplantação de S.
Pior ainda, uma falha em um dos recursos de D pode causar falhas em F e S. (MARTIN, Arquitetura limpa. Página 132)

DIP (Dependency Inversion Principle)

Segundo o princípio da inversão de dependência DIP, os sistemas mais flexíveis são aqueles em que as dependências de código-fonte se referem apenas a abstrações e não a itens concretos (MARTIN, Arquitetura limpa. Página 135)

Acredito que a definição de Martin para este princípio seja a mais direta e compreensível de todas, ainda mais para nós que trabalhamos com Typescript, e dado que já conhecemos todos os outros princípios, este será mais fácil, vamos ver o exemplo a seguir:


    class Storage {
        constructor(private readonly seq: Sequelize) {}

        public async store(data: CanStore) {
            this.seq.query(data.getContent())
    }
}

Aqui vemos que Storage é inicializado com Sequelize, que por sua vez é uma implementação concreta de interações com o banco de dados, que não está em nosso controle mudar, ou prevenir que a mesma mude.
Storage está em nossa regra de negócio (Domain), e o Sequelize está em nossa Infraestrutura (Infra), percebam que a Infra está apontando para Domain, e isso significa que nossa regra de negócio depende da nossa infraestrutura, isso é terrível, pois, a Domain é definido pelo cliente do sistema, é nossa regra base, se a tecnologia que usamos influencia nisso, então quer dizer que mudanças nessa tecnologia podem mudar nosso negócio, idealmente é nosso negócio que deve determinar as tecnologias a serem usadas e não depender delas.
O DIP nos ajuda a solucionar esse problema da seguinte forma:

Veja a codificação da figura acima:


    class DatabaseAdapter implements Database {
        constructor(private readonly seq: Sequelize) {}
        async set(data: Data): Promise<void> {
            // insere dados no banco
        }
        async get(id: string): Promise<DbReturn> {
            // busca dado pelo id
        }
    }

    interface Database {
        set(data: Data): Promise<void>
        get(id: string): Promise<DbReturn>
    }

    class Storage {
        constructor(private readonly db: Database) {}

        public async store(data: CanStore) {
            this.db.set(data.getContent())
    }
}

Percebam que agora temos um protocolo (Interface Database) para como devemos lidar com o banco de dados em si, e nossa classe Storage aponta para este protocolo, a qual é uma abstração, também criamos a classe DatabaseAdapter que implementa este protocolo, isso tudo significa que caso seja necessário trocar o ORM que estamos utilizando, quem deve fazer isso é a classe DatabaseAdapter que respeita o contrato definido em Database, mas nenhuma alteração será necessária em Storage.

Ah, mas se a tecnologia de banco de dados mudar, vamos precisar alterar a classe DatabaseAdapter, e isso fere o princípio OCP, não?
Não, por conta do SRP, pois a classe DatabaseAdapter só tem uma única razão para mudar, o banco de dados que estamos utilizando.

Extra:
Para sistemas que aderem ao DIP, é muito comum vermos Factories para construir as classes, do tipo:

const makeStorage = (): Storage {
    const db = new DatabaseAdapter(Sequelize)
    return new Storage(db)
}

E ao ter muitas classes que dependem de vários adaptadores, pode ficar muito chato montar essas factories, por isso recomendo que você de uma olhada no Inversify, existe uma curva de aprendizado para usar a ferramenta, mas com o conhecimento que você adquiriu durante este conteúdo, pode ser uma ótima adição a sua Stack.

Sintomas do descumprimento

Alterações em modulos não essenciais necessitam de alterações em módulos essenciais.
O que quero dizer é que seu negócio se torna dependente de suas ferramentas, sobre o seu negócio você tem controle, sobre as ferramentas que você utiliza, não, então depender delas é literalmente um tiro no pé.

Finalmente terminamos de ver todos os princípios do SOLID, e agora no final fica claro como os mesmos se complementam, mas para realmente fixarmos esse conhecimento, vamos praticar um pouco.

Exercícios

1) Um novo departamento é criado dentro da Apple e dois desenvolvedores são encarregados de criar funcionalidades que atendam a este novo departamento. As demandas dependem da integração de um banco de dados não relacional e do sistema de autenticação que já existe, então eles criam uma interface que define as funcionalidades desse novo elemento na infraestrutura, programam uma classe que atenda essa interface, então criam a classe que atende, de fato, o novo departamento, esta, é inicializada com a classe abstrata do novo banco de dados.
Eles percebem que vão precisar alterar a classe de autenticação para que possam utilizar seus recursos junto a classe do novo departamento.
Os desenvolvedores estão enfrentando este problema por que algum principio do SOLID foi ignorado, qual foi?

SRP
OCP
LSP
ISP
DIP Ver resposta OCP

2) Uma empresa percebe que está gastando muito com uma ferramenta que faz buscas em seu banco de dados não relacional, então decidem mudar para outra mais barata, porém, os desenvolvedores informam que vão precisar reestruturar a regra de negócio do sistema por causa disso, qual princípio do SOLID foi violado nesse caso?

Ver resposta DIP

3) Um hacker invadiu o sistema da Apple conseguindo acesso a uma conta de RH. Ele fez movimentações financeiras que não deveriam ser permitidas ao RH, isso só foi possivel porque um desenvolvedor extendeu a classe Administrativa que permitia essas operações e não sobrescreveu as funcionalidades de movimentação financeira para o RH, deixando a brecha que resultou nesse prejuizo, qual princípio do SOLID teria prevenido o ocorrido?

Ver resposta ISP

4) Você está passando por uma terrível dor de cabeça, pois toda vez que uma nova demanda de funcionalidade é destinada ao sistema em que trabalha é necessário mudar a classe responsável por registrar os logs do sistema, isso acontece por que a classe de Logs não está respeitando qual princípio?

Ver resposta SRP

5) Sobrescrever todas as funcionalidades de uma classe que você está estendendo não faz sentido, mas isso acontece em diversos sistemas onde os arquitetos não fazem um bom trabalho na hora de relacionar suas entidades, para estes arquitetos, qual principio do SOLID está sendo violado?

Ver resposta LSP

SOLID na prática

Conhecer os princípios do SOLID é o primeiro passo para se tornar um bom arquiteto de sistemas, mas para o total aproveitamento destes fundamentos, você deve conseguir identificar suas aplicações de forma rápida e intuitiva, para que isso aconteça, precisamos praticar.
Aqui proponho uma linha de raciocínio que pode facilitar muito seu trabalho.

Defina seus Atores

Como vimos durante o SRP, os atores são as chaves da nossa construção, o sistema é desenvolvido para eles e os módulos de alto nível que desenvolvermos devem ter a propriedade de só serem modificados mediante a necessidade de um e apenas um destes atores.
Ou seja, nunca comece a desenvolver um sistema perguntando o que ele vai fazer, mas sim quem vai utilizá-lo

Vamos então imaginar o desenvolvimento de um sistema para um e-commerce.

Quem vai utilizá-lo?

Consumidor
Operador
Gerente

Nesse cenário, quais são as atribuições de cada um destes atores?

Consumidor

Quer acessar o sistema para olhar catálogos e comprar itens.

Operador

Insere novos produtos no sistema e pode atualizar seus preços e informações.

Gerente

Existe para controlar as propriedades do sistema, pode adicionar novos operadores ou removê-los e alterar as taxas globais para compra de produtos.

Dessa forma, já estabelecemos nossas entidades mais primitivas e o que podem fazer em nosso sistema, traduzindo para o código:

    interface Customer {
        getProducts(start: number, end: number): Promise<Products[]>
        buy(productId: string): Promise<boolean>
    }

    interface Operator {
        addProduct(product: Product): Promise<boolean>
        updateProduct(product: Product): Promise<boolean>
    }

    interface Manager {
        addOperator(userId: string): Promise<boolean>
        removeOperator(userId: string): Promise<boolean>
        changeFees(fee: number): Promise<boolean>
    }

Aqui começamos a rascunhar o sistema e como ele deve se comportar, mas ainda faltam requisitos, principalmente os de caso base, por exemplo, como cadastrar um gerente na plataforma? Já que dependemos dele para cadastrar operadores e os clientes dependem dos operadores para ter produtos a serem visualizados e comprados.

Uma coisa podemos dizer que os 3 atores tem em comum, todos são usuários, que precisam se cadastrar, trocar suas senhas, caso necessário, verificarem seus perfis, etc.
Vamos desenhar uma interface para usuário:

    interface User {
        register(name: string, email: string, password: string): Promise<string>
        changePassword(userId: string, newPassword: string): Promise<boolean>
    }

Estaria correto dizer que Customer, Operator e Manager são subtipos válidos de User?

Isso quem nos responde é Barbara Liskov com o LSP, pois o comportamento de User não depende de maneira alguma do comportamento de nenhum dos 3 atores, o que significa que os mesmos não precisam sobrescrevê-los e sim, são subtipos válidos.

Agora temos então 4 módulos de sistema que respeitam o SRP, pois para o caso dos 3 atores apenas eles podem alterar seus comportamentos e para o caso do User, o comportamento só seria alterado se e apenas se a regra de usuários geral do sistema fosse alterada.

Ainda falta uma pergunta, se adicionarmos mais um Ator a este sistema, como um Coordenador, por exemplo, algum outro módulo teria de ser alterado para que o mesmo fosse feito? Ou se alterassemos o User, seria necessária uma alteração de seus subtipos?
Não, um Coordenador estenderia o User, e para todos os Atores que até o momento implementam User, não precisam sobrescrevê-lo, então estamos respeitando o OCP até o momento.

Apenas nesse pequeno exercício já resolvemos 3 princípios: SRP, OCP e LSP.

Entenda suas dependências

Cuidado com essa etapa, entender as dependências de um sistema não é escolher as ferramentas dele, mas sim o que essas ferramentas precisam ter para nos atender.

A dependência mais intuitiva que podemos ver aqui é um lugar para registrarmos nossos dados, então precisamos criar um tipo para definir o que utilizaremos de um banco de dados, vamos analisar ator por ator e entender suas necessidades:

Customer: Leitura e Escrita (Afinal de contas, a compra tem de ser registrada em algum lugar)
Operator: Escrita e Atualização
Manager: Escrita e Atualização

Ou seja, as funcionalidades necessárias de nosso banco são: Leitura, Escrita e Atualização. Percebam que não precisamos deletar dados em nenhum momento com nossas entidades, assim, partir do pré-suposto de que um CRUD é o mínimo necessário para uma implementação de banco de dados está errado.

Vamos escrever nossas interfaces para essa dependência:

    interface CanWrite {
        create(data: any): Promise<void>
    }
    interface CanChange {
        update(data: any): Promise<void>
    }
    interface CanRead {
        read(id?: string, startAt?: number, limit?: number): Promise<any[]>
    }

Para respeitar o ISP, tivemos de criar um protocolo para cada necessidade, pois o Customer precisa Ler e Escrever, o Operator e o Manager precisam Atualizar e Escrever, ou seja, se tivéssemos unido a função Update e Create em uma mesma interface, o Customer que só precisa Escrever teria a dependência da Atualização também, o que vai contra nosso princípio e já falamos anteriormente sobre os sérios problemas disso.

Nosso sistema também precisa ser exposto de alguma forma, seja como uma biblioteca ou aplicativo, mas aqui vamos escolher uma API, então vamos fazer o mesmo exercício do banco de dados para essa dependência.

Customer: GET e POST
Operator: POST e PUT
Manager: POST e PUT

Viram como caímos no exato mesmo modelo do banco de dados? Vamos criar as interfaces:

    interface CanGet {
        get(func: any): Promise<Controller>
    }
    interface CanPost {
        post(func: any): Promise<Controller>
    }
    interface CanPut {
        put(func: any): Promise<Controller>
    }

E pronto, temos nossas dependências estabelecidas, respeitando o ISP e finalmente vamos às ferramentas:

Defina suas ferramentas

Já sabemos o que precisamos de nossas ferramentas, então para o banco de dados, vamos escolher o Sequelize como nosso ORM (Dica: sempre tente tirar o máximo proveito que puder do typescript, escolha ferramentas que tenham tipos declarados ou que possuam alguma lib para tal, como no caso do Firestore (Google) que não possui as tipagens de modelo, mas temos o firestore-wrapper que lhe auxilia em tal tarefa) e o Express como o runtime de nossa aplicação.

A interface dos nossos adaptadores nós já temos, basta agora codificar suas classes com a ferramenta escolhida:

    class ReadAdapter implements CanRead {
        constructor (private readonly seq: Sequelize) {}
        async read(id?: string, startAt?: number, limit?: number): Promise<any[]> {
            // lógica da função
        }
    }

Como os módulos de nosso sistema estarão apontando para interfaces abstratas que são posteriormente implementadas por adaptadores que serão injetados nos módulos, estamos aqui respeitando o último princípio DIP.

Bom, até aqui acredito que você já tenha entendido a linha de raciocínio para se planejar um sistema com os princípios do SOLID em mente, que tal realmente colocarmos a mão na massa e criar um sistema simples com todas essas implementações e testes para cada um de nossos módulos a fim de garantirmos o comportamento esperado?
Isso vai ficar para o próximo artigo, enquanto isso, vamos praticar mais um pouco.

Exercícios

1) Analise o programa definido a seguir:


    class Circle {
        constructor(public readonly radius: number) {}
    }

    class Rectangle {
        constructor(public readonly width: number, public readonly height: number) {}
    }

    class CalculateArea {
        public circleCalculator(circle: Circle): number {
            return Math.PI * (circle.radius * circle.radius);
        }

        public rectangleCalculator(rectangle: Rectangle): number {
            return rectangle.width * rectangle.height;
        }
    }

Aqui temos um caso clássico de uma classe que calcula a área de diferentes Formas, temos o Círculo e o Retângulo, porém, este programa está violando um princípio, qual é este princípio?

Dica
Tente adicionar mais uma forma, como o Triângulo, por exemplo.



Ver resposta
OCP

1.1) Escreva um programa que corrija essa falha.

Ver resposta

interface Shape {
    calculateArea(): number;
}

class Circle implements Shape {
    constructor(public readonly radius: number) {}

    public calculateArea() {
        return Math.PI * (this.radius * this.radius);
    }
}

class Rectangle implements Shape {
    constructor(public readonly width: number, public readonly height: number) {}

    public calculateArea() {
        return this.width * this.height;
    }
}

class CalculateArea {
    public calculate(shape: Shape): number {
        return shape.calculateArea();
    }
}

2) Continuando com nosso programa que calcula formas geométricas, vamos replicar um caso definido por Martin sobre um dos princípios, analise o código a seguir:


    class Rectangle {
        constructor(public readonly width: number, public readonly height: number) {}
    }

    class Square extends Rectangle {

        constructor(public side: number) {
            super(side, side);
        }
    }

Qual princípio do SOLID está sendo violado? Por quê?

Dica
Square está alterando o comportamento de Rectangle



Ver resposta
LSP, pois a classe Square está estendendo Rectangle, mas os lados de um quadrado devem ter sempre o mesmo valor, enquanto o retangulo pode ter altura e largura indpendentes, tornando-se assim, um subtipo incoerente.

2.1) Escreva um programa que corrija essa falha.

Ver resposta

class Rectangle {
    constructor(public readonly width: number, public readonly height: number) {}
}

class Square {
    constructor(public readonly side: number) {}
}

3) Considere o programa abaixo:

    interface ShapeOperations {
        calculateArea(): number
        countVertex(): number
        calcDiameter(): number
    }

    class Square implements ShapeOperations {
        constructor(public readonly side: number) {}
        calculateArea(): number {
            return this.side * this.side;
        }
        countVertex(): number {
            return 4
        }
        calcDiameter(): number {
            return this.side * Math.sqrt(2);
        }
    }

    class Circle implements ShapeOperations {
        constructor(public readonly radius: number) {}
        calculateArea(): number {
            return Math.PI * (this.radius * this.radius);
        }
        countVertex(): number {
            throw new Error("Circle has no vertex");
        }
        calcDiameter(): number {
            return this.radius * 2;
        }
    }

Qual princípio do SOLID está sendo violado? Por quê?

Dica
Circle não pode implementar um contador de vértices



Ver resposta
ISP, se o circulo não pode implementar um contador de vértices, ele não deveria estender essa interface

3.1) Escreva um programa que corrija essa falha.

Ver resposta

interface HasArea {
    calculateArea(): number
}

interface HasVertex {
    countVertex(): number
}

interface HasDiameter {
    calcDiameter(): number
}

class Square implements HasArea, HasVertex, HasDiameter {
    constructor(public readonly side: number) {}
    calculateArea(): number {
        return this.side * this.side;
    }
    countVertex(): number {
        return 4
    }
    calcDiameter(): number {
        return this.side * Math.sqrt(2);
    }
}

class Circle implements HasArea, HasDiameter {
    constructor(public readonly radius: number) {}
    calculateArea(): number {
        return Math.PI * (this.radius * this.radius);
    }

    calcDiameter(): number {
        return this.radius * 2;
    }
}

Próximos passos

Leia o livro base para a construção desse conteúdo: Arquitetura Limpa por Robert C. Martin.

Com os conhecimento adquiridos nesse conteúdo, o livro do famoso Uncle Bob será muito mais palatável, mas não substitui a leitura do mesmo, que vai te apresentar outros exemplos com abordagens diferentes.

Tenha meios de planejar seus sistemas fora a escrita de interfaces.

UML é uma ferramenta muito poderosa para te ajudar no processo de planejamento, nesse conteúdo não falamos sobre isso, pois o foco aqui é o SOLID com Typescript, porém os diagramas são uma forma muito mais eficiente de entender como e o que será construido do que sair definindo interfaces, eles nos ajudam principalmente a entendermos como serão as relações entre nossas classes e entidades, quais comportamentos são esperados de cada uma e principalmente, nos ajudam a identificar os erros e incoerências dos programas antes de colocarmos a mão na massa. Um bom programador passa mais tempo no papel que no código.

Existem muitos artigos sobre o tema, como O do professor Marcelo Linder, que de uma forma simples te apresenta os conceitos básicos, mas se você quiser um conteúdo mais completo, minha recomendação é o livro UML 2 - Uma Abordagem Prática.

Estude DDD.

Neste conteúdo eu propus uma linha de raciocionio para você começar a formular seus sistemas, porém, é importante que você entenda sobre os processos mais aceitos de design de software.
Proposto por Eric Evans em seu livro Domain-Driven Design: Atacando as complexidades no coração do software em 2003, o DDD é fundamental para que engenheiros de software consigam se comunicar bem com os experts do negócio e traduzir as necessidades de maneira efetiva para o sistema.
O livro é minha principal recomendação, mas caso queira uma introdução um pouco mais direta, o artigo da FullCycle sobre o assunto é bem interessante.

Saiba trabalhar em equipe.

Depois de se tornar um especialista em arquitetura de sistemas, precisa trabalhar com outros desenvolvedores de maneira eficiente, para que depois de tudo bem planejado, cada um ataque um domínio do sistema a ser desenvolvido, e para que vocês não caiam no famoso ditado: O que um desenvolvedor faz em uma semana, dois fazem em duas.

Com um sistema bem desenhado e planejado, esse trabalho se torna algo muito fácil e para ajudar ainda mais, recomendo que estude sobre GitFlow e utilize sempre o Conventional Commits para ajudar seus colegas a entenderem o que você está fazendo.

Why should you consider adding Rust to your stack?

Leonardo Bonetti — Wed, 17 Aug 2022 17:45:30 +0000

Rust is a high-level language with low-level performance, which brings us to our first ready:

Performance

Unlike languages like C or C++, developing in rust is extremely fast and particularly satisfying, with the compiler extremely efficient in pointing out problems in the code, it becomes your friend and not your enemy (As I particularly felt developing applications in C around mid-2012 ).
It's a memory-safe language, forget the problems with null pointers and etc, garbage collector doesn't exist here because of the Ownership strategy.
Everything in the language is aimed at giving you the necessary possibilities to create the most performative systems possible with the practicality of interpreted languages like JS

Expand your technical vision

The market demands more and more speed of delivery from developers and languages like JS/TS help us a lot at this point, it has gigantic communities and many ready-made solutions, which hardly a JS developer will worry about concurrency problems, thread starving, efficiency in memory allocation, etc.
Each technology has its place and will better serve different situations, in terms of productivity, JS/TS is undoubtedly the best possible solution, depending on the needs of the system, it guarantees a fast and concise delivery, the problem starts when we tend to use the same technology for EVERYTHING.
Chances are, if you decide to learn RUST, you won't use it on your entire system, but rather create services to meet very specific demands that require extraordinary performance and security (You can even do everything in Rust, but as I said, each technology has its place and it would not be smart to do so in most situations).
I will exemplify with my work case, my company builds systems for financial solutions, in the case of a brokerage firm, 80% of the system is CRUDs, and for these 80% nothing better than a super productive language, but the 20% that is the order book used in trading and user balance control where atomicity and performance have to be guaranteed, that's where Rust shines, it gives you options that in the comfort of working so long with interpreted languages, you end up forgetting that exist, it brings you closer to the most basic fundamentals of building a computational system, giving you possibilities and a security that no other interpreted language will provide you.

Opportunities

The Rust ecosystem is infinitely smaller compared to JS/TS, although I've been a language lover since 2019, I'm just now feeling full security in bringing it to my company's stack, as it's getting more and more mature, but far from being extremely comprehensive, this means a fertile environment for growth opportunities, the reasons mentioned above make Rust a very desired language, but there is a great shortage of professionals and tools to help development.

Por que você deveria considerar adicionar Rust a sua stack?

Leonardo Bonetti — Wed, 17 Aug 2022 17:25:59 +0000

Rust é uma linguagem de alto nível com performance de uma de baixo nível, isso já nos leva ao nosso primeiro pronto:

Performance

Diferente de linguagens como C ou C++, desenvolver em rust é extremamente rápido e particularmente satisfatório, com compilador extremamente eficiente em apontar problemas no código, ele se torna seu amigo e não seu inimigo (Como particularmente me sentia desenvolvendo aplicações em C por meados de 2012).
É uma linguagem memory-safe, esqueça os problemas com null pointers e etc, garbage collector não existe aqui por conta da estratégia do Ownership.
Tudo na linguagem é voltado a te dar as possibilidades necessárias para criar os sistemas mais performáticos possíveis com a praticidade de linguagens interpretadas como JS

Ampliar sua visão técnica

O mercado demanda cada vez mais velocidade de entrega dos desenvolvedores e linguagens como JS/TS nos ajudam demais nesse ponto, tem comunidades gigantescas e muitas soluções prontas, que dificilmente um desenvolvedor JS vai se preocupar com problemas de concorrência, starving de threads, eficiência em alocação de memória e etc.
Cada tecnologia tem seu lugar e vai atender melhor a diferentes situações, em ponto de produtividade, JS/TS é sem dúvida a melhor solução possível, dependendo da necessidade do sistema, ela te garante uma entrega rápida e concisa, o problema começa quando tendemos a usar a mesma tecnologia para TUDO.
Provavelmente, se você decidir aprender RUST, não vai usá-lo em todo o seu sistema, mas sim criar serviços para atender a demandas muito específicas que exigem uma performance e segurança extraordinária (Você até pode fazer tudo em Rust, mas como já dito, cada tecnologia tem seu lugar e não seria inteligente fazer isso na maioria das situações).
Vou exemplificar com meu caso de trabalho, minha empresa constrói sistemas para soluções financeiras, no caso de uma corretora, 80% do sistema são CRUDs, e para esses 80% nada melhor do que uma linguagem super produtiva, mas os 20% que é o livro de ordens usado em negociações e o controle de saldo dos usuários onde a atomicidade e performance tem de ser garantidas, é ai que o Rust brilha, ele te dá opções que no conforto de se trabalhar tanto tempo com linguagens interpretadas, você acaba esquecendo que existem, ele te aproxima dos fundamentos mais básicos da construção de um sistema computacional, te dando possibilidades e uma segurança que nenhuma outra linguagem interpretada vai te proporcionar.

Oportunidades

O ecossistema do Rust é infinitamente menor comparado ao JS/TS, apesar de eu ser um amante da linguagem desde 2019, só agora estou sentindo segurança plena em trazer ela para a stack da minha empresa, pois está cada vez mais madura, mas longe de ser extremamente abrangente, isso significa um ambiente fértil de oportunidades de crescimento, os motivos citados acima tornam Rust uma linguagem muito desejada, mas existe uma grande escassez de profissionais e ferramentas para o auxílio do desenvolvimento.

Arquitetura orientada ao Ator

Leonardo Bonetti — Wed, 22 Dec 2021 14:17:55 +0000

Propor um modelo de arquitetura de software que orienta o sistema a seus utilizadores.

Apesar de parecer redundante dizer que um sistema deve ser desenvolvido a partir da orientação de seus utilizadores, um dos maiores problemas do processo de desenvolvimento é que os programadores tendem a criar mecânicas que façam sentido no ponto de vista de quem desenvolve, mas não necessariamente no ponto de vista de quem o utiliza, essa prática leva ao processo comum de utilizadores não se adaptarem a mecânicas que parecem ser simples e intuitivas.

O modelo descrito a seguir extende os conceitos definidos por Robert C. Martin em Clean Architecture: A Craftsman’s Guide to Software Structure

Atores

Atores são basicamente quem stabelece quais regras o sistema deve cumprir e qual comportamento esperado, antes de começarmos a pensar em desenvolver nossa aplicação, temos de estabelecer quem são seus atores, eles podem ser usuários tradicionais ou outros sistemas.

Atores são todos que interagem com a aplicação.

Para desenvolvermos esse raciocinio, vamos propor um sistema que iremos construir ao decorrer deste artigo, a aplicação escolhida é um simples sistema de loja.

Normalmente quando iniciamos a produção de um sistema, nos questionamos sobre as funcionalidades que ele terá, no modelo A.O.A, vamos começar com uma pergunta diferente:
Quem vai utilizar esse sistema?

Consumidor comum
Gerente
Operador

Aqui já estabelecemos a quem o sistema interessa, agora Por que o sistema interessa a esses atores?
Consumidor Comum (Costumer)

Ele quer acessar o sistema para olhar os catálogos e comprar itens, podemos dizer que ele é nosso ator mais importante, é o motivo do sistema existir.

Operador (Operator)

Ele preenche nosso sistema com as informações que serão disponibilizadas ao Costumer, adiciona produtos e atualiza preços.

Gerente (Manager)

Ele é a entidade que existe para controlar as propriedades do sistema, ele adiciona novos operadores e pode alterar as taxas impostas por compras.

O processo de se estabelecer os atores do sistema é com certeza o mais demorado e de certa forma caótico deste modelo de arquitetura, pois todo o resto do sistema será orientado a isso, então tenha certeza de gastar um bom tempo com o P.O do projeto ou seu cliente diretamente para entender todas essas peculiaridades da aplicação, atores definem as funções assim como normalmente contradizem elas.

Imaginem que o recebemos as seguintes definições:

O gerente pode alterar a taxa de compra de todos os consumidores
O operador pode alterar a taxa de compra de consumidores específicos

Temos aqui duas solicitações conflitantes de atores diferentes, pois se o gerente pode alterar todas as taxas ele tem o poder completo sobre o conjunto, mas o operador tem o poder sobre um elemento do conjunto, dessa forma que descrevi podemos interpretar que o maior poder é o gerente então em caso de conflito, ele teria a prioridade, mas se pensarmos que o poder não vem de quem tem o controle sobre o todo e sim a maior precisão, então em caso de conflito o operador que venceria.

Existem diversas formar de se resolver o problema acima, mas todas elas exigem que o arquiteto crie regras de negócios e a não ser que você seja o arquiteto do sistema e o dono do negocio, não se deve fazer isso para resolver um problema técnico.

Sendo assim, esse problema deve ser identificado pelo arquiteto, mas devolvido ao P.O para que se crie uma regra que resolva a disputa, geralmente o melhor jeito de se resolver esse tipo de disputa é não deixar com que dois atores interagem da mesma forma com uma mesma entidade

Entidades

Entidades são os elementos internos de seus sistemas, seus modelos de dados.

Agora que já sabemos quem são nossos atores, podemos definir quem são nossas entidades a partir das funções que os atores precisam realizar em nosso sistema.

Vamos fazer uma análise de nosso primeiro ator e o quais entidades ele precisa:

Costumer

Tem acesso ao catálogo de produtos
Adiciona itens a seu carrinho de compras
Compra um produto

A primeira funcionalidade é uma visualização, e a entidade necessária para realizar a mesma está em sua citação:

Produto

Já a segunda funcionalidade nos descreve uma entidade também em sua citação:

Carrinho de compras

Porem um carrinho de compras naturalmente precisa estar atrelado a algo, normalmente a um usuário, e assim chegamos a conclusão de uma entidade ainda mais primitiva, a representação do Ator dentro do sistema, o Costumer se torna um usuário.

Atenção: O exemplo acima não estabelece que todos os atores tem uma entidade apenas para sí no sistema, apenas que esse ator em especifico precisa de uma representação, mas que também pode ser a representação de outros atores.

A terceira funcionalidade pode ser resolvida com as entidades já presentes?

Vamos analisar o caso, temos então três entidades:

Produto
Carrinho de compras
Usuário

Uma compra pode ser descrita como produtos em um carrinho de compras pertencentes a um usuário que realiza um pagamento mediante ao valor somado dos produtos.

Analisando a citação, temos uma ação e exatamente três objetos que são nossas entidades.

A ação ainda não era conhecida, mas agora sabemos que pagar é uma funcionalidade do Ator Costumer, então podemos adicionar a nossa lista de funcionalidades desse ator.

Vamos analisar o caso do Operador

Ele pode:

Cadastrar novos produtos
Alterar o valor dos produtos

Ja temos a entidade de produto, mas é necessário saber quem é o operador para permitirmos as operações, e também já temos uma entidade primitiva que pode servir a esse propósito, a entidade Usuário.

Ou seja, não é necessário criar mais nenhuma entidade para o operador.

O Gerente pode:

Adicionar novos operadores
Mudar taxas de compras

Para a primeira funcionalidade, já sabemos que o operador é representado pela entidade usuário, sendo assim o gerente vai interagir com ela para adicionar novos operadores.

Para alterar as taxas de compras vamos precisar de um entidade que defina esses valores, podemos por enquanto defini-la como propriedades do sistema.

No final estabelecemos as seguintes entidades:

Usuário
Carrinho de compras
Produtos
Propriedades do sistema

Domain

Já entendemos quem são nossos atores e entidades, vamos agora colocar isso em nosso sistema e essa definição é feito na primeira camada chamada Domain.

A proposta dessa camada é criar as definições em níveis de código que será estendidas a outras camadas que atendam as mesmas, para este artigo não vou colocar trechos de códigos, pois a proposta é que uma arquitetura de software não dependa do ambiente ou tecnologia para ser aplicada, sendo assim, sinta-se livre para adaptar os exemplos em sua linguagem de preferência.

A estrutura de arquivos de domain ficaria da seguinte forma:

Domain
- Entities
  - User
  - Shop Cart
  - Product
  - SystemProperties
- Actor
  - Costumer
    - Get catalog
    - Add product to cart
    - Remove product from cart
    - Buy
  - Operator
    - Add product
    - Change product
  - Manager
    - Add Operator
    - Change fees

É importante ressaltar que dentro de domain não temos nenhum processo lógico, apenas interfaces que terão de ser respeitadas por outras funções que as implementem.

Dessa forma, qualquer desenvolvedor pode pode compreender as responsabilidades de cada usuário do sistema e como as mesmas se comportam, mas onde estariam os processos lógicos para fazer as funções do domain funcionarem?

Composer

A camada de composição é onde implementaremos as interfaces descritas acima e iremos compor a lógica de nossas funções.

Essas funções tem diversas sub-responsabilidades, como em Costumer → Add product to cart, temos de:

Buscar o produto
Validar as quantidades disponíveis dos mesmos
Adicionar ao carrinho
Atualizar valor total do carrinho

Por isso essa camada se chama Composer, ela faz a composição dos módulos do sistema e ao mesmo tempo também declara como esses módulos devem se comportar, pensando nisso, alem de criarmos os usecases das funções relativas aos atores, temos de criar os protocolos (interfaces) das funções relativas aos módulos nesta camada, a estrutura de composer seria:

Composer

Protocols
- Get product
- Check product amount
- Add to cart
- Update cart price
- ... (Todas as interfaces dos módulos necessários pelos compositores)
Costumer
- Get catalog
- Add product to cart
- Remove product from cart
- Buy
... (Continuar replicando os casos de uso de cada ator)

Agora devemos criar os módulos que atendam a necessidade de nossos compositores, já temos suas interfaces e sua lógica deve ser descrita na próxima camada

Modules

Um módulo é a menor parte executável de um sistema, geralmente caracterizado por um processo que pode ser utilizado por mais de um compositor, pegando o mesmo exemplo do Get product, isso é uma função que pode ser reutilizada em casos de uso pertencentes ao Usuário comum ou ao operador.

Diferentes módulos não devem implementar a mesma interface, digamos que tanto o Usuário comum quanto o Operador dependam de um modulo de buscar produto, porem o operador deve buscar esse produto da base de dados A e o Usuário comum deve buscar o produto da base de dados B, nesse caso o ideal é criarmos dois protocolos a mais em Composer, lá já temos estabelecido o protocolo de buscar produto e devemos estende-lo a interface Buscar produto de A e Buscar produto de B.

Tecnicamente não é problema dois módulos diferentes utilizarem a mesma interface, porem a diferenciação teria de ser feito nas Factories dos compositores, e uma boa arquitetura de software visa minimizar as possibilidades de erros, clarear o entendimento do sistema por seus desenvolvedores e facilitar a adaptação do sistema a mudanças. Não diferenciar a interface de dois módulos prejudica tanto a compreensão do sistema quando a possibilidade de ocasionar erros, pois digamos que um desenvolvedor precise fazer a alteração do compositor que utiliza o modulo de Buscar produtos de A, mas como a interface é a mesma ele se distrai e coloca o modulo de Buscar produtos de B, o sistema não vai reclamar, mas o P.O vai, por seu código não estar funcionando.

Infra

A camada de infraestrutura é onde vamos conectar nosso sistema as dependências necessárias para fazermos o mesmo funcionar, é a camada mais externa da nossa arquitetura.

Nosso módulo Get product from A precisa de um banco de dados para realizar essa busca, e o driver que irá conectar os dois está presente nessa mesma camada, neste caso o módulo em questão se torna também um adaptador ao banco de dados, pois qualquer alteração necessária no banco de dados vai gerar uma alteração no módulo que importa as propriedades de infraestrutura, mas não vai impactar de forma alguma nossa camada de composição que detém a regra de negócio do sistema.

Digamos que nosso sistema seja uma API Rest e precisamos de um framework para expor endpoints para os acessos do sistema pelos atores, o framework em si estará presente em infra.

Main

Esse parte é opcional e depende de como cada tecnologia se comporta, mas precisamos fazer essas camadas conversarem entre si e adicionarmos algum ponto de partida para nosso sistema ser iniciado.

Caso você esteja utilizando uma linguagem O.O e trabalhando com classes, precisa injetar as dependências necessárias nas classes dos compositores e isso normalmente é feito por factories, idealmente essas instruções estariam na camada Main que inicia o sistema.

Este é um trabalho ainda em desenvolvimento, então se chegou até aqui e quiser contribuir, me envie uma mensagem por aqui mesmo ou deixe um comentário, ficarei muito grato por qualquer esforço, de qualquer forma, muito obrigado pela atenção

15 minutes to create a Telegram Bot that can answer any question

Leonardo Bonetti — Fri, 05 Mar 2021 19:39:10 +0000

Introduction

In last article we create a personal assistant in 15 minutes,
due to its good acceptance, I decided to bring other challenges of 15 minutes, today, a telegram bot called Genius, he will try to answer anything you ask

The rules:

- interact with the system by telegram chat (Obviously)
- Searches must be carried out using wikipedia
- The robot must be able to change its response if it is not satisfactory to the user

Let's start

Create project

Create a folder to your project, on terminal execute the following command:
npm init -y && npx ts-init

Check that your tsconfig.json file is as follows

{
  "compilerOptions": {
    "lib": [
      "es6",
      "DOM"
    ],
    "alwaysStrict": true,
    "strictNullChecks": true,
    "noImplicitAny": true,
    "esModuleInterop": true,
    "resolveJsonModule": true
  },
  "files": [
    "src/index.ts"
  ]
}

Lets get our packages

npm i node-telegram-bot-api --save && npm i @types/node-telegram-bot-api -D node-telegram-bot-api is an amazing library to abstract Telegram Bot API and make our lives easier.
npm i wikipedia --save Wikipedia is a simple lib that abstract the wiki endpoints.

Create our bot

Open your telegram and search for @botfather
Open the conversation and click in start
Type /newBot
Give the common name and the name of the robot as indicated by the telegram instructions
Save the token key in some place to we use later

Let's code

First of all, wee need to import the libraries that will be used, so, create a file named src/index.ts.

import telegram from 'node-telegram-bot-api';
import wikipedia from 'wikipedia';

const TELEGRAM_KEY = "YOUR-API-KEY-HERE";

remember to replace where YOUR-API-KEY-HERE is written with your robot key

Create some interaction

Paste this code inside your src/index.ts

...
const Bot = new telegram(TELEGRAM_KEY, {polling: true});

Bot.onText(/\/start/, async (msg) => {
    if(!msg.from) return Bot.sendMessage(msg.chat.id, 'I not accept you!');
    Bot.sendMessage(msg.chat.id, 'Wellcome to GeniusAnswer, ask me something');
});

When a user starts the bot, we send a message asking the user to ask something

The main function

Paste this code inside your src/index.ts

...
const wikisearch = async (topic: string, pageIndex: number) => {
    const search = await wikipedia.search(topic);

    if(pageIndex > search.results.length) throw new Error('Invalid page index');

    const page = await wikipedia.page(search.results[pageIndex].title);

    const summary = await page.summary();

    return {text: summary.extract, pageIndex: 0, pageLength: search.results.length};
};

Bot.on("text", async (msg) => {
  if (!msg.from) return Bot.sendMessage(msg.chat.id, "I not accept you!");
  if (!msg.text) return Bot.sendMessage(msg.chat.id, "Invalid message");
  if (msg.text[0] === "/") return;

  Bot.sendMessage(msg.chat.id, `Searching for ${msg.text} ...`);

  const search = await wikisearch(msg.text, 0);

  console.log(search);

  let options_button = {};
  if (search.pageIndex < search.pageLength) {
    options_button = {
      reply_markup: {
        inline_keyboard: [
          [
            {
              text: "Next Answer ->",
              callback_data: JSON.stringify({ topic: msg.text, pageIndex: 1 }),
            },
          ],
        ],
      },
    };
  }

  return Bot.sendMessage(
    msg.chat.id,
    `${search.text} \n Answer ${search.pageIndex + 1}/${search.pageLength}`,
    options_button
  );
});

});

Here we only create a search function thata can make searchs on wikipedia and return the index of this result, if wee need a diferent result for this question, we only need to pass a diferent index for the function.
On next function will listen for text messages send to your bot, on result wee put a button that can change the index of search.

The callback function

Paste this code inside your src/index.ts

...
Bot.on("callback_query", async (callback) => {
  if (!callback.data || !callback.message) return;

  console.log(callback.data);

  const data = JSON.parse(callback.data) as {
    topic: string;
    pageIndex: number;
  };

  try {
    const search = await wikisearch(data.topic, data.pageIndex);

    console.log(search);

    let options_button = {};
    let inline_keyboard_buttons = [];
    if (search.pageIndex + 1 < search.pageLength) {
      inline_keyboard_buttons.unshift({
        text: "Next Answer ->",
        callback_data: JSON.stringify({
          topic: data.topic,
          pageIndex: search.pageIndex + 1,
        }),
      });

      if (search.pageIndex > 0) {
        inline_keyboard_buttons.unshift({
          text: "<- Previous Answer",
          callback_data: JSON.stringify({
            topic: data.topic,
            pageIndex: search.pageIndex - 1,
          }),
        });
      }
    } else if (search.pageIndex + 1 === search.pageLength) {
      inline_keyboard_buttons.unshift({
        text: "<- Previous Answer",
        callback_data: JSON.stringify({
          topic: data.topic,
          pageIndex: search.pageIndex - 1,
        }),
      });
    }

    if (inline_keyboard_buttons.length > 0) {
      options_button = {
        reply_markup: {
          inline_keyboard: [inline_keyboard_buttons],
        },
      };
    }

    return Bot.editMessageText(
      `${search.text} \n Answer ${search.pageIndex + 1}/${search.pageLength}`,
      {
        chat_id: callback.message.chat.id,
        message_id: callback.message.message_id,
        ...options_button,
      }
    );
  } catch (error) {
    return Bot.editMessageText(
      "Sorry, an error seems to have happened, please try again later",
      {
        chat_id: callback.message.chat.id,
        message_id: callback.message.message_id,
      }
    );
  }
});

Ok, although the callback function is very long, is easily to be understood, we just capture the search topic and change the index, depending on whether or not you have a next or previous page, we add the respective buttons to the message.

Now your code need to be like this

import telegram from "node-telegram-bot-api";
import wikipedia from "wikipedia";

const TELEGRAM_KEY = "YOUR-TELEGRAM-KEY-HERE";

const Bot = new telegram(TELEGRAM_KEY, { polling: true });

Bot.onText(/\/start/, (msg) => {
  if (!msg.from) return Bot.sendMessage(msg.chat.id, "I not accept you!");
  Bot.sendMessage(msg.chat.id, "Wellcome to GeniusAnswer, ask me something");
});

const wikisearch = async (topic: string, pageIndex: number) => {
  const search = await wikipedia.search(topic);

  if (pageIndex > search.results.length) throw new Error("Invalid page index");

  const page = await wikipedia.page(search.results[pageIndex].title);

  const summary = await page.summary();

  return {
    text: summary.extract,
    pageIndex: pageIndex,
    pageLength: search.results.length,
  };
};

Bot.on("text", async (msg) => {
  if (!msg.from) return Bot.sendMessage(msg.chat.id, "I not accept you!");
  if (!msg.text) return Bot.sendMessage(msg.chat.id, "Invalid message");
  if (msg.text[0] === "/") return;

  Bot.sendMessage(msg.chat.id, `Searching for ${msg.text} ...`);

  const search = await wikisearch(msg.text, 0);

  console.log(search);

  let options_button = {};
  if (search.pageIndex < search.pageLength) {
    options_button = {
      reply_markup: {
        inline_keyboard: [
          [
            {
              text: "Next Answer ->",
              callback_data: JSON.stringify({ topic: msg.text, pageIndex: 1 }),
            },
          ],
        ],
      },
    };
  }

  return Bot.sendMessage(
    msg.chat.id,
    `${search.text} \n Answer ${search.pageIndex + 1}/${search.pageLength}`,
    options_button
  );
});

Bot.on("callback_query", async (callback) => {
  if (!callback.data || !callback.message) return;

  console.log(callback.data);

  const data = JSON.parse(callback.data) as {
    topic: string;
    pageIndex: number;
  };

  try {
    const search = await wikisearch(data.topic, data.pageIndex);

    console.log(search);

    let options_button = {};
    let inline_keyboard_buttons = [];
    if (search.pageIndex + 1 < search.pageLength) {
      inline_keyboard_buttons.unshift({
        text: "Next Answer ->",
        callback_data: JSON.stringify({
          topic: data.topic,
          pageIndex: search.pageIndex + 1,
        }),
      });

      if (search.pageIndex > 0) {
        inline_keyboard_buttons.unshift({
          text: "<- Previous Answer",
          callback_data: JSON.stringify({
            topic: data.topic,
            pageIndex: search.pageIndex - 1,
          }),
        });
      }
    } else if (search.pageIndex + 1 === search.pageLength) {
      inline_keyboard_buttons.unshift({
        text: "<- Previous Answer",
        callback_data: JSON.stringify({
          topic: data.topic,
          pageIndex: search.pageIndex - 1,
        }),
      });
    }

    if (inline_keyboard_buttons.length > 0) {
      options_button = {
        reply_markup: {
          inline_keyboard: [inline_keyboard_buttons],
        },
      };
    }

    return Bot.editMessageText(
      `${search.text} \n Answer ${search.pageIndex + 1}/${search.pageLength}`,
      {
        chat_id: callback.message.chat.id,
        message_id: callback.message.message_id,
        ...options_button,
      }
    );
  } catch (error) {
    return Bot.editMessageText(
      "Sorry, an error seems to have happened, please try again later",
      {
        chat_id: callback.message.chat.id,
        message_id: callback.message.message_id,
      }
    );
  }
});

Now, our code is complete, let's test?

Run npm run ts on your terminal and open your telegram.
Search for your bot name (the same that you create in the begin of this article, generally ends with _bot) and press START.

Enjoy yourself!

There are some ways to optimize the response time of this robot, if you are interested I can show them in another article later, but I believe this is an interesting challenge for those who liked the idea of the robot, leave in the comments your solutions and ideas

15 minutes to create a personal assistant that can search on wikipedia (and tell some horrible jokes)

Leonardo Bonetti — Tue, 02 Mar 2021 14:32:42 +0000

Introduction

On a boring day at work, a colleague and I were talking to Alexa, when a bet arose due to the joke, creating a virtual assistant in 15 minutes.

Alexa has a multitude of functions, so to make the challenge possible ours should just take questions about common topics.

Then we choose the following rules:

The assistant must interact with you by speaking your name
Responses must be in audio
Searches must be carried out using wikipedia
Tell some jokes

Let's code

Create project

I can't code without typescript anymore, so...

npm init -y && npx ts-init

Check that your tsconfig.json file is as follows

{
  "compilerOptions": {
    "lib": [
      "es6",
      "DOM"
    ],
    "alwaysStrict": true,
    "strictNullChecks": true,
    "noImplicitAny": true,
    "esModuleInterop": true,
    "resolveJsonModule": true
  },
  "files": [
    "src/index.ts"
  ]
}

Lets get our packages

npm i --save say Say is an amazing TTS (Text-to-Speech) library, it will help us with a voice to our robot.
npm i --save wikipedia Wikipedia is a simple lib that abstract the wiki endpoints and make our lives easier

Add some Jokes

Create a file named src/jokes.json, copie the content of this gist to your file

Finally we will code

Inside your src/index.ts import all libraries

import say from 'say';
import wikipedia from "wikipedia";
import jokes from './jokes.json';
import readline from "readline";

...

Our personal assistant will receive the commands by text, like the old ways
So, w'll need a interface to interact with our user by terminal

...

const rl = readline.createInterface({
    input: process.stdin,
    output: process.stdout
});

The main goal here is create an assistant that can make searchs on wikipedia, so, lets create this func

...
const wikisearch = async (topic: string) => {
    const search = await wikipedia.search(topic);
    const page = await wikipedia.page(search.results[0].title);

    const summary = await page.summary();

    return summary.extract;
}

Now let's give our assistant a voice

...
const speak = (text: string) => {
    return new Promise((resolve, reject) => {
        say.speak(text, 'Samantha', 0.9, (err) => {
            if(err) reject(err);
            resolve(true);
        });
    })
}

As my assistant is a woman, I decided to give her the voice of Samantha, and to make it more audible, I leave the playback speed at 0.9, but feel free to change any of these properties, you can check the full list of voices available here

Ok, lets interact.
By the first rule of the challenge, the bot need to know our name, so

...

let name = "";

rl.question("What is your name ? ", async function(received: string) {
        name = received;
        await speak(`Hello ${received}, my name is Clotilde`);
        ask();
});

Now, lets code the final function

...
const ask = () => {
    rl.question("ask me something: ", async function(rQuery: string) {

        if(rQuery == 'stop') {
            say.stop();
            return rl.close();
        }

        if(rQuery.toLocaleLowerCase().split(' ').findIndex(item => item == 'joke') > -1) {
            const jokeIndex = Math.floor(Math.random() * jokes.length);
            const joke = jokes[jokeIndex];
            await speak(joke.text);
        } else {
            const searchTopic = await wikisearch(rQuery);
            await speak(`According to wikipedia, ${searchTopic}`);
        }

        ask();
    });
}

The idea here is very simple, if the user asks something that contains the word joke, we tell a joke, if not, we search on wikipedia.

And, for finally, when we shutdown our assistant:

...

rl.on("close", async function() {
    console.log("\nBYE BYE !!!");
    await speak("Bye Bye");
    process.exit(0);
});

She will say "Bye Bye"

Your code should now look like this:

import say from 'say';
import wikipedia from "wikipedia";
import jokes from './jokes.json';
import readline from "readline";

const rl = readline.createInterface({
    input: process.stdin,
    output: process.stdout
});

const wikisearch = async (topic: string) => {
    const search = await wikipedia.search(topic);
    const page = await wikipedia.page(search.results[0].title);

    const summary = await page.summary();

    return summary.extract;
}

const speak = (text: string) => {
    return new Promise((resolve, reject) => {
        say.speak(text, 'Samantha', 0.9, (err) => {
            if(err) reject(err);
            resolve(true);
        });
    })
}

let name = "";

rl.question("What is your name ? ", async function(received: string) {
        name = received;
        await speak(`Hello ${received}, my name is Clotilde`);
        ask();
});


const ask = () => {
    rl.question("ask me something: ", async function(rQuery: string) {

        if(rQuery == 'stop') {
            say.stop();
            return rl.close();
        }

        if(rQuery.toLocaleLowerCase().split(' ').findIndex(item => item == 'joke') > -1) {
            const jokeIndex = Math.floor(Math.random() * jokes.length);
            const joke = jokes[jokeIndex];
            await speak(joke.text);
        } else {
            const searchTopic = await wikisearch(rQuery);
            await speak(`According to wikipedia, ${searchTopic}`);
        }

        ask();
    });
}


rl.on("close", async function() {
    console.log("\nBYE BYE !!!");
    await speak("Bye Bye");
    process.exit(0);
});

The complete repo of this project can be found on here

Thank you very much, let us know in the comments section how long it took you to create this bot

Lint, what and why

Leonardo Bonetti — Tue, 03 Nov 2020 15:32:46 +0000

The problem:

The statement “Time is money” makes more and more sense among programmers, being efficient allows more jobs in less time and you certainly don't want to waste your hours behind a ghost character or a dead code due to a lack of attention during development.

Spending hours developing an application can be exhausting, and it gets worse when we finally test it and "CRASH!". (Let's go back there in the code to resolve this).
After a few more hours it turns out that the problem was the lack of a single character in the code.

Well, the top case is probably the daily life of many developers, and without a doubt it is one of the oldest problems in programming.

The solution:

"We are going to write a program that checks the code to find possible syntax errors, infinite loops, dead codes, etc."

In 1978 a computer scientist working for Bell Labs named Stephen C. Johnson created a program for checking static code in C, currently we have Linters for virtually all commercial programming languages, and at development time they point out flaws in our code that could even pass as a structural or logical problem in our application, making us spend hours and hours behind the problems.

When to use?
“Prevention is better than cure”, so always, always use Linters in your projects, no matter the size and duration.

But which linter should I use?
The https://github.com/mcandre/linters repository is an extremely useful source for you to find the best one for your language and need.

Automation:
Okay, it is useless to use a tool to prevent errors caused many times by lack of attention, but forget to use it.
So there are several ways to automate the code checking process, let's talk about my two favorites.

Git Hooks. (My favorite)
During pre-commit, set up a command to perform the inspection of your code using your preferred linter, so the chance of sending broken code to your repository is minimal.
CI
If you are using GitFlow, you will probably code your feature in a specific branch for it, and when your work is done if you create a merge request for the development branch, use your Git Host resources (GitHub or GitLab) to set up a CI process that executes a command to check your code before asking another developer to approve it, that way, not only is your time saved, but it helps to save the time of the rest of the team.