Os princípios SOLID são um conjunto de diretrizes para escrever software de alta qualidade, manutenível e escalável.

Eles foram introduzidos por Robert C. Martin em seu artigo de 2000, "Design Principles and Design Patterns" (Princípios de padrões de design, em português – texto do link em inglês), para ajudar desenvolvedores a escrever software que seja fácil de entender, modificar e estender.

Esses conceitos foram posteriormente desenvolvidos por Michael Feathers, que nos apresentou a abreviação SOLID.

SOLID tem a ver com:

• Single Responsibility Principle (Princípio da responsabilidade única - SRP)
• Open-Closed Principle (Princípio aberto-fechado - OCP)
• Liskov Substitution Principle (Princípio da substituição de Liskov - LSP)
• Interface Segregation Principle (Princípio da segregação de interface - ISP)
• Dependency Inversion Principle (Princípio da inversão de dependência - DIP)

Esses princípios fornecem uma maneira para os desenvolvedores organizarem seu código e criarem software flexível, fácil de alterar e testável. A aplicação dos princípios SOLID pode levar a um código mais modular, manutenível e extensível, além de poder facilitar a colaboração entre desenvolvedores em uma base de código.

Neste tutorial, exploraremos cada um dos princípios SOLID em detalhes. Explicaremos por que eles são importantes e forneceremos exemplos de como você pode aplicá-los na prática. Ao final deste tutorial, você deverá ter um bom entendimento dos princípios SOLID e de como aplicá-los aos seus projetos de desenvolvimento de software.

O que é o princípio da responsabilidade única?

O princípio da responsabilidade única (SRP) afirma que uma classe deve ter apenas um motivo para mudar, ou, em outras palavras, ela deve ter apenas uma responsabilidade. Isso significa que uma classe deve ter apenas um trabalho a fazer e deve fazê-lo bem.

Se uma classe tiver muitas responsabilidades, ela pode se tornar difícil de entender, manter e modificar. Mudanças em uma responsabilidade podem afetar inadvertidamente outra responsabilidade, levando a consequências indesejadas e bugs. Ao seguir o SRP, podemos criar código mais modular, fácil de entender e menos propenso a erros.

Vejamos um exemplo que viola o SRP:

class Marcador {
    String nome;
    String cor;
    int preco;

    public Marcador(String nome, String cor, int preco) {
        this.nome = nome;
        this.cor = cor;
        this.preco = preco;
    }
}

O código acima define uma classe Marcador simples com três variáveis de instância – nome, cor e preco.

class Fatura {
    private Marcador marcador;
    private int quantidade;

    public Fatura(Marcador marcador, int quantidade) {
        this.marcador = marcador;
        this.quantidade = quantidade;
    }

    public int calcularTotal() {
        return marcador.preco * this.quantidade;
    }

    public void imprimirFatura() {
        // implementação de impressão
    }

    public void salvarNoBancoDeDados() {
        // implementação de salvamento no banco de dados
    }
}

A classe Fatura acima viola o SRP porque tem várias responsabilidades – é responsável por calcular o valor total, imprimir a fatura e salvar a fatura no banco de dados. Como resultado, se a lógica de cálculo mudar, como a adição de impostos, o método calcularTotal() precisaria ser modificado. Do mesmo modo, se a implementação de impressão ou salvamento no banco de dados mudar em algum momento, a classe precisaria ser alterada.

Existem vários motivos para a classe ser modificada, o que pode levar ao aumento dos custos de manutenção e complexidade.

Veja como você pode modificar o código para seguir o SRP:

class Fatura {
    private Marcador marcador;
    private int quantidade;

    public Fatura(Marcador marcador, int quantidade) {
        this.marcador = marcador;
        this.quantidade = quantidade;
    }

    public int calcularTotal() {
        return marcador.preco * this.quantidade;
    }
}

class FaturaDao {
    private Fatura fatura;

    public FaturaDao(Fatura fatura) {
        this.fatura = fatura;
    }

    public void salvarNoBancoDeDados() {
        // implementação de salvamento no banco de dados
    }
}

class ImpressoraDeFatura {
    private Fatura fatura;

    public ImpressoraDeFatura(Fatura fatura) {
        this.fatura = fatura;
    }

    public void imprimirFatura() {
        // implementação de impressão
    }
}

Neste exemplo refatorado, dividimos as responsabilidades da classe Fatura em três classes separadas: Fatura, FaturaDao e ImpressoraDeFatura.

A classe Fatura é responsável apenas por calcular o valor total, e as responsabilidades de impressão e salvamento foram delegadas a classes separadas. Isso torna o código mais modular, fácil de entender e menos propenso a erros.

O que é o princípio aberto-fechado?

O princípio aberto-fechado (OCP) afirma que entidades de software (classes, módulos, funções e assim por diante) devem ser abertas para extensão, mas fechadas para modificação. Isso significa que o comportamento de uma entidade de software pode ser estendido sem modificar seu código-fonte.

O OCP é essencial porque promove a extensibilidade e a manutenibilidade do software. Ao permitir que entidades de software sejam estendidas sem modificação, os desenvolvedores podem adicionar novas funcionalidades sem o risco de quebrar o código existente. Isso resulta em código mais fácil de manter, estender e reutilizar.

Vejamos o exemplo anterior novamente.

class FaturaDao {
    private Fatura fatura;

    public FaturaDao(Fatura fatura) {
        this.fatura = fatura;
    }

    public void salvarNoBancoDeDados() {
        // implementação de salvamento no banco de dados
    }
}

A classe FaturaDao tem a responsabilidade única de salvar a fatura no banco de dados. Suponha, no entanto, que haja um novo requisito para salvar a fatura em um arquivo também. Uma maneira de implementar esse requisito seria modificar a classe FaturaDao existente adicionando um método salvarEmArquivo(). Isso, contudo, viola o princípio aberto-fechado porque modifica o código existente que já foi testado e está em produção.

Para seguir o OCP, uma solução melhor seria criar uma interface FaturaDao e implementá-la separadamente para salvamento em banco de dados e arquivo, conforme mostrado abaixo:

interface FaturaDao {
    public void salvar(Fatura fatura);
}

class FaturaDaoBancoDeDados implements FaturaDao {
    @Override
    public void salvar(Fatura fatura) {
        // implementação de salvamento no banco de dados
    }
}

class FaturaDaoArquivo implements FaturaDao {
    @Override
    public void salvar(Fatura fatura) {
        // implementação de salvamento em arquivo
    }
}

Desse modo, se houver um novo requisito para salvar a fatura em outro armazenamento de dados, você pode implementar uma nova implementação de FaturaDao sem modificar o código existente. Agora, a interface FaturaDao está aberta para extensão e fechada para modificação, o que segue o OCP.

O que é o princípio da substituição de Liskov?

O princípio da substituição de Liskov (LSP) afirma que qualquer instância de uma classe derivada deve ser substituível por uma instância de sua classe base sem afetar a correção do programa.

Em outras palavras, uma classe derivada deve se comportar como sua classe base em todos os contextos. Em termos mais simples, se a classe A é um subtipo da classe B, você deve ser capaz de substituir B por A sem quebrar o comportamento do seu programa.

A importância do LSP reside em sua capacidade de garantir que o comportamento de um programa permaneça consistente e previsível ao substituir objetos de classes diferentes. Violar o LSP pode levar a comportamento inesperado, bugs e problemas de manutenibilidade.

Vejamos um exemplo.

interface VeiculoDeDuasRodas {
    void ligarMotor();

    void acelerar();
}

No exemplo dado, a interface VeiculoDeDuasRodas tem dois métodos, ligarMotor() e acelerar(). Duas classes implementam essa interface, Motocicleta e Bicicleta.

class Motocicleta implements VeiculoDeDuasRodas {

    boolean motorLigado;
    int velocidade;

    @Override
    public void ligarMotor() {
        motorLigado = true;
    }

    @Override
    public void acelerar() {
        velocidade += 5;
    }
}

Motocicleta implementa corretamente o método ligarMotor(), pois define o booleano motorLigado como verdadeiro. Ele também implementa corretamente o método acelerar() aumentando a velocidade em 5.

class Bicicleta implements VeiculoDeDuasRodas {

    boolean motorLigado;
    int velocidade;

    @Override
    public void ligarMotor() {
        throw new AssertionError("Não há motor!");
    }

    @Override
    public void acelerar() {
        velocidade += 5;
    }
}

No entanto, a classe Bicicleta lança um AssertionError no método ligarMotor() porque não tem motor. Isso significa que uma instância de VeiculoDeDuasRodas não pode ser substituída por uma instância de Bicicleta sem quebrar o comportamento do programa.

Em outras palavras, se a classe Bicicleta for considerada um subtipo da interface VeiculoDeDuasRodas, de acordo com o LSP, qualquer instância de VeiculoDeDuasRodas deve ser substituível por uma instância de Bicicleta sem alterar a correção do programa.

Neste caso, porém, isso não é verdade, porque Bicicleta lança um AssertionError ao tentar ligar o motor. Portanto, o código viola o LSP.

O que é o princípio da segregação de interface?

O princípio da segregação de interface (ISP) se concentra no design de interfaces que são específicas para as necessidades de seus clientes. Ele afirma que nenhum cliente deve ser forçado a depender de métodos que não usa.

O princípio sugere que em vez de criar uma interface grande, que cubra todos os métodos possíveis, é melhor criar interfaces menores e mais focadas para casos de uso específicos. Essa abordagem resulta em interfaces mais coesas e menos acopladas.

Considere uma interface Veiculo como abaixo:

interface Veiculo {
    void ligarMotor();
    void desligarMotor();
    void dirigir();
    void voar();
}

E então você tem uma classe chamada Carro que implementa a interface Veiculo:

class Carro implements Veiculo {

    @Override
    public void ligarMotor() {
        // implementação
    }

    @Override
    public void desligarMotor() {
        // implementação
    }

    @Override
    public void dirigir() {
        // implementação
    }

    @Override
    public void voar() {
        throw new UnsupportedOperationException("Este veículo não pode voar.");
    }
}

Neste exemplo, a interface Veiculo tem muitos métodos. A classe Carro é forçada a implementar todos eles, embora não possa voar. Isso viola o ISP porque a interface Veiculo não é segregada adequadamente em interfaces menores com base na funcionalidade relacionada.

Vamos entender como você pode seguir o ISP aqui. Suponha que você refatore a interface Veiculo em interfaces menores e mais focadas:

interface Dirigivel {
    void ligarMotor();
    void desligarMotor();
    void dirigir();
}

interface Voador {
    void voar();
}

Agora, você pode ter uma classe chamada Carro, que implementa apenas a interface Dirigivel:

class Carro implements Dirigivel {

    @Override
    public void ligarMotor() {
        // implementação
    }

    @Override
    public void desligarMotor() {
        // implementação
    }

    @Override
    public void dirigir() {
        // implementação
    }
}

Graças à segregação de interface, você pode ter outra classe chamada Aviao, que implementa as interfaces Dirigivel e Voador:

class Aviao implements Dirigivel, Voador {

    @Override
    public void ligarMotor() {
        // implementação
    }

    @Override
    public void desligarMotor() {
        // implementação
    }

    @Override
    public void dirigir() {
        // implementação
    }

    @Override
    public void voar() {
        // implementação
    }
}

Neste exemplo, você segregou adequadamente a interface Veiculo em interfaces menores com base na funcionalidade relacionada. Isso adere ao ISP e torna seu código mais flexível e manutenível.

O que é o princípio da inversão de dependência?

O princípio da inversão de dependência (DIP) afirma que módulos de alto nível não devem depender de módulos de baixo nível, mas ambos devem depender de abstrações. Abstrações não devem depender de detalhes – detalhes devem depender de abstrações.

Esse princípio visa reduzir o acoplamento entre módulos, aumentar a modularidade e tornar o código mais fácil de manter, testar e estender.

Por exemplo, considere um cenário em que você tem uma classe que precisa usar uma instância de outra classe. Na abordagem tradicional, a primeira classe criaria diretamente uma instância da segunda classe, levando a um acoplamento forte entre elas. Isso torna difícil alterar a implementação da segunda classe ou testar a primeira classe independentemente.

Se, contudo, você aplicar o DIP, a primeira classe dependeria de uma abstração da segunda classe em vez da implementação. Isso tornaria possível alterar facilmente a implementação e testar a primeira classe independentemente.

Aqui está um exemplo que viola o DIP:

class CondicoesDoTempo {
    private String condicoesAtuais;
    private EnviadorDeEmail enviadorDeEmail;

    public CondicoesDoTempo() {
        this.enviadorDeEmail = new EnviadorDeEmail();
    }

    public void setCondicoesAtuais(String descricaoDoTempo) {
        this.condicoesAtuais = descricaoDoTempo;
        if (descricaoDoTempo == "chuvoso") {
            enviadorDeEmail.enviarEmail("Está chuvoso");
        }
    }
}

class EnviadorDeEmail {
    public void enviarEmail(String mensagem) {
        System.out.println("Email enviado: " + mensagem);
    }
}

Neste exemplo, a classe CondicoesDoTempo cria diretamente uma instância da classe EnviadorDeEmail, tornando-a fortemente acoplada à implementação. Isso torna difícil alterar a implementação da classe EnviadorDeEmail ou testar a classe CondicoesDoTempo independentemente.

Aqui está um exemplo de como aplicar o DIP ao código acima:

interface Notificador {
    public void alertarCondicoesDoTempo(String descricaoDoTempo);
}

class CondicoesDoTempo {
    private String condicoesAtuais;
    private Notificador notificador;

    public CondicoesDoTempo(Notificador notificador) {
        this.notificador = notificador;
    }

    public void setCondicoesAtuais(String descricaoDoTempo) {
        this.condicoesAtuais = descricaoDoTempo;
        if (descricaoDoTempo == "chuvoso") {
            notificador.alertarCondicoesDoTempo("Está chuvoso");
        }
    }
}

class EnviadorDeEmail implements Notificador {
    public void alertarCondicoesDoTempo(String descricaoDoTempo) {
        System.out.println("Email enviado: " + descricaoDoTempo);
    }
}

class SMS implements Notificador {
    public void alertarCondicoesDoTempo(String descricaoDoTempo) {
        System.out.println("SMS enviado: " + descricaoDoTempo);
    }
}

Neste exemplo, criamos uma interface Notificador que define o método alertarCondicoesDoTempo. A classe CondicoesDoTempo agora depende dessa interface em vez da classe EnviadorDeEmail, tornando possível alterar facilmente a implementação e testar a classe CondicoesDoTempo independentemente.

Também criamos duas implementações da interface Notificador, EnviadorDeEmail e SMS, para demonstrar como você pode alterar a implementação da classe CondicoesDoTempo sem afetar seu comportamento.

Conclusão

Neste artigo, você aprendeu sobre os princípios SOLID, que são uma parte muito importante dos princípios de design em geral.

Ao aplicar esses princípios em seus projetos de desenvolvimento de software, você pode criar código mais fácil de manter, estender e modificar, levando a um software mais robusto, flexível e reutilizável. Isso também levará a uma colaboração melhor entre os membros da equipe, à medida que o código se torna mais modular e fácil de trabalhar.

Para mais tutoriais como este, acompanhe o editorial do freeCodeCamp em português.

Tradução em português europeu

Este artigo é um resumo do que estou a escrever no meu projeto mais recente, solidbook.io - The Handbook to Software Design and Architecture with TypeScript (link em inglês). Dá uma vista de olhos por lá se gostares desta publicação.

É uma loucura para mim considerar o facto do Facebook ter sido em tempos um ficheiro de texto vazio no computador de alguém. 🤣

Neste último ano, tenho-me esforçado muito em design e arquitetura de software, Design Orientado a Domínio (link em inglês) e a escrever um livro sobre isso, e queria tirar um tempo para tentar juntar as peças todas em algo útil que pudesse partilhar com a comunidade.

Aqui está o meu roteiro para como aprender design e arquitetura de software.

Dividi-o em duas partes: o stack (pilha) e o map (mapa).

O stack

De modo semelhante ao modelo OSI em redes, cada camada é construída sobre a base da camada anterior.

O map

Embora eu ache que a pilha é boa para ver o panorama geral de como tudo funciona em conjunto, o mapa é um pouco mais detalhado (e inspirado pelo roteiro do programador web – link em inglês) e, como resultado, penso que seja mais útil.

Aqui está ele! Para duplicar o repositório, ler a minha redação detalhada e fazer o download em alta resolução, clica aqui.

Nota da tradução: houve uma revisão do conteúdo em março deste ano. Caso deseje acessar o conteúdo mais recente (em inglês) acesse aqui.

Fase 1: código limpo

O primeiro passo em direção à criação de software duradouro é descobrir como escrever código limpo.

Código limpo é código que é fácil de compreender e alterar. Logo no início, isto manifesta-se em algumas escolhas de design como:

• Ser consistente
• Dar preferência a nomes significativos de variáveis, métodos e classes em vez de explicar em comentários
• Garantir que o código está corretamente indentado e espaçado
• Garantir que todos os testes possam ser executados
• Escrever funções puras sem efeitos secundários
• Não passar nulos

Escrever código limpo é incrivelmente importante

Pensa nisso como se fosse o jogo do Jenga.

De modo a manter a estrutura do nosso projeto estável ao longo do tempo, coisas como indentação, pequenas classes e métodos, e nomes significativos, compensam bastante a longo termo.

O melhor recurso para aprender como escrever código limpo é livro de Uncle Bob, "Código Limpo" (link em inglês).

Fase 2: paradigmas de programação

Agora que estamos a escrever código legível que é fácil de fazer a manutenção, seria uma boa ideia compreender realmente os 3 maiores paradigmas da programação e a maneira como influenciam o nosso modo de escrever código.

No livro de Uncle Bob, "Arquitetura Limpa" (link em inglês), ele destaca que:

• Programação Orientada a Objetos é a ferramenta mais adequada para definir como passamos limites arquitetónicos com polimorfismo e plugins
• Programação funcional é a ferramenta que utilizamos para enviar dados para os limites das nossas aplicações
• E programação estruturada é a ferramenta que utilizamos para escrever algoritmos

Isso implica que o software eficiente utiliza uma mistura de todos estes 3 estilos de paradigmas de programação em alturas diferentes.

Embora possas adotar uma abordagem estritamente funcional ou estritamente orientada a objetos para escrever código, compreender onde cada um deles se destaca melhorará a qualidade dos teus designs.

Se tudo o que tiveres for um martelo, tudo se parece com um prego.

Recursos

Para programação funcional, dá uma vista de olhos:

• Guia Maioritariamente Adequado do Professor Frisby para Programação Funcional (link em inglês)
• Modelação de Domínio Tornada Funcional (link em inglês)

Fase 3: programação orientada a objetos

É importante saber como cada um dos paradigmas funciona e como te incentivam a estruturar o código dentro deles, mas no que diz respeito à arquitetura, Programação Orientada a Objetos é claramente a ferramenta ideal para o trabalho.

A programação Orientada a Objetos não só nos permite criar uma arquitetura de plugin e criar flexibilidade nos nossos projetos; Programação Orientada a Objetos vem com 4 princípios de Programação Orientada a Objetos (encapsulamento, herança, polimorfismo e abstração) que nos ajudam a criar modelos de domínio ricos.

A maior parte dos programadores a aprender Programação Orientada a Objetos nunca chega a essa parte: aprender como criar uma implementação de software para o domínio do problema, e localizá-la no centro de uma aplicação web com camadas.

Programação funcional pode parecer a solução para todos os problemas nesse cenário, mas eu recomendo familiarizar-te com o design orientado a modelos e Design Orientado a Domínio para compreender o panorama de como os modeladores de objetos são capazes de encapsular um negócio completo com um modelo de domínio com zero dependências.

Por que é que isso é importante?

É muito importante porque, se podes criar um modelo mental de um negócio, podes criar uma implementação de software desse negócio.

Fase 4: princípios de design

Neste momento, a tua compreensão de que a Programação Orientada a Objetos é muito útil para encapsular modelos de domínio ricos e para resolver o terceiro tipo de "Problemas de Software Difíceis"– Domínios Complexos (link em inglês).

No entanto, a Programação Orientada a Objetos pode introduzir alguns desafios de design.

Onde devo utilizar composição?

Quando devo utilizar herança?

Quando devo utilizar uma classe abstrata?

Princípios de design são boas práticas muito bem estabelecidas e testadas que podes utilizar como segurança.

Alguns exemplos de princípios de design comuns com que te deves familiarizar são:

• Composição sobre herança
• Encapsular o que varia
• Programar contra abstrações, não concreções
• O princípio de Hollywood: "Não nos chames, nós chamamos-te"
• Os princípios SOLID, especialmente o princípio de responsabilidade singular
• DRY (Do Not Repeat Yourself – Não te Repitas, em português)
• YAGNI (You Aren't Gonna Need It, Não Vais Precisar Disso, em português)

Certifica-te de que alcanças as tuas próprias conclusões, no entanto. Não te limites a seguir o que outra pessoa diga que deves fazer. Certifica-te que faz sentido para ti.

Fase 5: padrões de design

Praticamente todos os problemas de software já foram categorizados e resolvidos em algum momento. Chamamos a esses padrões: padrões de design, na verdade.

Existem 3 categorias de padrões de design: criativo, estrutural e comportamental.

Criativo

Padrões criativos são padrões que controlam como os objetos são criados.

Exemplos de padrões criativos incluem:

• O padrão Singleton, para garantir que existe uma única instância de uma classe.
• O padrão Abstract Factory, para criar uma instância de várias famílias de classes.
• O padrão Prototype, para começar com uma instância que é clonada a partir de uma já existente.

Estrutural

Padrões estruturais que simplificam como definimos relações entre componentes.

Exemplos de padrões de design estruturais incluem:

• O padrão Adapter, para criar uma interface para acionar classes que normalmente não funcionam em conjunto, para funcionarem em conjunto.
• O padrão Bridge, para dividir uma classe que deve ser um ou mais, num conjunto de classes que pertencem a uma hierarquia, permitindo que as implementações sejam desenvolvidas de forma independente umas das outras.
• O padrão Decorator, para adicionar responsabilidades a objetos dinamicamente.

Comportamental

Padrões comportamentais são padrões comuns para facilitar comunicações elegantes entre objetos.

Exemplos de padrões comportamentais são:

• O padrão Template, para diferir os passos exatos de um algoritmo para uma subclasse.
• O padrão Mediator, para definir os canais de comunicação exatos permitidos entre classes.
• O padrão Observer, para habilitar classes para descrever algo de interesse e para notificar quando ocorrer uma alteração.

Criticas sobre o padrão de design

Padrões de design são bons, mas por vezes podem trazer complexidade extra aos nossos designs. É importante lembrar o YAGNI e tentar manter os nossos designs tão simples quanto possível. Utiliza apenas padrões de design quando tiveres mesmo a certeza que precisas deles. Saberás quando for o momento.

Se soubermos o que cada um destes padrões faz, quando utilizá-los, e quando nem sequer nos preocuparmos em utilizá-los, estaremos em boa forma para começar a compreender como fazer a arquitetura de sistemas complexos.

A razão por trás disso é que padrões arquitetónicos são simplesmente padrões de design com a escala elevada para alto nível, enquanto que os padrões de design são implementações de baixo nível (mais próximas a classes e funções).

Recursos

Refactoring Guru - Padrões de Design (link em inglês)

Fase 6: princípios arquitetónicos

Agora estás num nível de pensamento mais elevado do que o nível de classe.

Compreendemos que as decisões que tomamos para organizar e criar relações entre componentes, a nível elevado e a nível baixo, vão ter um impacto significativo na facilidade de manutenção, flexibilidade e capacidade de testagem do nosso projeto.

Aprende os princípios orientadores que te ajudam a criar a flexibilidade que o teu código-base necessita para ser capaz de reagir a novas funcionalidades e exigências, com o mínimo esforço possível.

Aqui está o que eu recomendo que aprendas logo à partida:

• Princípios de design de componentes: o Princípio de Abstração Estável (link em inglês), o Princípio de Dependência Estável (link em inglês), e o Princípio de Dependência Acíclica, para como organizar componentes, as suas dependências, quando juntá-las, e as implicações de criar acidentalmente ciclos de dependência e depender de componentes instáveis.
• Política x Detalhe (Link em inglês), para compreender como separar as regras da tua aplicação a partir dos detalhes de implementação.
• Limites e como identificar os subdomínios a que as funcionalidades da tua aplicação pertencem.

O Uncle Bob descobriu e documentou originalmente muitos destes princípios. Então, o melhor recurso para aprender isto é, novamente, "Arquitetura Limpa" (link em inglês).

Fase 7: estilos arquitetónicos

Arquitetura é sobre as coisas que importam.

É sobre identificar as necessidades do sistema de maneira a que este seja bem-sucedido e de seguida aumentar as hipóteses de sucesso ao escolher a arquitetura que melhor se adequa aos requisitos.

Por exemplo, um sistema que tem muita complexidade de lógica de negócio beneficiaria da utilização de uma arquitetura por camadas para encapsular essa complexidade.

Um sistema como a Uber precisa de ser capaz de lidar com muitos eventos em tempo real de uma só vez e atualizar a localização do condutor, então, um estilo de arquitetura publicar-subscrever poderia ser o mais eficaz.

Vou-me repetir a mim mesmo aqui porque é importante observar que as 3 categorias de estilos arquitetónicos são semelhantes às 3 categorias de padrões de design, porque estilos arquitetónicos são padrões de design de alto nível.

Estrutural

Projetos com níveis variantes de componentes e grande intervalo de funcionalidades beneficiarão ou serão prejudicados pela adopção de uma arquitetura estrutural.

Aqui estão alguns exemplos:

• Arquiteturas com base em componentes enfatizam separação de preocupações entre os componentes individuais dentro de um sistema. Imagina a Google por um segundo. Considera quantas aplicações eles têm dentro da empresa (Google Docs, Google Drive, Google Maps, etc). Para plataformas com muitas funcionalidades, arquiteturas com base em componentes dividem as preocupações em componentes independentes vagamente agrupados. Isto é uma separação horizontal.
• Monolítico significa que a aplicação é combinada numa única plataforma ou programa, implementada completamente. Observação: podes ter uma arquitetura com base em componentes E monolítica se separares as tuas aplicações adequadamente, enquanto implementas tudo em conjunto.
• Arquiteturas por camadas separam verticalmente as preocupações ao dividir o software em camadas de infraestrutura, aplicação e domínio.

Um exemplo de corte das responsabilidades/preocupações de uma aplicação de modo vertical usando uma arquitetura de camadas. Lê aqui (texto em inglês) para obter mais informações sobre como fazer isso.

Mensagens

Dependendo do teu projeto, enviar mensagens pode ser um componente realmente importante para o sucesso do sistema. Para projetos como esse, arquiteturas com base em mensagens criadas sobre princípios de programação funcional e padrões de design comportamental como o padrão observer.

Aqui estão alguns exemplos de estilos de arquiteturas com base em mensagens:

• Arquiteturas Orientadas por Eventos vêm todas as alterações significativas a estados como eventos. Por exemplo, numa aplicação de venda de discos de vinil, o estado de uma oferta pode alterar de "pendente" para "aceite" quando ambas as partes concordam com a troca.
• Arquiteturas Publicar-subscrever são criadas sobre o padrão de design Observer ao fazer com que seja o método de comunicação principal entre o próprio sistema, utilizadores finais/clientes, e outros sistemas e componentes.

Distributivo

Uma arquitetura distributiva significa simplesmente que os componentes do sistema são implementados separadamente e operam ao comunicar num protocolo de rede. Sistemas distributivos podem ser muito eficazes para escalar a taxa de transferência, escalar equipas e delegar (tarefas potencialmente caras) responsabilidades a outros componentes.

Alguns exemplos de estilos de arquiteturas distributivas são:

• Arquitetura client-servidor. Uma das arquiteturas mais comuns, onde dividimos o trabalho a ser feito entre o client (apresentação) e o servidor (lógica de negócio).
• Arquiteturas ponto-a-ponto distribuem tarefas de camada de aplicação entre participantes igualmente privilegiados, formando uma rede ponto-a-ponto.

Fase 8: padrões arquitetónicos

Padrões arquitetónicos explicam em grande detalhe tático como realmente implementar um destes estilos arquitetónicos.

Aqui estão alguns exemplos de padrões arquitetónicos e os estilos que estes herdam:

• Design Orientado a Domínio é uma abordagem ao desenvolvimento de software para problemas de domínio realmente complexos. Para que o design orientado a domínio seja bem-sucedido, precisamos de implementar uma arquitetura de camadas de maneira a separar as preocupações de um modelo de domínio dos detalhes infra-estruturais que fazem a aplicação realmente executar, como bases de dados, servidores web, caches etc.
• Controlador Modelo-Vista é provavelmente o padrão arquitetónico mais conhecido para desenvolver aplicações baseadas na interface de utilizador. Funciona ao dividir a aplicação em 3 componentes: modelo, vista e controlador. O controlador modelo-vista é incrivelmente útil quando estás no início e ajuda-te a aproveitar outras arquiteturas, mas existe uma altura em que percebemos que o controlador Modelo-Vista não é suficiente para problemas com muita lógica de negócio.
• Fornecimento de eventos é uma abordagem funcional onde armazenamos apenas as transações e nunca o estado. Se alguma vez precisarmos do estado, podemos aplicar todas as transações desde o início.

Fase 9: padrões empresariais

Qualquer padrão arquitetónico que escolhas introduzirá um número de construções e linguagem especializada para te familiarizares e decidir se vale a pena o esforço ou não.

Ao pegar num exemplo que muitos de nós conhecemos, no Controlador Modelo-Vista, a vista armazena todo o código da camada de apresentação, o controlador é comandos de tradução e consultas da vista para pedidos que são tratados pelo modelo e retornados pelo controlador.

Em que parte do Modelo (M) lidamos com estas coisas?:

• Lógica de validação
• Regras invariáveis
• Eventos de domínio
• Casos de utilização
• Consultas complexas
• E lógica empresarial

Se simplesmente utilizarmos um ORM (object-relational mapper) como Sequelize ou TypeORM como o modelo, todas essas coisas importantes são deixadas para interpretação onde devem estar, e acabam por ficar numa capada não especificada entre o (que deveria ser um rico) modelo e o controlador.

Retirado de "3.1 - Slim (Logic-less) models" em solidbook.io (link em inglês).

Se existe alguma coisa que eu tenha aprendido até agora na minha jornada para lá do controlador modelo-vista, é que existe uma construção para tudo.

Para cada uma destas coisas em que o Controlador Modelo-Vista falha em abordar, existem outros padrões empresariais para resolvê-las. Por exemplo:

• Entidades (link em inglês) descrevem modelos que têm uma identidade.
• Objetos de valor (link em inglês) são modelos que não têm identidade e podem ser utilizados de modo a encapsular a lógica de validação.
• Eventos de domínio (link em inglês) são eventos que significam algum evento empresarial relevante a acontecer e podem ser subscritos de outros componentes.

Com base no estilo arquitetónico que tiveres escolhido, vão existir muitos outros padrões empresariais para aprenderes de maneira a implementar esse padrão no seu potencial máximo.

Padrões de integração

Assim que a tua aplicação estiver operacional, à medida que recebes mais e mais utilizadores, podes obter alguns problemas de desempenho. Chamadas de API podem demorar muito tempo, os servidores podem quebrar por estares sobrecarregados de pedidos etc. Para resolver esses problemas, podes ler sobre a integração de coisas como consulta de mensagens ou caches de modo a melhorar o desempenho.

Estas são provavelmente as coisas mais desafiantes: escalar, auditar e desempenho.

Desenhar um sistema para escala pode ser incrivelmente desafiante. Isto requer uma compreensão profunda sobre as limitações de cada componente dentro da arquitetura e um plano de ação para como mitigar o stress na tua arquitetura e continuar a servir pedidos em situações de grande tráfego.

Existe também a necessidade de auditar o que está a acontecer na tua aplicação. Grandes empresas precisam de ser capazes de fazer auditorias de modo a identificar potenciais problemas de segurança, compreender como os utilizadores estão a utilizar as suas aplicações, e ter um registo de tudo o que aconteceu até agora.

Isso pode ser desafiante de implementar, mas as arquiteturas comuns acabam por parecer baseadas em eventos e são criadas sobre uma grande variedade de conceitos de design de software e sistemas, princípios e práticas como Event Storming, DDD, CQRS (command query response segregation) e Event Sourcing.

O autor do artigo original criou o boletim informativo Git Better para ajudar a aprender novos truques e tópicos avançados do Git. Se você está interessado em melhorar no Git, você deve definitivamente dar uma olhada nisso.

Se você usa o Git há algum tempo, pode já ter usado o Git stash. É um dos recursos úteis do Git.

Aqui estão alguns dos truques úteis que aprendi sobre o Git stash na semana passada.

1. Git stash save
2. Git stash list
3. Git stash apply
4. Git stash pop
5. Git stash show
6. Git stash branch <nome>
7. Git stash clear
8. Git stash drop

Git stash save

Este comando é como o Git stash. Porém, ele vem com várias opções. Vou discutir algumas opções importantes neste artigo.

Git stash com mensagem

git stash save "Sua mensagem para o stash".

O comando acima armazena (stash, em inglês) e deixa uma mensagem. Veremos como isso é útil em instantes.

Armazenando arquivos não rastreados

Você também pode armazenar arquivos não rastreados.

git stash save -u

ou

git stash save --include-untracked

Git stash list

Antes de discutir este comando, deixe-me dizer algo sobre como o stash funciona.

Quando você usa Git stash ou Git stash save, o Git, de fato, criará um objeto Git commit com algum nome e o salvará em seu repositório.

Isso significa que você pode visualizar a lista de stashes que fez a qualquer momento.

git stash list

Veja o exemplo abaixo:

Você pode ver a lista de stashes feitos. O stash mais recente feito está no topo.

Você pode ver que o stash superior recebe uma mensagem personalizada (usando Git stash save "mensagem").

Git stash apply

Este comando pega o stash mais alto na pilha e o aplica ao repositório. No nosso caso, é stash@{0}.

Se você deseja aplicar algum outro stash, pode especificar o ID desse stash.
Aqui está o exemplo:

git stash apply stash@{1}

Git stash pop

Este comando é muito semelhante ao stash apply, mas exclui o stash da pilha depois de aplicado.

Aqui está o exemplo:

Como você pode ver, o stash superior foi excluído e o stash@{0} foi atualizado com o stash mais antigo.

Do mesmo modo, se você deseja que um stash específico apareça, você pode especificar o id do stash

git stash pop stash@{1}

Git stash show

Este comando mostra o resumo das diferenças dos stashes. O comando acima considera apenas o stash mais recente.

Aqui está o exemplo:

Se você quiser ver a diferença completa, pode usar o seguinte:

git stash show -p

Da mesma forma como ocorre com outros comandos, você também pode especificar o stash id para obter o resumo das diferenças.

git stash show stash@{1}

Git stash branch <nome>

Este comando cria uma branch (em português, ramificação) com o stash mais recente e, em seguida, exclui o stash mais recente (como stash pop).

Se você precisar de um stash específico, poderá especificar o ID do stash.

git stash branch <nome> stash@{1}

Isso será útil quando você se deparar com conflitos depois de aplicar o stash à versão mais recente da sua branch.

Git stash clear

Este comando exclui todos os stashes feitos no repositório. Talvez seja impossível revertê-lo.

Git stash drop

Este comando exclui o stash mais recente da pilha. Use-o com cautela, pois pode ser difícil revertê-lo.

Você também pode especificar o ID do stash.

git stash drop stash@{1}

Espero que você tenha aprendido alguns truques úteis sobre o Git stash.

Se você chegou até aqui, imagino que esteja bem interessado no Git. Confira o boletim informativo Git Better do autor para aprender novos truques e tópicos avançados do Git. :)

Se você gostou do artigo, compartilhe-o. 😀

Escrito por: Angela Zhang

Como engenheira de software, eu passo muito tempo lendo e escrevendo documentos de design. Após ter passado por centenas desses documentos, vi em primeira mão uma forte correlação entre bons documentos de design e o sucesso final do projeto.

Este artigo é minha tentativa de descrever o que torna ótimo um documento de design.

O artigo é dividido em 4 seções:

• Por que escrever um documento de design
• O que incluir em um documento de design
• Como escrevê-lo
• O processo que o envolve

Por que escrever um documento de design?

Um documento de design – também conhecido como especificação técnica – é uma descrição de como você planeja resolver um problema.

Já existem muitos escritos (textos em inglês) sobre a importância de escrever um documento de design antes de começar a programar. Portanto, tudo o que vou dizer aqui é:

Um documento de design é a ferramenta mais útil para garantir que o trabalho certo seja feito.

O principal objetivo de um documento de design é torná-lo mais eficaz, forçando você a pensar no design e a obter feedback dos outros. As pessoas frequentemente pensam que o objetivo de um documento de design é ensinar aos outros sobre algum sistema ou servir como documentação mais tarde. Embora esses possam ser efeitos colaterais benéficos, eles não são o objetivo em si.

Como regra geral, se você estiver trabalhando em um projeto que pode levar um mês ou mais de engenharia, você deve escrever um documento de design. Porém, não pare por aí – muitos projetos menores também poderiam se beneficiar de um minidocumento de design.

Ótimo! Se você ainda está lendo, você acredita na importância dos documentos de design. Entretanto, equipes de engenharia diferentes e até mesmo engenheiros dentro de uma mesma equipe, muitas vezes, escrevem documentos de design de modos muito diferentes. Portanto, vamos falar sobre o conteúdo, estilo e processo de um bom documento de design.

O que incluir em um documento de design?

Um documento de design descreve a solução para um problema. Como a natureza de cada problema é diferente, naturalmente, você gostaria de estruturar seu documento de design de modos diferentes.

Para começar, a seguir está uma lista de seções que você deve pelo menos considerar incluir em seu próximo documento de design:

Título e pessoas

O título de seu documento de design, os autores (que devem ser os mesmos da lista de pessoas que planejam trabalhar neste projeto), os revisores do documento (falaremos mais sobre isso na seção Processo, abaixo), e a data em que este documento foi atualizado pela última vez.

Visão geral

Um resumo de alto nível que todo engenheiro da empresa deve entender e usar para decidir se é útil para eles ler o resto do documento. Deve ter, no máximo, 3 parágrafos.

Contexto

Uma descrição do problema em questão, por que este projeto é necessário, o que as pessoas precisam saber para avaliar este projeto e como ele se encaixa na estratégia técnica, na estratégia do produto ou nas metas trimestrais da equipe.

Objetivos e não objetivos

A seção Objetivos deve:

• descrever o impacto de seu projeto – onde seu usuário pode ser outra equipe de engenharia ou mesmo outro sistema técnico
• especificar como medir o sucesso usando métricas – com ainda maior valor se você puder conectar a seção a um painel que rastreie essas métricas

"Não objetivos" são igualmente importantes para descrever quais problemas você não estará resolvendo para que todos saibam do que se está falando.

Marcos

Uma lista de pontos notáveis mensuráveis para que seu gerente de projeto e para que o gerente dele possam olhar a lista e saber aproximadamente quando diferentes partes do projeto estarão concluídas. Eu o encorajo a quebrar o projeto em marcos importantes para o usuário, se o projeto tiver mais de um mês de duração.

Use datas no calendário para levar em conta atrasos não relacionados, férias, reuniões e assim por diante. Deve ser algo parecido com isto:

Data de início: 7 de junho de 2022
Marco nº 1 — Novo MVP do sistema em funcionamento em modo escuro: 28 de junho de 2022
Marco nº 2 - Aposentar o sistema antigo: 4 de julho de 2022
Encerramento: Adicionar os recursos X, Y e Z ao novo sistema: 14 de julho de 2022

Adicione uma subseção [Atualização] se a data final de entrega de alguns desses marcos mudar, para que as partes interessadas possam facilmente ver as estimativas mais atualizadas.

Solução existente

Além de descrever a implementação atual, você também deve percorrer um fluxo de exemplo de alto nível para ilustrar como os usuários interagem com esse sistema e/ou como os dados fluem através dele.

Uma história de usuário é uma ótima maneira de enquadrar isto. Tenha em mente que seu sistema pode ter diferentes tipos de usuários com diferentes casos de uso.

Solução proposta

Algumas pessoas chamam isso de seção de Arquitetura técnica. Mais uma vez, percorra uma história de usuário para tornar isso concreto. Sinta-se à vontade para incluir muitas subseções e diagramas.

Forneça um quadro geral primeiro, depois preencha com muitos detalhes. Busque um mundo ideal onde você possa escrever essa seção e depois tirar férias em alguma ilha deserta, enquanto outro engenheiro da equipe pode simplesmente ler e implementar a solução do jeito que você a descreveu.

Soluções alternativas

O que mais você considerou quando chegou à solução acima? Quais são os prós e contras das alternativas? Você já considerou comprar uma solução de terceiros – ou usar uma solução de código aberto – que resolva esse problema em vez de criar sua própria solução?

Testabilidade, monitoramento e alerta

Gosto de incluir esta seção, porque as pessoas muitas vezes tratam essa parte como algo a se pensar depois ou simplesmente a ignoram. Quase sempre, isso volta para incomodar mais tarde, quando as coisas se quebram e eles não têm ideia de como ou por quê.

Impacto entre equipes

Como isso aumentará a carga de chamadas de solução de problemas e qual o impacto disso para a equipe de dev-ops?‌‌
Quanto dinheiro vai custar? ‌
‌Causa alguma regressão de latência para o sistema? ‌
Expõe alguma vulnerabilidade de segurança?
Quais são algumas das consequências negativas e dos efeitos colaterais? ‌
Como a equipe de suporte poderia comunicar isso aos clientes?

Perguntas abertas

Qualquer assunto em aberto sobre o qual você não tenha certeza, decisões controversas que você gostaria que os leitores ponderassem a respeito, sugestões de trabalho futuro e assim por diante. Um nome, de certo modo, irônica para esta seção são as "incógnitas conhecidas".

Escopo detalhado e linha de tempo

Esta seção será lida, em geral, apenas pelos engenheiros que trabalham neste projeto, seus líderes técnicos e seus gerentes. Portanto, esta seção pode ficar ao final do documento.

Essencialmente, esta é a divisão de como e quando você planeja executar cada parte do projeto. Há muita coisa que entra na delimitação precisa do escopo. Então, você pode ler este artigo (texto em inglês) para saber mais sobre a delimitação do escopo.

Também tenho a tendência de tratar esta seção do documento de design como um rastreador das tarefas em andamento. Portanto, eu a atualizo sempre que minha estimativa de escopo muda. Isso, porém, é mais uma preferência pessoal.

Como escrevê-lo

Agora que falamos sobre o que entra em um bom documento de design, vamos falar sobre o estilo de escrita. Prometo que será diferente de sua aula de inglês do ensino médio.

Escreva da maneira mais simples possível

Não tente escrever como os trabalhos acadêmicos que você leu. Eles são escritos para impressionar os revisores dos periódicos. Seu documento é escrito para descrever a sua solução e obter feedback de seus colegas de equipe. Você pode obter clareza ao usar:

• Palavras simples
• Frases curtas
• Listas com pontos e/ou listas numeradas
• Exemplos concretos, como "Usuário Alice conecta sua conta bancária, então ..."

Adicione muitos gráficos e diagramas

Os gráficos podem muitas vezes ser úteis para comparar várias opções potenciais. Os diagramas são, geralmente, mais fáceis de analisar do que o texto. Tive sorte com o aplicativo de Desenhos do Google para criar diagramas.

Dica profissional: lembre-se de adicionar um link para a versão editável do diagrama sob a captura de tela para que você possa facilmente atualizá-lo mais tarde quando as coisas mudarem inevitavelmente.

Inclua números

A escala do problema, muitas vezes, determina a solução. Para ajudar os revisores a ter uma noção do estado das coisas, inclua números reais como nº de linhas de bancos de dados, nº de erros de usuários, latência – e como isso é escalável com o uso. Lembra-se das suas notações de Big-O?

Tente ser engraçado

Uma especificação não é um trabalho acadêmico. Além disso, as pessoas gostam de ler coisas engraçadas. Então, essa é uma boa maneira de manter o leitor engajado. Não exagere, porém, a ponto de tirar o foco da ideia principal.

Se você, como eu, tem dificuldade em ser engraçado, Joel Spolsky (obviamente conhecido por seus talentos cômicos...) tem esta dica:

Uma das maneiras mais fáceis de ser engraçado é ser específico quando não é chamado para [Exemplo:] Em vez de dizer "pessoas com interesses especiais", dizer "cultivadores de abacate canhotos".

Faça o teste do cético

Antes de enviar seu documento de design a outras pessoas para revisão, examine-o fingindo ser o revisor. Quais perguntas e dúvidas você pode ter sobre este design? Então, trate-as de antemão.

Faça o teste das férias

Se você passar um tempo maior em férias e sem acesso à internet, alguém de sua equipe pode ler o documento e implementar as coisas do modo como você pretendia?

O principal objetivo de um documento de design não é o compartilhamento de conhecimento, mas é uma boa maneira de avaliar a clareza para que outros possam realmente dar a você um feedback útil.

Processo

Ah, sim, a temida palavra começando com P. Os documentos de design ajudam a obter feedback antes que você gaste muito tempo implementando a solução errada ou a solução para o problema errado. Há muita coisa envolvida em se obter um bom feedback, mas isso é para um artigo posterior. Por enquanto, vamos apenas falar especificamente sobre como escrever o documento de design e obter feedback para ele.

Antes de mais nada, todos que trabalham no projeto devem fazer parte do processo de design. Não é problema se a liderança tecnológica acabar impulsionando muitas das decisões, mas todos devem estar envolvidos na discussão e aderir ao design. Portanto, quando falamos "você" ao longo deste artigo, lembre-se de que ele se aplica a todas as pessoas no projeto.

Em segundo lugar, o processo de design não significa que você está olhando para as ideias teóricas do quadro branco. Sinta-se à vontade para colocar as mãos à obra e fazer um protótipo de soluções potenciais. Isso não é a mesma coisa que começar a escrever o código de produção para o projeto antes de escrever um documento de design. Não faça isso. Você deve, no entanto, se sentir absolutamente livre para escrever algum código enjambrado e que você possa descartar depois apenas para validar uma ideia. Para garantir que você só escreva código exploratório, faça com que seja uma regra que nenhum código desse protótipo seja inserido na branch master/main.

Depois disso, ao começar a ter alguma ideia de como realizar seu projeto, faça o seguinte:

1. Peça a um engenheiro ou líder técnico experiente em sua equipe para ser seu revisor. O ideal seria que fosse alguém bem respeitado e/ou familiarizado com os casos de ponta do problema. Convença-os com algum presentinho, se necessário.
2. Vá com o colega a uma sala de conferências com um quadro branco.
3. Descreva o problema que você está enfrentando para este engenheiro (este é um passo muito importante, não o pule!).
4. Explique a implementação que você tem em mente e convença o engenheiro de que esta é a coisa certa a ser construída.

Fazer tudo isso antes mesmo de começar a escrever seu documento de design permite que você receba feedback o mais rápido possível, antes de investir mais tempo e se apegar a qualquer solução específica. Muitas vezes, mesmo que a implementação permaneça a mesma, seu revisor é capaz de apontar os casos limite que você precisa cobrir, indicar quaisquer áreas potenciais de confusão e antecipar dificuldades que você possa encontrar mais tarde.

Então, depois de escrever um rascunho do seu documento de design, peça ao mesmo revisor que o leia novamente, e carimbe-o adicionando o seu nome como revisor na seção Título e Pessoas do documento de design. Isto cria um incentivo adicional e responsabilidade para o revisor.

Sobre essa nota, considere a adição de revisores especializados (tais como SREs e engenheiros de segurança) para aspectos específicos do design.

Assim que você e os revisores assinarem, sinta-se à vontade para enviar o documento de design à sua equipe para feedback adicional e compartilhamento de conhecimento. Sugiro que este processo de coleta de feedback seja limitado no tempo a cerca de 1 semana para evitar atrasos prolongados. Comprometa-se a responder a todas as perguntas e comentários que as pessoas deixarem durante essa semana. Deixar comentários pendentes = muito azar.

Finalmente, se houver muito conflito entre você, seu revisor e outros engenheiros que leem o documento, recomendo fortemente a consolidação de todos os pontos de conflito na seção Discussão do seu documento. Então, marque uma reunião com as diferentes partes para falar pessoalmente sobre essas discordâncias.

Sempre que um tópico de discussão tiver mais de 5 comentários, passar para uma discussão presencial tenderá a ser muito mais eficiente. Tenha em mente que você ainda é responsável por fazer a chamada final, mesmo que nem todos consigam chegar a um consenso.

Ao falar com um colega recentemente sobre isso, soube que ele tem um processo semelhante, exceto pelo fato de que, além de ter um engenheiro experiente ou líder técnico em sua equipe como revisor, eles também sugerem ter um engenheiro de uma equipe diferente para revisar o documento. Eu não tentei isso, mas certamente posso ver o quanto ajuda obter feedback de pessoas com perspectivas diferentes e melhorar a legibilidade geral do documento.

Uma vez que você tenha feito tudo o que vemos acima, é hora de começar a implementação! Para ganhar uns pontos a mais, trate este documento de projeto como um documento vivo à medida que você implementa o design. Atualize o documento toda vez que aprender algo que o leve a fazer mudanças na solução original ou atualizar seu escopo. Você vai me agradecer mais tarde quando não tiver que explicar as coisas repetidas vezes a todas as partes interessadas.

Por fim, vamos realmente fazer um metadiscurso por um segundo: Como avaliamos o sucesso de um documento de design?

Meu colega de trabalho, Kent Rakip, tem uma boa resposta para isso: Um documento de design é bem-sucedido se o ROI correto de trabalho for feito. Isso significa que um documento de design bem-sucedido pode realmente levar a um resultado como este:

1. Você gasta 5 dias escrevendo o documento de projeto, o que força você a pensar em diferentes partes da arquitetura técnica
2. Você recebe o feedback de revisores de que X é a parte mais arriscada da arquitetura proposta
3. Você decide implementar X primeiro para reduzir o risco do projeto
4. 3 dias depois, você descobre que X não é possível ou é muito mais difícil do que você pretendia originalmente
5. Você decide parar de trabalhar neste projeto e prioriza outros trabalhos em seu lugar

No início deste artigo, dissemos que o objetivo de um documento de design é garantir que o trabalho certo seja feito. No exemplo acima, graças a este documento de design, em vez de desperdiçar potencialmente meses apenas para abandonar este projeto mais tarde, você gastou apenas 8 dias. Parece-me um resultado muito bem-sucedido.

Para creditar aqueles que merecem, eu aprendi muito do que mostro acima ao trabalhar ao lado de alguns engenheiros incríveis na Plaid e na Quora.

Se você gostou deste artigo, siga a autora no Twitter para mais artigos sobre engenharia, processos e sistemas de back-end.

Os desenvolvedores precisam instalar as ferramentas de linha de comando do Xcode antes de começar a desenvolver software no Mac.

A Apple fornece um ambiente de desenvolvimento completo para os programadores, chamado de Xcode. Se estiver desenvolvendo software para o macOS, o iOS, o tvOS e o watchOS, deve instalar a aplicação completa do Xcode.

Se já não estiver pré-instalada, você pode instalá-la a partir do site do desenvolvedor da Apple ou da App Store no Mac.

O que são as ferramentas de linha de comando do Xcode?

Se não estiver desenvolvendo software para um dispositivo da Apple, você não precisa da aplicação completa do Xcode (são necessários 40GB de espaço em disco!).

Em vez disso, você pode instalar as ferramentas de linha de comando do Xcode. É um pacote pequeno para desenvolvedores de software com ferramentas que rodam na linha de comando, ou seja, na aplicação do Terminal.

Os programadores já usavam essas ferramentas nos sistemas operacionais do Unix desde o início da computação. Elas servem como base de quase todo o desenvolvimento de software.

Por sorte, o pacote das ferramentas de linha de comando do Xcode precisam apenas de 1,2 GB de espaço em disco.

Você tem três escolhas de instalação das ferramentas de linha de comando do Xcode no Mac:

• instalar o pacote completo do Xcode
• instalar as ferramentas de linha de comando do Xcode quando sugerido por um comando
• instalar as ferramentas de linha de comando do Xcode como parte de uma instalação do Homebrew.

Eu não recomendo instalar o pacote completo do Xcode a menos que você esteja desenvolvendo software para um dispositivo da Apple. O download demora muito e consome espaço em disco desnecessário. Em vez disso, tente um dos outros dois métodos, que são mais rápidos.

Como instalar as ferramentas de linha de comando do Xcode a partir de um prompt de comando

A Apple facilitou a instalação das ferramentas de linha de comando do Xcode, pois alguns comandos solicitarão que você comece a instalação.

Aqui temos exemplos de comandos que sugerirão a instalação das ferramentas de linha de comando do Xcode:

• clang – um compilador que transforma código fonte em um programa executável
• gcc – o compilador GNU
• git – o sistema de controle de versão que salva arquivos em processo

Ao rodar qualquer um desses comandos no Terminal, será solicitada a instalação das ferramentas de linha de comando do Xcode. Já fiz um artigo sobre como abrir o Terminal no MacOS (texto em inglês) – basta clicar no ícone do Spotlight, na barra de menu, e digitar “terminal.”

Você também pode inserir o comando xcode-select --install no terminal para começar o processo de instalação. Você verá um painel que pede que você instale as ferramentas de linha de comando do Xcode.

Clique em 'Install' para começar o download e o processo de instalação.

A instalação leva 8 minutos em um Mac M1 Mini de 2021, com uma conexão com a internet de 100Mbps. Ela é significativamente mais lenta no Mac Intel em uma conexão lenta com a internet.

Você verá uma mensagem de confirmação quando a instalação estiver concluída.

Verifique se você instalou com sucesso as ferramentas de linha de comando do Xcode:

$ xcode-select -p

Você verá o seguinte:

/Library/Developer/CommandLineTools

Como usar o Homebrew para instalar as ferramentas de linha de comando do Xcode

Por mais fácil que possa ser usar o prompt de comando para instalar as ferramentas de linha de comando do Xcode, eu recomendo um método ainda mais fácil: usar o Homebrew.

Essa opção foi adicionada ao Homebrew recentemente. Por isso, muitos desenvolvedores ainda não sabem sobre ela.

O Homebrew é um conhecido gerenciador de pacotes para o Mac. A maioria dos desenvolvedores precisa de linguagens de programação e programas utilitários que não vêm instalados no macOS e que não estão incluídos no pacote das ferramentas de linha de comando do Xcode. O Homebrew pode instalar quase toda ferramenta de código aberto para os desenvolvedores.

Como você provavelmente precisará do Homebrew em algum momento, pode ser interessante deixar que o Homebrew instale as ferramentas de linha de comando do Xcode para você.

Primeiro, verifique se o Homebrew já está instalado.

$ brew

Se o Homebrew não estiver instalado, você verá uma mensagem assim:

zsh: command not found: brew

O Homebrew fornece um script de instalação que você pode executar em um único comando (verifique se ele não mudou no site do Homebrew).

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

O script de instalação do Homebrew pedirá que você insira sua senha do Mac. Essa é a senha que você usa para entrar no Mac.

Password:

Você não verá os caracteres enquanto digita. Pressione Enter quando tiver concluído.

Se você ainda não instalou as ferramentas de linha de comando do Xcode, verá a seguinte mensagem: "The Xcode Command Line Tools will be installed." Pressione Return para continuar quando isso for pedido pelo script de instalação do Homebrew.

Você verá mensagens de diagnóstico e de andamento da instalação. A instalação do Homebrew leva de 2 a 15 minutos em um Mac M1 Mini de 2021, com uma conexão com a internet de 100Mbps. Ela é significativamente mais lenta em um Mac Intel com uma conexão lenta com a internet.

Nas máquina Mac Intel, isso é tudo o que você precisa fazer – o Homebrew está pronto para ser utilizado. No Mac Intel, o Homebrew é instalado no diretório /usr/local/bin, que já está configurado para o acesso pelo shell como o $PATH padrão do macOS.

Nas máquinas Silicon da Apple, é preciso mais uma etapa. Os arquivos do Homebrew são instalados na pasta /opt/homebrew. Mas a pasta não é parte do $PATH padrão. Siga o conselho do Homebrew e crie um arquivo ~/.zprofile que contenha um comando que configura o Homebrew. O Homebrew mostra as instruções ao final do processo de instalação:

- Add Homebrew to your PATH in ~/.zprofile:
echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"

Após instalar o Homebrew, verifique se o Homebrew está instalado adequadamente.

$ brew doctor

Você verá o seguinte:

Your system is ready to brew.

O Homebrew está instalado com sucesso. Os arquivos do Homebrew estarão em /usr/local (para os macOS Intel) ou em /opt/homebrew (para os Silicon da Apple).

Agora, você já tem instalados as ferramentas de linha de comando do Xcode e o Homebrew. Se quiser saber mais sobre como adicionar pacotes do Homebrew para configurar seu ambiente de desenvolvimento, consulte Install a Homebrew Package (em inglês).

Mais informações

Eu também escrevi um guia detalhado sobre como instalar as ferramentas de linha de comando do Xcode (em inglês) que vai além do básico descrito aqui.

No guia, eu explico como verificar se as ferramentas de linha de comando do Xcode já estão instaladas. Entro em mais detalhes sobre como instalar as ferramentas de linha de comando do Xcode com o Homebrew. Por fim, explico como desinstalar as ferramentas de linha de comando do Xcode, reinstalar as ferramentas de linha de comando do Xcode e dou uma lista das ferramentas de linha de comando do Xcode que você pode usar (textos em inglês).

Também existe um guia completo de como instalar o Homebrew para o Mac que explica como atualizar o Homebrew, desinstalar o Homebrew e se manter atualizado na manutenção do Homebrew (textos em inglês).

Seu ambiente de desenvolvimento

O MacOS é a plataforma mais popular de desenvolvimento de software pelo fato de o sistema operacional ter como base o Unix, o sistema padrão para o desenvolvimento de software já há bastante tempo.

Com as ferramentas de linha de comando do Xcode instaladas, você terá uma base sólida para adicionar praticamente qualquer ferramenta de desenvolvimento de código aberto.

Adicione o Homebrew e você terá um gerenciador de pacotes que pode instalar gerenciadores de versão, linguagens de programação e quase todas as outras ferramentas de que você precisa.

Combinados com um editor de texto e uma aplicação de terminal, você estará preparado para qualquer tutorial que encontrar no freeCodeCamp.