Módulo 18: Pilares do Software de Qualidade

Introdução ao Módulo

Bem-vindo ao Módulo 18! Nesta etapa da sua jornada, vamos conectar cinco dos tópicos mais importantes para a construção de software robusto, escalável e de fácil manutenção. Mais do que apenas escrever código que funciona, você aprenderá a criar soluções que perduram e que podem ser evoluídas com segurança.

Vamos explorar a Arquitetura como a planta baixa do nosso sistema, os Padrões de Projeto como soluções inteligentes para problemas comuns, o Banco de Dados como o coração que armazena as informações, os Testes como a garantia de qualidade e as Boas Práticas como o alicerce que sustenta tudo.

Aula 1: Arquitetura de Software - A Planta Baixa do Sistema

1. O que é Arquitetura de Software?

Arquitetura de software define a estrutura de alto nível de um sistema. São as decisões mais importantes e difíceis de mudar, que determinam como os componentes do sistema se organizam e interagem.

• Analogia: É a planta de uma casa. Antes de construir as paredes (código), você precisa decidir quantos andares, onde ficarão os quartos, a cozinha, e como a eletricidade e o encanamento (fluxo de dados) irão conectar tudo.
• Objetivos: Escalabilidade, performance, manutenibilidade, segurança e resiliência.

2. Principais Estilos Arquiteturais

Não existe “a melhor” arquitetura; a escolha depende dos requisitos do projeto.

• Arquitetura Monolítica:

  • O que é: Toda a aplicação é construída como uma única unidade.
  • Prós: Simples para desenvolver e implantar no início.
  • Contras: Difícil de escalar, manter e atualizar com o tempo (“Big Ball of Mud”).

• Arquitetura em Camadas (N-Tier):

  • O que é: Separa o sistema em camadas lógicas (Apresentação, Negócio, Dados).
  • Prós: Organização clara, separação de responsabilidades.
  • Exemplo: Um sistema web com front-end (Apresentação), back-end com regras de negócio (Negócio) e um banco de dados (Dados).

• Microservices (Microsserviços):

  • O que é: O sistema é uma coleção de pequenos serviços independentes, cada um com sua própria responsabilidade e banco de dados.
  • Prós: Escalabilidade granular, resiliência (a falha de um serviço não derruba tudo), times independentes.
  • Contras: Complexidade operacional, comunicação entre serviços, consistência de dados.

• Arquitetura Orientada a Eventos (EDA - Event-Driven Architecture):

  • O que é: A comunicação entre os componentes é feita através da produção e consumo de eventos (mensagens).
  • Prós: Alto desacoplamento, escalabilidade e resiliência.
  • Exemplo: Um sistema de e-commerce onde um PedidoCriado evento dispara ações em outros serviços (Estoque, Pagamento, Notificação).

Aula 2: Padrões de Projeto (Design Patterns) - Soluções Reutilizáveis

1. O que são Padrões de Projeto?

São soluções testadas e comprovadas para problemas recorrentes no design de software. Eles não são códigos prontos, mas sim “receitas” ou “templates” que podem ser adaptados para resolver um problema específico. Foram popularizados pelo livro “Design Patterns: Elements of Reusable Object-Oriented Software” (o livro da “Gangue dos Quatro” ou GoF).

2. Categorias e Exemplos Principais (GoF)

a) Padrões Criacionais (Creational)

Focam em como os objetos são criados, tornando o sistema mais flexível.

• Singleton: Garante que uma classe tenha apenas uma instância e fornece um ponto de acesso global a ela. (Ex: Gerenciador de conexão com o banco de dados).
• Factory Method: Define uma interface para criar um objeto, mas deixa as subclasses decidirem qual classe instanciar. (Ex: Uma fábrica de Veiculo que pode criar Carro ou Moto).
• Builder: Separa a construção de um objeto complexo de sua representação, permitindo que o mesmo processo de construção crie diferentes representações. (Ex: Montar um objeto Pizza com diferentes ingredientes passo a passo).

b) Padrões Estruturais (Structural)

Focam em como classes e objetos são compostos para formar estruturas maiores.

• Adapter: Permite que interfaces incompatíveis trabalhem juntas. (Ex: Um “adaptador de tomada” para conectar uma classe que espera XML a uma que fornece JSON).
• Decorator: Adiciona novas funcionalidades a um objeto dinamicamente, sem alterar sua classe. (Ex: Adicionar Bacon e QueijoExtra a uma Pizza base).
• Facade: Fornece uma interface simplificada para um sistema complexo de classes. (Ex: Um botão “Ligar Home Theater” que internamente liga a TV, o receiver e o Blu-ray).

c) Padrões Comportamentais (Behavioral)

Focam na comunicação e na distribuição de responsabilidades entre os objetos.

• Strategy: Permite que você defina uma família de algoritmos, coloque cada um deles em uma classe separada e torne seus objetos intercambiáveis. (Ex: Um objeto CalculadoraDeFrete que pode usar diferentes estratégias: Sedex, PAC, Jadlog).
• Observer: Define uma dependência um-para-muitos, de modo que, quando um objeto muda de estado, todos os seus dependentes são notificados e atualizados automaticamente. (Ex: Uma Planilha (observador) que se atualiza quando os dados em um Grafico (observado) mudam).

Aula 3: Banco de Dados - O Coração da Aplicação

1. O Papel do Banco de Dados na Arquitetura

O banco de dados não é apenas um “depósito”. A escolha do tipo de banco e a forma como os dados são modelados e acessados são decisões arquiteturais críticas que impactam performance e complexidade.

2. Tipos de Banco de Dados

• Relacionais (SQL):

  • Modelo: Dados estruturados em tabelas com linhas e colunas, com relacionamentos definidos por chaves.
  • Exemplos: PostgreSQL, MySQL, SQL Server.
  • Ideal para: Sistemas que exigem alta consistência e transações complexas (propriedades ACID), como sistemas financeiros e de gestão.

• Não Relacionais (NoSQL):

  • Modelo: Flexível, sem esquema fixo. Existem vários tipos:
    • Documento: Armazena dados em documentos JSON/BSON. (Ex: MongoDB).
    • Chave-Valor: Dicionário simples e ultrarrápido. (Ex: Redis).
    • Grafo: Focado em representar e consultar relacionamentos. (Ex: Neo4j).
  • Ideal para: Big Data, aplicações em tempo real, sistemas com requisitos de alta escalabilidade e flexibilidade.

3. Padrões de Acesso a Dados

• Repository Pattern: Media o acesso entre o domínio do negócio e a camada de mapeamento de dados. A aplicação conversa com uma interface de repositório (IProdutoRepository), sem saber se os dados estão vindo de um SQL Server, MongoDB ou de uma API.
• ORM (Object-Relational Mapping): Ferramentas que mapeiam os objetos da sua aplicação para as tabelas de um banco de dados relacional. Reduzem o código “boilerplate” de SQL. (Ex: JPA/Hibernate em Java, Entity Framework em .NET, Sequelize em Node.js).

Aula 4: Testes de Software - Garantindo a Qualidade

1. Por que Testar?

• Garantir que o código faz o que deveria.
• Reduzir bugs em produção.
• Permitir refatoração segura: Mudar o código sem quebrar o que já funciona.
• Servir como documentação viva: Um bom teste descreve o comportamento esperado de uma função ou componente.

2. A Pirâmide de Testes

É um modelo para pensar sobre a proporção de cada tipo de teste.

• Testes de Unidade (Base da Pirâmide - Muitos):

  • O que testam: A menor parte do código (uma função, um método, uma classe) de forma isolada.
  • Características: Rápidos, baratos, fáceis de escrever. Usam “mocks” e “stubs” para simular dependências.

• Testes de Integração (Meio da Pirâmide - Menos):

  • O que testam: A interação entre dois ou mais componentes.
  • Exemplo: Se a sua camada de serviço consegue se comunicar corretamente com o repositório e o banco de dados.
  • Características: Mais lentos e complexos que os de unidade.

• Testes de Ponta a Ponta (E2E) (Topo da Pirâmide - Poucos):

  • O que testam: O fluxo completo do usuário, simulando uma interação real com o sistema.
  • Exemplo: Simular um usuário fazendo login, adicionando um produto ao carrinho e finalizando a compra.
  • Características: Muito lentos, caros e frágeis (quebram com facilidade).

3. TDD (Test-Driven Development)

É uma prática de desenvolvimento onde você escreve o teste antes de escrever o código de produção.

• Ciclo:
  1. Red: Escreva um teste que falha.
  2. Green: Escreva o código mais simples possível para o teste passar.
  3. Refactor: Refatore o código para melhorar a qualidade, com a segurança de que os testes continuam passando.

Aula 5: Boas Práticas - O Alicerce do Bom Código

1. Princípios de Design de Software

São diretrizes que ajudam a criar um código mais limpo, modular e de fácil manutenção.

• SOLID:

  • S (Single Responsibility Principle): Uma classe deve ter um, e apenas um, motivo para mudar.
  • O (Open/Closed Principle): As entidades de software devem ser abertas para extensão, mas fechadas para modificação.
  • L (Liskov Substitution Principle): Objetos de uma superclasse devem ser substituíveis por objetos de uma subclasse sem quebrar a aplicação.
  • I (Interface Segregation Principle): Uma classe não deve ser forçada a implementar interfaces e métodos que não irá usar.
  • D (Dependency Inversion Principle): Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.

• KISS (Keep It Simple, Stupid): A simplicidade deve ser um objetivo chave. A melhor solução é, muitas vezes, a mais simples.

• DRY (Don’t Repeat Yourself): Não repita código. Abstraia e reutilize.

• YAGNI (You Ain’t Gonna Need It): Não implemente funcionalidades que você não precisa agora, achando que “talvez um dia vá precisar”.

2. Clean Code (Código Limpo)

• Conceito: Escrever código que seja fácil de ler e entender por outros humanos.
• Práticas:
  • Nomes de variáveis e funções que revelem a intenção.
  • Funções pequenas e focadas.
  • Comentários que explicam o “porquê”, não o “o quê”.
  • Formatação consistente.