DEV Community: Yuri Peixinho

Cluster 4: #10 testes rápidos e independentes, #13 simplicidade e refatoração contínua

Yuri Peixinho — Sat, 01 Aug 2026 21:50:16 +0000

Introdução

Esse cluster é diferente dos outros três: ele não previne um tipo de bug, ele sustenta a capacidade de manter os outros nove princípios ao longo do tempo. A segunda lei de Lehman, a Lei da Complexidade Crescente, diz que a complexidade de um sistema aumenta por padrão a menos que alguém trabalhe ativamente para reduzir-la. Refatoração não é uma tarefa opcional de “polimento”, é a única força que contrabalança uma tendência que existe independente da sua vontade. Mas refatorar só é seguro se você consegue confirmar rapidamente que nada quebrou — e é aí que testes lentos ou dependentes de ordem matam a disciplina inteira: se rodar a suíte demora 20 minutos ou falha de forma inconsistente, o time para de rodar, para de confiar, e para de refatorar, e a lei da complexidade crescente passa a valer sem oposição. Esse não é um risco teórico: o relatório The Developer Coefficient (Stripe, 2018), baseado em pesquisa com centenas de desenvolvedores e executivos de engenharia, estimou que uma fração substancial da semana de trabalho — na casa de um terço a 40% — é perdida lidando com dívida técnica e código malfeito, com impacto econômico global estimado em centenas de bilhões de dólares por ano. Esse número é, em essência, o preço agregado de organizações que pararam de fazer #10 e #13 e deixaram a lei de Lehman correr sem freio.

#10 Testes Rápidos e Independentes

A base conceitual mais direta aqui é o acrônimo FIRST, documentado por Robert C. Martin em Clean Code (2008) e creditado a Tim Ottinger e Jeff Langr: um teste de unidade deveria ser Fast (rápido), Independent (independente de outros testes), Repeatable (repetível em qualquer ambiente), Self-Validating (retorna verdadeiro/falso, sem exigir inspeção manual de log) e Timely (escrito no momento certo, perto do código que testa). O título desse princípio no artigo pega exatamente as duas primeiras letras — porque são, na prática, as duas que mais diretamente disparam a espiral de morte descrita na introdução: um teste lento drena paciência a cada execução; um teste dependente de ordem drena confiança a cada falha que não devia ter acontecido.

Exemplo — teste lento e acoplado vs. teste rápido e isolado:

// Lento e acoplado — bate no banco de dados real a cada execução
public class RetificacaoServiceTests
{
    [Fact]
    public void DeveRetificarMovimento_QuandoValorDivergente()
    {
        var context = new FiscalDbContext(_connectionStringReal); // conexão real com SQL Server
        var service = new RetificacaoService(context);

        var resultado = service.Retificar(movimentoId: 123);

        Assert.True(resultado.Sucesso);
        // Cada execução: abre conexão de rede real, e depende de que a linha 123
        // já exista no banco com o estado "certo" — herdado de uma execução anterior
    }
}

// Rápido e isolado — dependência trocada por um fake em memória
public class RetificacaoServiceTests
{
    [Fact]
    public void DeveRetificarMovimento_QuandoValorDivergente()
    {
        var repositorioFake = new RepositorioMovimentoFake(
            new Movimento(id: 123, valor: 500m, status: StatusMovimento.Pendente));
        var service = new RetificacaoService(repositorioFake);

        var resultado = service.Retificar(movimentoId: 123);

        Assert.True(resultado.Sucesso);
        // Roda em memória, sem I/O — milissegundos. O estado de entrada é 100%
        // definido dentro do próprio teste, não herdado de nada externo
    }
}

Exemplo — teste dependente de ordem vs. independente:

// Frágil — os dois testes compartilham uma lista estática entre execuções
public class NumeracaoNotaFiscalTests
{
    private static readonly List<int> _numerosGerados = new();

    [Fact]
    public void PrimeiroNumero_DeveSerUm()
    {
        var numero = GerarProximoNumero(_numerosGerados);
        Assert.Equal(1, numero);
        _numerosGerados.Add(numero);
    }

    [Fact]
    public void SegundoNumero_DeveSerDois()
    {
        var numero = GerarProximoNumero(_numerosGerados);
        Assert.Equal(2, numero);
        // Só passa se PrimeiroNumero_DeveSerUm já rodou antes, e nessa ordem.
        // Rodar sozinho, em paralelo, ou com a suíte embaralhada: falha.
    }
}

// Independente — cada teste monta seu próprio estado, do zero
public class NumeracaoNotaFiscalTests
{
    [Fact]
    public void PrimeiroNumero_DeveSerUm()
    {
        var numero = GerarProximoNumero(new List<int>());
        Assert.Equal(1, numero);
    }

    [Fact]
    public void SegundoNumero_DeveSerDois()
    {
        var numero = GerarProximoNumero(new List<int> { 1 }); // pré-condição explícita, não herdada
        Assert.Equal(2, numero);
    }
}

O segundo exemplo é o padrão mais comum de "flakiness" na prática: dois testes que passam perfeitamente na ordem em que foram escritos, e falham de forma aparentemente aleatória assim que uma pipeline de CI paraliza a execução, ou quando algum framework de teste decide randomizar a ordem deliberadamente — justamente pra expor esse tipo de acoplamento escondido antes que ele vire um problema em produção.

#13 Simplicidade e Refatoração Contínua

A base conceitual mais direta vem de Kent Beck, em Extreme Programming Explained (1999): as Quatro Regras do Design Simples, nessa ordem de prioridade — (1) passa em todos os testes, (2) revela a intenção, (3) sem duplicação, (4) menor número de elementos possível. A ordem importa: só faz sentido buscar "menos elementos" depois de garantir que a intenção está clara e que não há duplicação — simplicidade não é sinônimo de "menos código a qualquer custo", é a ausência de tudo que não precisa estar ali.

A ligação com dívida técnica, que a introdução já traz pelo relatório da Stripe, vem de Ward Cunningham, num relato de experiência na OOPSLA de 1992: código que corta caminho pra entregar mais rápido hoje é, literalmente, um empréstimo — você recebe velocidade agora e paga juros (retrabalho, fricção, tempo de entendimento) em cada mudança futura, até que alguém pague o principal de volta via refatoração. Cunningham não estava fazendo uma crítica moral ao atalho — dívida técnica pode ser escolha racional e deliberada —, o ponto dele é que ela tem que ser paga de algum jeito, consciente ou não.

A técnica pra pagar essa dívida com segurança é formalizada por Martin Fowler em Refactoring: Improving the Design of Existing Code (1999): uma sequência de pequenas transformações, cada uma preservando o comportamento observável do sistema, verificada por testes a cada passo — nunca uma reescrita de uma vez só. Robert C. Martin resume o hábito do dia a dia nisso com a Regra do Escoteiro: deixe o código um pouco mais limpo do que você encontrou, toda vez que mexer nele — não precisa de um projeto formal de refatoração, é disciplina contínua aplicada a cada Pull Request.

Exemplo — duplicação que se acumula em silêncio:

// Complexo — a mesma validação de CPF/CNPJ duplicada em dois lugares do sistema
public class ValidadorNotaFiscal
{
    public bool Validar(NotaFiscal nota)
    {
        var doc = nota.Cliente.Documento.Replace(".", "").Replace("-", "").Replace("/", "");
        if (doc.Length == 11) { /* ~20 linhas de validação de CPF */ }
        else if (doc.Length == 14) { /* ~25 linhas de validação de CNPJ */ }
        return true;
    }
}

public class ValidadorTransmissao
{
    public bool PodeTransmitir(ArquivoEFinanceira arquivo)
    {
        var doc = arquivo.Titular.Documento.Replace(".", "").Replace("-", "").Replace("/", "");
        if (doc.Length == 11) { /* a mesma validação de CPF, copiada e colada */ }
        // quem corrigir um bug aqui precisa lembrar de corrigir no outro lugar também
    }
}

// Simples — a regra vive em um único lugar; os dois validadores delegam
public static class ValidadorDocumento
{
    public static bool EhValido(string documento)
    {
        var limpo = Limpar(documento);
        return limpo.Length switch
        {
            11 => ValidarCpf(limpo),
            14 => ValidarCnpj(limpo),
            _ => false
        };
    }

    private static string Limpar(string doc) => doc.Replace(".", "").Replace("-", "").Replace("/", "");
}

public class ValidadorNotaFiscal
{
    public bool Validar(NotaFiscal nota) => ValidadorDocumento.EhValido(nota.Cliente.Documento);
}

Essa é a Regra 3 de Beck (sem duplicação) na prática. O perigo da versão duplicada não é só o volume de código — é que um bug corrigido num lugar continua vivo no outro, esperando quieto até alguém notar a divergência, geralmente meses depois, geralmente em produção.

Cluster 3: #8 distância do framework, #11 organizar por ator, #9 constructs corretos

Yuri Peixinho — Sat, 01 Aug 2026 21:49:33 +0000

Introdução

A restrição já está posta pelo artigo: a Lei da Mudança Contínua de Lehman (1974) — todo sistema em uso real será solicitado a mudar, indefinidamente, e a única pergunta em aberto é se essa mudança sai barata (alteração localizada) ou cara (reescrita). Os três princípios desse cluster não impedem a mudança — não tem como impedir que ela chegue —, eles atacam a fonte de onde ela vem, cada um numa direção diferente: #8 blinda contra mudança que vem de fora do sistema (o ecossistema de frameworks), #11 blinda contra mudança que vem das pessoas ao redor do sistema (atores com pedidos concorrentes), e #9 blinda contra mudança que vem do próprio domínio crescendo além do que foi validado como seguro.

#8 Distância do Framework

A base conceitual é o que Robert C. Martin ("Uncle Bob") formaliza em Clean Architecture (2017): frameworks pertencem ao anel mais externo da arquitetura — são um detalhe de entrega, não o centro do sistema. A regra de negócio não deveria importar nada do framework; é o framework que deveria se adaptar pra rodar a regra de negócio (a Inversão de Dependência aplicada em escala arquitetural, não só entre duas classes). Martin propõe um teste simples pra isso, conhecido como "screaming architecture": olhando só a estrutura de pastas de um projeto, ela deveria gritar o domínio do negócio — "isso é um sistema de compliance fiscal" — e não gritar o framework — "isso é um projeto ASP.NET" ou "isso é um projeto Angular".

O caso do AngularJS, é essa falha na prática: equipes que escreveram regra de negócio usando construtos específicos do AngularJS ($scope, watchers, diretivas com lógica de domínio embutida) não enfrentaram só um problema de "trocar de framework" quando o suporte acabou em 2022 — tiveram que reescrever a regra de negócio em si, porque ela nunca existiu separada do framework pra começo de conversa. A mudança que a Lei de Lehman garante chegou pela porta do ecossistema, não por um pedido de negócio, e o custo foi o de uma reescrita completa.

// Ruim — regra de negócio vive dentro do Controller, acoplada ao ASP.NET
public class PedidoController : ControllerBase
{
    [HttpPost]
    public IActionResult CriarPedido([FromBody] PedidoDto dto)
    {
        if (dto.Itens.Count == 0)
            return BadRequest("Pedido sem itens"); // regra de negócio dentro do framework web

        if (dto.ValorTotal > 10000 && dto.Cliente.Tipo == "PF")
            return BadRequest("Limite excedido para pessoa física");

        return Ok();
    }
}

// Bom — regra de negócio isolada, sem qualquer referência ao ASP.NET
public class ValidadorPedido
{
    public ResultadoValidacao Validar(Pedido pedido)
    {
        if (pedido.Itens.Count == 0)
            return ResultadoValidacao.Falha("Pedido sem itens");

        if (pedido.ValorTotal > 10000 && pedido.Cliente.Tipo == TipoCliente.PessoaFisica)
            return ResultadoValidacao.Falha("Limite excedido para pessoa física");

        return ResultadoValidacao.Sucesso();
    }
}

// O Controller vira uma casca fina que só traduz HTTP <-> domínio
public class PedidoController : ControllerBase
{
    private readonly ValidadorPedido _validador;
    public PedidoController(ValidadorPedido validador) => _validador = validador;

    [HttpPost]
    public IActionResult CriarPedido([FromBody] PedidoDto dto)
    {
        var resultado = _validador.Validar(dto.ParaPedido());
        return resultado.Valido ? Ok() : BadRequest(resultado.Erro);
    }
}

Se o ASP.NET Core for substituído amanhã — por minimal APIs, por outro framework inteiro —, só a casca (PedidoController) muda. ValidadorPedido nunca soube que o ASP.NET existia.

#11 Organizar por Ator

Martin também reformula aqui o "S" do SOLID. A formulação clássica do Single Responsibility Principle — "uma classe deve ter só uma razão pra mudar" — é vaga: razão pra mudar, segundo quem? Em Clean Architecture, ele resolve a ambiguidade com uma definição operacional: um módulo deve ser responsável perante um, e apenas um, ator — sendo ator o grupo de pessoas (ou papel de negócio) que pode solicitar uma mudança naquele módulo especificamente. Se dois atores diferentes têm poder de pedir mudanças na mesma classe, essa classe tem duas razões concorrentes pra mudar — e uma mudança pedida por um ator arrisca quebrar, silenciosamente, o comportamento que o outro ator depende, sem que ninguém tenha pedido isso.

O exemplo canônico é uma classe Funcionario que atende três atores ao mesmo tempo:

// Ruim — uma classe atende três atores diferentes: Financeiro, RH e o time de dados
public class Funcionario
{
    public decimal CalcularSalario() { /* regra que só o Financeiro pode pedir pra mudar */ }
    public string GerarRelatorioHoras() { /* regra que só o RH pode pedir pra mudar */ }
    public void Salvar() { /* regra que só o time de dados/infra pode pedir pra mudar */ }
}

Se CalcularSalario e GerarRelatorioHoras compartilham um método privado auxiliar — por exemplo, um cálculo de dias trabalhados no mês —, uma mudança pedida pelo Financeiro na fórmula de hora extra pode alterar silenciosamente o número que aparece no relatório do RH. O RH nunca pediu nada, nunca revisou nada, só um dia percebe que o número mudou sem aviso.

// Bom — cada ator tem sua própria classe; a mudança de um nunca atravessa pro código do outro
public class CalculadoraSalario
{
    public decimal Calcular(Funcionario funcionario) { /* só o Financeiro mexe aqui */ }
}

public class RelatorioHoras
{
    public string Gerar(Funcionario funcionario) { /* só o RH mexe aqui */ }
}

public class FuncionarioRepository
{
    public void Salvar(Funcionario funcionario) { /* só o time de dados mexe aqui */ }
}

Segundo exemplo, pra mostrar que o princípio não vale só entre classes — vale entre pastas/módulos também:

// Ruim — organizado por camada técnica; atores diferentes convivem no mesmo diretório
/Services
  FuncionarioService.cs      <- muda quando Financeiro OU RH pedem algo
  RelatorioService.cs        <- muda quando RH OU Diretoria pedem algo
  NotificacaoService.cs      <- muda por qualquer motivo, de qualquer ator

// Bom — organizado por ator/domínio; a mudança de um ator fica fisicamente isolada
/Financeiro
  CalculadoraSalario.cs
/RH
  RelatorioHoras.cs
  GestaoFerias.cs
/Diretoria
  RelatorioExecutivo.cs

Na versão "por camada técnica", um Pull Request do RH e um Pull Request do Financeiro competem pelo mesmo arquivo (FuncionarioService.cs) sem relação nenhuma entre os dois pedidos — terreno fértil pra conflito de merge e, pior, pra mudança de um ator vazar pro comportamento que o outro depende, sem ninguém perceber no code review.

#9 Constructs Corretos

Structs são blocos fundamentais de controle de fluxo e organização de código: for, while, if/else, switch, funções, recursão, estruturas de dados (arrays, listas, dicionários, etc.). "Usar constructs corretos" significa escolher a ferramenta certa pra cada problema, em vez de forçar uma solução genérica ou "na moda" onde ela não se encaixa.

1. Escolha a ferramenta certa pro problema — não a que você "sabe usar melhor"

O exemplo clássico: iterar um array com for em vez de recursão.

// Desnecessariamente complexo — recursão para algo simples
public decimal SomarValores(List<decimal> valores, int index = 0)
{
    if (index >= valores.Count) return 0;
    return valores[index] + SomarValores(valores, index + 1);
}

// Correto — for/LINQ é direto e sem risco de stack overflow
public decimal SomarValores(List<decimal> valores)
{
    return valores.Sum();
}

Recursão tem seu lugar (árvores, backtracking, algoritmos naturalmente recursivos), mas usar recursão pra percorrer uma lista simples é usar o construct errado — mais difícil de ler, mais arriscado (stack overflow em listas grandes), sem ganho nenhum.

2. Evite variáveis globais — passe dados via parâmetros e retornos

// Ruim — estado global, difícil de rastrear quem altera o quê
public static class ContextoAtual
{
    public static string TenantId;
    public static DateTime PeriodoReferencia;
}

public void ProcessarArquivo()
{
    // usa ContextoAtual.TenantId direto — de onde veio? quem garante que está certo?
}

// Bom — dependência explícita via parâmetro
public void ProcessarArquivo(string tenantId, DateTime periodoReferencia)
{
    // fica óbvio de onde vêm os dados, e é testável isoladamente
}

3. Evite complexidade desnecessária

// Complexo demais para o que faz
public bool EhValido(string cnpj)
{
    return !(string.IsNullOrEmpty(cnpj) == false ? false : true) && cnpj.Length == 14;
}

// Direto
public bool EhValido(string cnpj)
{
    return !string.IsNullOrEmpty(cnpj) && cnpj.Length == 14;
}

Aninhamentos de if desnecessários, negações duplas, ternários encadeados — tudo isso é "construct errado" mesmo quando funciona, porque exige esforço mental extra de quem lê.

4. Control flow lógico e intuitivo

// Cadeia de if — funciona, mas escala mal
public string ObterDescricaoStatus(StatusArquivo status)
{
    if (status == StatusArquivo.Pendente) return "Pendente";
    else if (status == StatusArquivo.Processando) return "Processando";
    else if (status == StatusArquivo.Concluido) return "Concluído";
    else if (status == StatusArquivo.Erro) return "Erro";
    else return "Desconhecido";
}

// Switch expression — mais legível pra múltiplos casos fixos
public string ObterDescricaoStatus(StatusArquivo status) => status switch
{
    StatusArquivo.Pendente => "Pendente",
    StatusArquivo.Processando => "Processando",
    StatusArquivo.Concluido => "Concluído",
    StatusArquivo.Erro => "Erro",
    _ => "Desconhecido"
};

Cluster 2: #5 funções puras, #7 evitar null/booleanos, #12 command query separation

Yuri Peixinho — Sat, 01 Aug 2026 21:49:20 +0000

Introdução

Como já dito anteriormente: A restrição: quando o comportamento de uma função depende de estado invisível no momento da leitura (uma variável global, um efeito colateral escondido atrás de uma "consulta", uma flag booleana cujo significado não está no call site), reproduzir um bug exige reconstruir todo esse contexto invisível — e é exatamente por isso que esses bugs consomem tempo desproporcional de debug comparado a bugs em código puro. O caso mais grave documentado na literatura de engenharia de software é o Therac-25 (1985-1987): uma máquina de radioterapia cujo software tinha uma condição de corrida (estado compartilhado mutável, dependente de timing) que, combinada com a remoção dos interlocks de segurança em hardware que existiam nas versões anteriores, liberou doses de radiação até 100x acima do previsto, matando ao menos três pacientes. O relatório de Nancy Leveson e Clark Turner (1993) aponta diretamente para o problema de confiar em estado compartilhado sem isolamento. Num registro bem menos trágico mas igualmente didático, o colapso da Knight Capital em 2012 — perda de US$460 milhões em 45 minutos — aconteceu porque uma flag booleana reaproveitada (que ligava um código morto de 8 anos atrás, chamado "Power Peg") foi ativada acidentalmente num deploy incompleto: ninguém mais conseguia dizer com certeza o que aquela flag realmente controlava. Isso é o princípio #7 na prática: booleanos e nulos acumulam significado ambíguo com o tempo até que ninguém consegue mais raciocinar sobre o que eles realmente ligam ou desligam.

O fio condutor continua o mesmo: estado escondido é a causa raiz dos bugs mais caros de rastrear. A diferença de um bug em código limpo pra um bug em código com estado escondido é a diferença entre achar uma chave debaixo do tapete e achar uma chave que foi escondida em algum lugar aleatório da casa há três meses, por alguém que nem trabalha mais aqui. Vamos nos três princípios, cada um com mais de um exemplo.

#5 Funções Puras

A base é a transparência referencial (Strachey, 1967): uma expressão só pode ser trocada pelo seu valor sem mudar o comportamento do programa se ela não depender de nem alterar nada fora dela. Backus, no discurso do Turing Award de 1977, chama o estilo oposto (mutação de estado compartilhado, ao estilo da arquitetura von Neumann) de gerador de uma distância conceitual enorme entre o problema e o código — cada função pura elimina essa distância porque pode ser entendida e testada isolada do resto do universo.

Por que isso importa na prática: uma função pura é testável sem mock, sem setup, sem ordem de execução. Você chama com os mesmos argumentos e sempre recebe o mesmo resultado. Uma função impura como CreateOrder(items) do exemplo esconde duas fontes de variação (Guid.NewGuid(), DateTime.Now) dentro da regra de negócio — isso significa que testar essa função exige ou aceitar não-determinismo no teste, ou fazer wrapping/mocking de chamadas estáticas do sistema, o que é sinal de que a impureza vazou pra dentro de algo que deveria ser lógica pura.

A correção não é só "passar como parâmetro" por estética — é sobre onde a decisão não-determinística deve morar. Guid.NewGuid() e DateTime.Now são decisões de infraestrutura (que ID usar, que relógio consultar), não decisões de negócio. Empurrar isso pra borda (controller, handler, o que for) significa que a regra de negócio (CreateOrder) fica livre de qualquer coisa que não seja lógica pura de domínio.

// Impura — Guid.NewGuid() e DateTime.Now escondidos dentro da regra de negócio
Order CreateOrder(List<Item> items)
{
    return new Order(Guid.NewGuid(), items, DateTime.Now);
}

// Pura — id e data entram como parâmetro; quem gera esses valores é a borda (controller, por exemplo)
Order CreateOrder(List<Item> items, Guid id, DateTime createdAt)
{
    return new Order(id, items, createdAt);
}

#7 Evitar null/booleanos

O artigo conecta isso diretamente ao caso Knight Capital: uma flag booleana reaproveitada ativou um código morto de 8 anos, e ninguém mais sabia com certeza o que aquela flag controlava. Isso não é sobre "booleano é ruim". É sobre o seguinte: um booleano só carrega um bit de informação, mas o significado desse bit precisa ser reconstruído de cabeça por quem lê o código, e esse significado tende a se degradar com o tempo — a flag original tinha um propósito claro, mas depois de anos de reaproveitamento, ninguém consegue mais dizer com certeza o que ligar/desligar aquele bit realmente faz no sistema como um todo hoje.

Com null o problema é análogo mas com uma variante a mais: null costuma significar simultaneamente "ainda não temos esse valor", "esse valor não se aplica" e "erro ao buscar esse valor" — três situações completamente diferentes, comprimidas na mesma representação. Quem lê if (cliente.Endereco == null) não sabe qual dos três casos está tratando, e o compilador não ajuda a diferenciar.

Exemplo — null com múltiplos significados:

// Ambíguo — null pode significar "não processado", "não se aplica" ou "erro"
public decimal? DesconTotalAplicado { get; set; }

if (pedido.DesconTotalAplicado == null)
{
    // Ainda não calculado? Pedido sem desconto? Falha no cálculo?
    // A leitura desse if não responde isso.
}

// Explícito — cada estado é um caso nomeado
public enum StatusDesconto { NaoCalculado, SemDesconto, ErroNoCalculo, Aplicado }
public record ResultadoDesconto(StatusDesconto Status, decimal Valor);

if (pedido.Desconto.Status == StatusDesconto.NaoCalculado)
{
    // Agora não há ambiguidade — o call site já diz o que está acontecendo
}

Exemplo — booleano que vira flag de reaproveitamento:

// Perigoso — flag genérica que qualquer feature futura pode reaproveitar
public bool ModoAlternativo { get; set; }

if (config.ModoAlternativo)
{
    ExecutarFluxoLegado(); // Daqui a 2 anos: alguém vai reativar isso achando que é outra coisa?
}

// Explícito — cada modo tem nome e propósito documentado no próprio tipo
public enum ModoExecucao { Padrao, ReprocessamentoLegado, MigracaoDados }

switch (config.Modo)
{
    case ModoExecucao.ReprocessamentoLegado:
        ExecutarFluxoLegado();
        break;
}

O segundo exemplo é literalmente o padrão do "Power Peg" da Knight Capital — uma flag que ligava um caminho de código antigo, sem que o significado dela estivesse escrito em lugar nenhum além da cabeça de quem a criou originalmente (e essa pessoa provavelmente já não estava mais na empresa quando o incidente aconteceu).

Regra prática: se um booleano ou um null pode significar mais de uma coisa dependendo do contexto, ele deveria ser um enum, ou um tipo de resultado explícito (tipo Option<T>/Result<T,E>, ou um record com status nomeado). O custo de escrever o enum é uma linha; o custo de não escrever é alguém, meses depois, precisando reconstruir de memória o que aquele bit realmente significa — exatamente o tipo de reconstrução de contexto invisível que a introdução do artigo descreve como a razão desses bugs consumirem tempo desproporcional.

#12 Command Query Separation

Um método deve ser um Comando (faz algo, muda estado, não retorna valor) ou uma Query (responde uma pergunta, retorna valor, não muda nada) — nunca as duas coisas ao mesmo tempo.

O motivo disso se conectar diretamente ao fio condutor da introdução: uma função que parece uma pergunta ("me diga X") mas na verdade também é uma ordem escondida ("e de paço muda Y") é o caso mais insidioso de estado escondido, porque o nome da função mente sobre o que ela faz. Quem lê o call site vê uma leitura e não tem motivo nenhum pra suspeitar de um efeito colateral — e é exatamente essa lacuna entre o que o código aparenta fazer e o que ele realmente faz que faz um bug consumir horas de debug ao invés de minutos.

Exemplo clássico — método que parece query mas é comando:

// Viola CQS — o nome sugere consulta, mas o método também gera efeito colateral
public bool ValidarEProcessarPagamento(Pagamento pagamento)
{
    var valido = pagamento.Valor > 0 && pagamento.CartaoValido;
    if (valido)
    {
        _repositorio.Salvar(pagamento); // Efeito colateral escondido atrás de um nome de "validação"
        _servicoEmail.Enviar(pagamento.Cliente, "Pagamento processado");
    }
    return valido;
}

// Chamada — parece inofensiva, mas dispara persistência e envio de e-mail
if (ValidarEProcessarPagamento(pagamento))
{
    // ...
}

Quem escreve if (ValidarEProcessarPagamento(pagamento)) num teste, ou numa tentativa de debug, provavelmente só quer checar se o pagamento é válido — e sem querer dispara persistência no banco e envio de e-mail de verdade. Isso é o análogo direto do "Power Peg" da Knight Capital: uma chamada que parece uma coisa (checagem) mas na verdade também é outra (ativação de um fluxo real), e a discrepância só aparece quando já é tarde.

Correção:

// Query — só responde, sem efeito colateral
public bool ValidarPagamento(Pagamento pagamento)
{
    return pagamento.Valor > 0 && pagamento.CartaoValido;
}

// Comando — só age, não retorna valor de decisão
public void ProcessarPagamento(Pagamento pagamento)
{
    _repositorio.Salvar(pagamento);
    _servicoEmail.Enviar(pagamento.Cliente, "Pagamento processado");
}

// Chamada — a intenção de cada linha é legível sem precisar abrir a implementação
if (ValidarPagamento(pagamento))
{
    ProcessarPagamento(pagamento);
}

Segundo exemplo, um padrão bem comum em código com estado mutável em memória — método que "verifica e incrementa" ao mesmo tempo:

// Viola CQS — parece uma consulta ("ainda tem estoque?") mas decrementa o estoque
public bool TemEstoqueDisponivel(int produtoId, int quantidade)
{
    var produto = _estoque.Buscar(produtoId);
    if (produto.Quantidade >= quantidade)
    {
        produto.Quantidade -= quantidade; // Mutação escondida dentro de uma pergunta
        return true;
    }
    return false;
}

// Separado — a pergunta não muta nada; a ordem é explícita e separada
public bool TemEstoqueDisponivel(int produtoId, int quantidade)
{
    return _estoque.Buscar(produtoId).Quantidade >= quantidade;
}

public void ReservarEstoque(int produtoId, int quantidade)
{
    var produto = _estoque.Buscar(produtoId);
    produto.Quantidade -= quantidade;
}

Note que essa separação também resolve, de quebra, um problema de race condition: se dois lugares diferentes chamam TemEstoqueDisponivel na versão original (achando que é só uma checagem), ambos podem decrementar o estoque sem saber que o outro também fez isso — o mesmo tipo de condição de corrida sobre estado compartilhado que o Therac-25 exibia, só que em domínio de negócio ao invés de hardware médico.

Regra prática: antes de escrever um método, pergunte "esse método responde uma pergunta ou executa uma ordem?" Se a resposta for "as duas coisas", é sinal de que ele precisa ser dividido em dois. O teste rápido: consegue chamar o método várias vezes seguidas sem mudar o resultado do programa (fora o retorno em si)? Se sim, é query. Se não, é comando — e não deveria fingir ser outra coisa através de um nome que sugere só leitura

Cluster 1 do Clean Code: #1 consistência, #2 nomes, #3 estilo, #4 métodos/classes/arquivos pequenos, #6 complexidade ciclomática

Yuri Peixinho — Sat, 25 Jul 2026 19:36:04 +0000

Introdução

Esse é um material que depende de leitura anterior. Recomendo ler o artigo introdutório antes de prosseguir.

Como já dito anteriormente: a restrição aqui não é de gosto, é de hardware. A memória humana de trabalho segura certca de 7±2 "pedaços" de informação simultâneos. O que isso significa de fato? Uma função com 8 variáveis e 6 caminhos de decisão ativos exige que quem lê segure mais estado na cabeça do que ela fisicamente comporta. O erro de interpretação não é falta de atenção, é o estouro da capacidade cognitiva. Isso tem confirmação empírica direta em revisão de código. O revisor humano simplesmente para de conseguir processar depois de certo volume. Consistência, nomes claros e funções pequenas não deixam o código "bonito" — elas mantêm o problema dentro do que um cérebro humano consegue segurar de uma vez.

#1 Be Consistent

Teoria: o experimento de Chase & Simon (1973) com mestres de xadrez mostrou que expertise é reconhecimento de padrões recorrentes tratados como um chunk só, e essa vantagem desaparece quando o padrão é quebrado (posição aleatória no tabuleiro). Consistência é o que permite ao leitor transferir o reconhecimento aprendido num arquivo para o próximo; inconsistência zera essa transferência e obriga reconstrução do zero a cada arquivo.

Prática:

// Ruim — três verbos para a mesma operação, em três arquivos diferentes
async function getUser(id: string) { ... }
async function fetchProducts() { ... }
async function retrieveOrders() { ... }

// Bom — mesmo verbo, reconhecível instantaneamente em qualquer arquivo
async function getUser(id: string) { ... }
async function getProducts() { ... }
async function getOrders() { ... }

#2 Meaningful names over comments

Teoria: um nome bem escolhido externaliza um chunk pronto; o leitor consome o significado já processado em vez de derivá-lo ao vivo a partir da lógica bruta. Comentário tenta fazer o mesmo trabalho, mas com uma falha estrutural: não é verificado por nada, então quando o código muda e o comentário não acompanha, ele entrega um chunk errado — pior que não ter nome nenhum, porque agora o leitor gasta memória extra descobrindo que o comentário mentiu.

// Ruim — comentário tentando compensar nome ruim, e pode ficar desatualizado
// verifica se pode aplicar desconto de fidelidade
if (u.t === 2 && d < 30) { ... }

// Bom — o nome já é o chunk, comentário vira desnecessário
const isEligibleForLoyaltyDiscount = user.tier === Tier.Gold && daysSinceSignup < 30;
if (isEligibleForLoyaltyDiscount) { ... }

#3 Indentation and Code Style

Teoria: Larkin & Simon (1987) mostram que representações espaciais bem construídas permitem inferência por reconhecimento visual (rápido, quase grátis) em vez de busca simbólica sequencial (lenta, consome working memory). Indentação consistente transforma aninhamento — uma informação lógica abstrata — em informação espacial, processada em paralelo pelo sistema visual em vez de competir pelo mesmo gargalo cognitivo usado para entender a regra de negócio.

// Ruim — indentação inconsistente esconde a estrutura de aninhamento
function calculate(x) {
if (x > 0) {
      return x * 2
  } else {
return 0
}}

// Bom — indentação consistente revela a estrutura de graça
function calculate(x: number) {
  if (x > 0) {
    return x * 2;
  }
  return 0;
}

No projeto de vocês isso nem deveria ser decisão manual — oxfmt rodando via husky/lint-staged já resolve isso no commit, antes de chegar em code review.

#4 Keep methods / classes / files small

Teoria: o orçamento de working memory (4-7 chunks) é fixo por leitura. Uma função pequena cabe inteira dentro desse orçamento; uma função grande obriga o leitor a "paginar" informação — soltar um chunk pra abrir espaço pra outro — e é exatamente aí que se esquece uma condição vista no início enquanto se lê o fim.

Prática:

// Ruim — uma função fazendo filtro, soma e formatação juntos
function getOrderSummary(orders: Order[]) {
  const active= orders.filter(o=> o.status!== 'cancelled');
  const total= active.reduce((sum, o) => sum+ o.value, 0);
  return `${active.length} pedidos ativos, total de R$${total.toFixed(2).replace('.', ',')}`;
}

// Bom — cada função com um único nível de abstração, testável isoladamente
function getActiveOrders(orders: Order[]) {
  return orders.filter(o=> o.status!== 'cancelled');
}
function getTotalValue(orders: Order[]) {
  return orders.reduce((sum, o) => sum+ o.value, 0);
}
function formatCurrency(value: number) {
  return `R$${value.toFixed(2).replace('.', ',')}`;
}
function getOrderSummary(orders: Order[]) {
  const active= getActiveOrders(orders);
  return `${active.length} pedidos ativos, total de${formatCurrency(getTotalValue(active))}`;
}

#6 Minimize cyclomatic complexity

Teoria: McCabe (1976) conta pontos de decisão (if, case, &&, ||, laços) na fórmula V(G) = E − N + 2; o NIST (SP 500-235) classifica acima de 10 como risco moderado e acima de 50 como praticamente intestável. Vale uma ressalva importante: a fórmula original de McCabe não pesa profundidade de aninhamento — um if aninhado dentro de outro conta igual a um if solto no mesmo nível, mesmo que o aninhado exija segurar mais chunks simultâneos na cabeça. Foi exatamente essa lacuna que motivou a SonarSource a propor, em 2017, a métrica de Complexidade Cognitiva, que penaliza aninhamento explicitamente — essa é, na prática, a métrica mais alinhada com o argumento do Cluster 1 (memória de trabalho), enquanto McCabe original mede melhor “quantos caminhos preciso testar” (o que cruza com o Cluster 4, de testes).

// Complexidade alta — decisões aninhadas, todas precisam ficar ativas na cabeça
function canEditOrder(user: User, order: Order) {
  if (user.role === 'admin') {
    return true;
  } else {
    if (order.status === 'draft') {
      if (order.ownerId === user.id) {
        return true;
      } else {
        return false;
      }
    } else {
      return false;
    }
  }
}

// Complexidade baixa — guard clauses, cada condição resolvida e descartada da memória
function canEditOrder(user: User, order: Order) {
  if (user.role === 'admin') return true;
  if (order.status !== 'draft') return false;
  return order.ownerId === user.id;
}

Aqui o número de McCabe é quase o mesmo nas duas versões (mesmas 3 decisões) — a diferença real é a complexidade cognitiva: na primeira versão você precisa segurar até 3 condições aninhadas ativas ao mesmo tempo pra saber qual return está sendo executado,na segunda, cada linha resolve e descarta uma condição antes de passar pra próxima.

4 Clusters do Clean Code Principles

Yuri Peixinho — Sat, 25 Jul 2026 19:18:44 +0000

Introdução

O termo virou disciplina formal com o livre de Robert C. Martin, conhecido por “Uncle Bob”, Clean Code: A Handbook of Agile Software Craftsmanship (2008), nascido do movimento ágil/XP no fim dos anos 90 como reação aos projetos que afundavam sobre o peso do próprio código, a motivação não é estética, é econômica.

O próprio Martin cita que a proporção entre tempo lendo código e tempo escrevendo código é “bem acima de 10 para 1”, e Robert Glass, em Facts and Fallacies of Software Engineering (2002), mostra que a manutenção consome entre 40% e 80% (média ~60%).

Os 13 Princípios

Muitos desenvolvedores acreditam que os princípios são recomendações independentes, portanto, faz mais sentido tratar como respostas a um punhado de restrições que existem quer que você as respeite ou quer não. Desse modo, podemos agrupar os 13 princípios em quatro necessidades reais, cada uma com um caso concreto que acontece quando ela é ignorada.

Vamos dividir esses princípios em quatro clusters diferentes, cada um se refere a uma respectiva area. Eles não competem entre si, eles atacam, respectivamente, o limite do cérebro que lê o código, o custo de rastrear estado invisível, o custo de mudar algo estruturado do jeito errado, e o mecanismo que permite manter os três anteriores funcionando daqui a dois anos, não só no dia em que o código foi escrito.

Cluster 1 — Limíte físico da memória de trabalho humanada.

Princípios: #1 consistência, #2 nomes, #3 estilo, #4 métodos/classes/arquivos pequenos, #6 complexidade ciclomática

A restrição aqui não é de gosto, é de hardware. A memória humana de trabalho segura certca de 7±2 "pedaços" de informação simultâneos. O que isso significa de fato? Uma função com 8 variáveis e 6 caminhos de decisão ativos exige que quem lê segure mais estado na cabeça do que ela fisicamente comporta. O erro de interpretação não é falta de atenção, é o estouro da capacidade cognitiva. Isso tem confirmação empírica direta em revisão de código. O revisor humano simplesmente para de conseguir processar depois de certo volume. Consistência, nomes claros e funções pequenas não deixam o código "bonito" — elas mantêm o problema dentro do que um cérebro humano consegue segurar de uma vez.

Cluster 2 — Estado escondido é a causa rais dos bugs mais caros de rastrear

Princípios: #5 funções puras, #7 evitar null/booleanos, #12 command query separation

A restrição: quando o comportamento de uma função depende de estado invisível no momento da leitura (uma variável global, um efeito colateral escondido atrás de uma "consulta", uma flag booleana cujo significado não está no call site), reproduzir um bug exige reconstruir todo esse contexto invisível — e é exatamente por isso que esses bugs consomem tempo desproporcional de debug comparado a bugs em código puro. O caso mais grave documentado na literatura de engenharia de software é o Therac-25 (1985-1987): uma máquina de radioterapia cujo software tinha uma condição de corrida (estado compartilhado mutável, dependente de timing) que, combinada com a remoção dos interlocks de segurança em hardware que existiam nas versões anteriores, liberou doses de radiação até 100x acima do previsto, matando ao menos três pacientes. O relatório de Nancy Leveson e Clark Turner (1993) aponta diretamente para o problema de confiar em estado compartilhado sem isolamento. Num registro bem menos trágico mas igualmente didático, o colapso da Knight Capital em 2012 — perda de US$460 milhões em 45 minutos — aconteceu porque uma flag booleana reaproveitada (que ligava um código morto de 8 anos atrás, chamado "Power Peg") foi ativada acidentalmente num deploy incompleto: ninguém mais conseguia dizer com certeza o que aquela flag realmente controlava. Isso é o princípio #7 na prática: booleanos e nulos acumulam significado ambíguo com o tempo até que ninguém consegue mais raciocinar sobre o que eles realmente ligam ou desligam.

Cluster 3 — Mudança é garantida; a estrutura decisde se ela sai barata ou cara

Princípios: #8 distância do framework, #11 organizar por ator, #9 constructs corretos

A restrição vem direto da Lei da Mudança Contínua de Lehman (1974): todo sistema em uso real será solicitado a mudar, indefinidamente — a única variável em aberto é se sua arquitetura absorve essa mudança com uma alteração localizada ou exige reescrita. Frameworks front-end viraram e morreram várias vezes em poucas décadas (o próprio fim de vida do AngularJS em 2022 forçou reescritas inteiras em empresas que tinham misturado regra de negócio com APIs do framework). O caso mais caro já registrado de "reaproveitar construção sem revalidar o contexto" é o Ariane 5 (1996): a Agência Espacial Europeia reaproveitou o software de referência inercial do foguete Ariane 4 sem revalidar se os valores numéricos ainda cabiam nos mesmos limites — o Ariane 5 tinha velocidade horizontal maior, um valor estourou a conversão de 64 bits para 16 bits, a exceção não foi tratada, e o foguete se autodestruiu 37 segundos após o lançamento, um prejuízo de ~US$370 milhões. Não foi falta de teste no sentido abstrato — foi código correto no contexto errado, exatamente o risco que organizar por ator/domínio e manter regra de negócio isolada do framework existem para evitar.

Cluster 4 — Sem rede de segurança rápida, toda a disciplina anterior apodrece sozinha

Princípios: #10 testes rápidos e independentes, #13 simplicidade e refatoração contínua

SQL: Melhores Práticas de Segurança

Yuri Peixinho — Wed, 22 Jul 2026 16:50:14 +0000

Introdução

Os números que abrem este artigo não são abstratos: US$ 4,45 milhões é o custo médio de uma violação, e credenciais comprometidas ou uso indevido de privilégios estão entre as causas mais citadas ano após ano nos relatórios da Verizon. As práticas abaixo existem porque, historicamente, foi assim que as violações mais caras aconteceram.

Princípio do menor privilégio

Audite periodicamente quem tem acesso a quê. É comum um privilégio concedido "temporariamente" para resolver um problema pontual nunca ser revogado, isso se acumula ao longo de anos até que praticamente todo mundo tem acesso a tudo, o oposto do que Griffiths & Wade propuseram.

Nunca concatenar SQL, sempre parametrizar

-- PERIGOSO: concatenação direta permite SQL Injection
"SELECT * FROM usuarios WHERE email = '" + email_do_usuario + "'"

-- SEGURO: query parametrizada
SELECT * FROM usuarios WHERE email = ?

SQL Injection continua, décadas depois, sendo uma das vulnerabilidades mais exploradas do OWASP Top 10 — e a defesa é simples: nunca construir SQL por concatenação de string com input externo.

Criptografia em trânsito e em repouso

Conexões com o banco devem usar TLS/SSL (em trânsito), e dados sensíveis (senhas, dados de pagamento, documentos) devem ser criptografados no armazenamento (em repouso) de forma que, mesmo se alguém acessar o disco fisicamente ou um backup vazar, os dados não sejam legíveis.

Auditoria e Logging

Manter registro de quem executou o quê, e quando, especialmente para operações sensíveis (DELETE, mudanças de permissão, acesso a tabelas com dados pessoais). Sem isso, uma violação pode passar meses sem ser percebida.

Separação de ambientes e contas de serviço

A aplicação em produção não deveria conectar no banco com uma conta de administrador. Cada serviço deve ter sua própria conta, com privilégios mínimos e escopados exatamente ao que aquele serviço faz, se uma aplicação for comprometida, o estrago fica contido.

Backups testados

Segurança não é só impedir acesso indevido, é também garantir recuperação. Um backup que nunca foi restaurado em teste é, na prática, um backup que você não sabe se funciona.

SQL: GRANT and REVOKE

Yuri Peixinho — Wed, 22 Jul 2026 16:44:27 +0000

Introdução

Em 1976, dois pesquisadores da IBM, Patricia Griffiths e Bradford Wade, publicaram "An Authorization Mechanism for a Relational Database System" — o paper que descreveu o modelo de autorização construído para o System R, o protótipo que deu origem ao SQL. O problema que eles resolviam era muito concreto: pela primeira vez, múltiplos departamentos e usuários compartilhavam o mesmo banco de dados físico, em vez de cada aplicação ter seus próprios arquivos isolados. Alguém no financeiro não deveria conseguir apagar tabelas de RH só porque tinha acesso ao mesmo servidor. Esse paper é literalmente a origem do GRANT/REVOKE que você usa hoje.

GRANT, concedendo privilégios

GRANT SELECT, INSERT ON pedidos TO usuario_vendas;
GRANT ALL PRIVILEGES ON clientes TO admin_sistema;
GRANT EXECUTE ON PROCEDURE transferir_saldo TO app_usuario;

Você concede ações específicas (SELECT, INSERT, UPDATE, DELETE, EXECUTE...) sobre objetos específicos (tabelas, views, procedures) para usuários ou roles específicos.

REVOKE, retirando privilégios

REVOKE INSERT ON pedidos FROM usuario_vendas;
REVOKE ALL PRIVILEGES ON clientes FROM ex_funcionario;

O oposto simétrico do GRANT — remove exatamente o que foi concedido, sem afetar outros privilégios que a pessoa já tinha.

WITH GRANT OPTION, repassando permissões

Isso permite que gerente_vendas também conceda esse mesmo privilégio para outras pessoas — útil para delegar administração de acesso sem te tornar um gargalo, mas usado com cautela (cada nível de repasse é um lugar a mais onde o controle pode escapar).

SQL: Data Integrity Constraints

Yuri Peixinho — Wed, 22 Jul 2026 16:44:04 +0000

Introdução

Em 1970, um matemático da IBM chamado Edgar F. Codd publicou um paper chamado "A Relational Model of Data for Large Shared Data Banks". Antes disso, os bancos de dados eram majoritariamente hierárquicos ou baseados em arquivos simples (como o IMS da própria IBM, de 1966) — e a garantia de que os dados faziam sentido era inteiramente responsabilidade da aplicação. Se um programador esquecesse de checar se um cliente existia antes de gravar um pedido, ou se duas aplicações diferentes escreviam no mesmo arquivo com regras diferentes, os dados simplesmente ficavam inconsistentes. Não existia rede de segurança dentro do banco.

Quando Codd formalizou o modelo relacional, e depois, em 1985, publicou suas famosas "12 regras" para o que um banco verdadeiramente relacional deveria garantir, uma delas — a Regra 10, "Integrity Independence" — dizia algo radical para a época: as regras de integridade não podem depender da aplicação. Elas precisam viver dentro do banco, no catálogo, indissociáveis dos dados. É essa ideia, de quase 50 anos atrás, que sustenta tudo que vamos ver a seguir.

E não é só sobre corrupção de dados por acidente. É também sobre quem pode tocar no quê. Segundo o Cost of a Data Breach Report da IBM (2023), o custo médio global de uma violação de dados passou de US$ 4,45 milhões — e o Data Breach Investigations Report da Verizon, ano após ano, aponta credenciais comprometidas e uso indevido de privilégios como alguns dos vetores mais recorrentes de invasão. Integridade e segurança não são burocracia: são a diferença entre um banco confiável e um acidente esperando para acontecer.

Constraints

Constraints são regras que você declara junto com a estrutura da tabela, e que o próprio banco passa a fiscalizar automaticamente, sem depender de nenhuma aplicação lembrar de validar nada. Se uma regra é violada, o banco simplesmente recusa a operação, não importa de onde ela veio (seu backend, um script de outro time, uma query manual de madrugada).

`NOT NULL`, a garantia mais básica

CREATE TABLE clientes (
  id INT PRIMARY KEY,
  nome VARCHAR(100) NOT NULL,
  email VARCHAR(100) NOT NULL
);

Impede que um campo essencial fique vazio. Parece trivial, mas é a constraint que mais previne bugs silenciosos em relatórios (COUNT, SUM e JOIN se comportam de forma traiçoeira quando encontram NULL inesperado, como vimos quando falamos de COALESCE e NULLIF).

`UNIQUE`, sem duplicatas

CREATE TABLE clientes (
  id INT PRIMARY KEY,
  cpf VARCHAR(11) UNIQUE,
  email VARCHAR(100) UNIQUE
);

Garante que dois clientes nunca terão o mesmo CPF ou e-mail — o banco rejeita o segundo INSERT antes mesmo dele acontecer.

`PRIMARY KEY`, identidade única da linha

Combina NOT NULL + UNIQUE, e é o identificador que outras tabelas usam para apontar para essa linha:

CREATE TABLE produtos (
  id INT PRIMARY KEY,
  nome VARCHAR(100) NOT NULL
);

`FOREIGN KEY`, integridade referencial (a mais importante do artigo)

Esta é, historicamente, a constraint que Codd mais insistiu em formalizar. Ela garante que uma linha não pode referenciar algo que não existe:

CREATE TABLE pedidos (
  id INT PRIMARY KEY,
  cliente_id INT NOT NULL,
  FOREIGN KEY (cliente_id) REFERENCES clientes(id)
);

Sem isso, seria possível criar um pedido apontando para cliente_id = 9999, quando o cliente 9999 nunca existiu (ou foi deletado) — um registro órfão, que quebra relatórios e JOINs silenciosamente.

O que fazer quando o "pai" é deletado? Isso é definido em ON DELETE:

FOREIGN KEY (cliente_id) REFERENCES clientes(id) ON DELETE CASCADE    -- deleta os pedidos junto
FOREIGN KEY (cliente_id) REFERENCES clientes(id) ON DELETE SET NULL   -- pedido fica "sem cliente"
FOREIGN KEY (cliente_id) REFERENCES clientes(id) ON DELETE RESTRICT-- impede deletar o cliente enquanto houver pedidos (padrão mais seguro)

`CHECK`, regras de negócio arbitrárias

CREATE TABLE produtos (
  id INT PRIMARY KEY,
  preco NUMERIC NOT NULL CHECK (preco > 0),
  desconto NUMERIC CHECK (desconto BETWEEN 0 AND 100)
);

Diferente das constraints anteriores (que são estruturais), CHECK valida regras de negócio arbitrárias — preço não pode ser negativo, desconto não pode passar de 100%. É a forma mais direta de embutir uma regra de domínio na própria estrutura da tabela.

`DEFAULT`, preenchendo lacunas com sensatez

CREATE TABLE pedidos (
  id INT PRIMARY KEY,
  status VARCHAR(20) DEFAULT 'pendente',
  criado_em TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Não impede um valor inválido, mas garante que, na ausência de um valor explícito, o banco preenche algo sensato, evitando que NULLs se espalhem por falta de atenção da aplicação.

O fio condutor de tudo isso: a integridade sai da aplicação e vai para o banco. Exatamente a tese que Codd defendia em 1985, e que continua sendo a diferença entre um sistema que se autopolicia e um que depende da sorte de todo desenvolvedor lembrar de validar tudo, sempre, em todo lugar que escreve no banco.

SQL: Stored Procedures e Functions

Yuri Peixinho — Wed, 22 Jul 2026 03:29:55 +0000

Introdução

Quando você manda uma query SQL avulsa, o banco faz isso toda vez:

Parse — analisa a sintaxe.
Otimização — decide o melhor plano de execução (quais índices usar, ordem dos JOINs, etc.).
Execução — roda de fato.

Uma stored procedure/function é salva no banco com nome próprio, e o banco guarda (ou reutiliza) o plano de execução já otimizado para as próximas chamadas. Isso poupa o trabalho de reanalisar e replanejar a mesma lógica repetidamente — é isso que "precompilado" quer dizer na prática (não é bytecode compilado feito um .exe, é o plano de execução em cache).

Stored Procedures

Um bloco de código SQL + lógica procedural (variáveis, IF, WHILE, loops) salvo no banco, que você executa/chama — não usa dentro de um SELECT.

Sintaxe (varia bastante entre bancos)

SQL Server (T-SQL):

CREATE PROCEDURE TransferirSaldo
  @conta_origem INT,
  @conta_destino INT,
  @valor DECIMAL(10,2)
AS
BEGIN
  UPDATE contas SET saldo = saldo - @valor WHERE id = @conta_origem;
  UPDATE contas SET saldo = saldo + @valor WHERE id = @conta_destino;
END;

-- Chamando:
EXEC TransferirSaldo @conta_origem= 1, @conta_destino= 2, @valor= 100;

Repare que já conectamos com assunto de Transact e ACID: a procedure encapsula a transação inteira (os dois UPDATEs) — isso é extremamente comum na prática. A lógica de negócio "transferência bancária" mora em um único lugar, versionada e reutilizável.

Parâmetros: `IN`, `OUT` e `INOUT`

`IN` (padrão)	Recebe um valor de fora para dentro da procedure
`OUT`	Devolve um valor calculado de dentro para fora, para a variável do chamador
`INOUT`	Funciona nos dois sentidos — entra com um valor, sai modificado

Lógica procedural: variáveis, IF, loops

Isso é o que diferencia uma procedure de um SELECT comum. Ela pode ter controle de fluxo, como uma linguagem de programação de verdade:

CREATE PROCEDURE processar_pedidos_pendentes()
LANGUAGE plpgsql
AS $$
DECLARE
  pedido RECORD;
  contadorINT := 0;
BEGIN
  FOR pedidoIN SELECT * FROM pedidos WHERE status = 'pendente' LOOP
    IF pedido.total > 1000 THEN
      UPDATE pedidos SET status = 'em_analise' WHERE id = pedido.id;
    ELSE
      UPDATE pedidos SET status = 'aprovado' WHERE id = pedido.id;
    END IF;
    contador := contador+ 1;
  END LOOP;

  RAISE NOTICE'% pedidos processados', contador;
END;
$$;

Isso é impossível de fazer em um SELECT puro. É por isso que procedures existem: para lógica que precisa de passos sequenciais, decisões e repetição, não só "buscar dados".

Functions

Um bloco de código salvo no banco que obrigatoriamente retorna um valor, e pode ser usado dentro de outras queries — em SELECT, WHERE, ORDER BY — exatamente como ROUND() ou UPPER() (que são, na verdade, funções nativas do banco; as suas são "customizadas").

Sintaxe

CREATE FUNCTION CalcularIdade(@data_nascimento DATE)
RETURNS INT
AS
BEGIN
  RETURN DATEDIFF(YEAR, @data_nascimento, GETDATE());
END;

SELECT nome, dbo.CalcularIdade(data_nascimento) AS idade FROM clientes;

Scalar Function vs. Table-Valued Function

Tipo	Retorna	Exemplo de uso
Scalar	Um único valor (número, texto, data)	`calcular_idade()` acima — um INT por linha
Table-valued	Uma tabela inteira (linhas e colunas)	Uma função que retorna "todos os pedidos de um cliente"

-- Table-valued function (PostgreSQL):
CREATE FUNCTION pedidos_do_cliente(cliente_id INT)
RETURNS TABLE(pedido_id INT, total NUMERIC, data DATE)
LANGUAGE plpgsql
AS $$
BEGIN
  RETURN QUERY
    SELECT id, total, data_pedido FROM pedidos WHERE cliente_id = $1;
END;
$$;

-- Usando como se fosse uma tabela:
SELECT * FROM pedidos_do_cliente(1) WHERE total > 100;

Isso conecta diretamente com view. Uma table-valued function é como uma "view com parâmetros". A view não aceita argumentos; a function sim.

Diferenças cruciais: Procedure vs. Function

Stored Procedure	Function
Retorno	Opcional (pode não retornar nada, ou retornar via `OUT`)	Obrigatório — sempre retorna um valor
Uso em SELECT	❌ Não pode ser usada dentro de um `SELECT`/`WHERE`	✅ Pode ser usada como se fosse uma coluna/expressão
Como se chama	`CALL procedure(...)` / `EXEC procedure`	Dentro de uma query: `SELECT function(...)`
Transações	✅ Pode conter `COMMIT`/`ROLLBACK` dentro dela	❌ Geralmente não pode controlar transação (roda dentro da transação de quem chamou)
Parâmetros de saída	Suporta `OUT`/`INOUT`	Só retorno via `RETURN` (sem `OUT` na maioria dos bancos)
Efeitos colaterais (side effects)	Esperado — fazer `INSERT`/`UPDATE`/`DELETE` é o uso típico	Deveria ser evitado — functions idealmente são "puras" (calculam e retornam, sem alterar dados), embora tecnicamente algumas linguagens permitam
Uso típico	Automatizar processos, lotes, transações complexas	Cálculos reutilizáveis, regras de negócio usadas em queries

Regra prática para decidir qual usar: se você precisa buscar/calcular e devolver um valor para usar dentro de uma query, use function. Se você precisa executar uma sequência de ações (múltiplos UPDATEs, lógica de transação, processamento em lote), use procedure.

Transactions & ACID

Yuri Peixinho — Wed, 22 Jul 2026 02:41:43 +0000

ACID

Toda vez que você faz uma transferência bancária, finaliza uma compra online ou reserva um assento num voo, um banco de dados está tomando decisões em frações de segundo que determinam se aquela operação aconteceu de verdade, ou não aconteceu de jeito nenhum. O mecanismo que garante isso tem nome: ACID.

O conceito foi formalizado pelo cientista Jim Gray no final dos anos 1970, numa época em que bancos de dados começavam a ser usados em sistemas críticos e os engenheiros precisavam de um vocabulário preciso para falar sobre confiabilidade. Décadas depois, as quatro propriedades que ele descreveu continuam sendo o padrão pelo qual julgamos a solidez de qualquer banco de dados transacional.

Atomicidade

Uma transação é atômica quando ela é tudo ou nada. Não existe estado intermediário.

Imagine uma transferência de R$500 entre duas contas. A operação envolve dois passos: debitar da conta A e creditar na conta B. Se o sistema cair exatamente entre esses dois passos, o que acontece? Sem atomicidade, o dinheiro some — saiu de A, mas nunca chegou em B. Com atomicidade, o banco de dados garante que ou os dois passos acontecem juntos, ou nenhum deles é confirmado. A transação incompleta é desfeita automaticamente.

Consistência

Consistência garante que uma transação sempre leva o banco de dados de um estado válido para outro estado válido, respeitando todas as regras definidas no esquema — chaves estrangeiras, restrições de unicidade, campos obrigatórios.

Se uma regra diz que o saldo de uma conta não pode ser negativo, nenhuma transação pode violar isso. Mesmo que a transação seja atomicamente executada, ela será rejeitada se o resultado final quebrar uma restrição. O banco de dados nunca fica num estado que contradiz suas próprias regras.

Isolamento

Bancos de dados reais lidam com milhares de transações simultâneas. O isolamento define o quanto uma transação em andamento é visível para as outras.

Sem isolamento, dois usuários comprando o último ingresso disponível ao mesmo tempo poderiam ambos ver o ingresso como disponível, ambos confirmar a compra, e o sistema acabar com um ingresso vendido duas vezes. Com isolamento, as transações se comportam como se estivessem sendo executadas em série, uma após a outra — mesmo que na prática estejam rodando em paralelo.

Na prática, isolamento total tem um custo de desempenho alto, então os SGBDRs oferecem níveis de isolamento configuráveis — do mais permissivo (Read Uncommitted) ao mais restritivo (Serializable) — permitindo que cada sistema escolha o equilíbrio certo entre segurança e velocidade.

Durabilidade

Uma vez que o banco confirma uma transação — retornando um "commit" — aquele dado persiste, independente do que aconteça a seguir. Queda de energia, falha de hardware, reinicialização do servidor: nada desfaz uma transação já confirmada.

Isso é garantido por mecanismos como o write-ahead log (WAL): antes de qualquer dado ser modificado no disco, a intenção da modificação é registrada num log separado. Se o sistema cair no meio do processo, o banco consegue se recuperar relendo esse log e replicando as operações que ainda não haviam sido concluídas.

Por o ACID que importa?

ACID não é um detalhe de implementação, é uma promessa. Quando um banco de dados diz que é ACID-compliant, ele está dizendo que você pode confiar nele para operações onde o custo de um erro é alto.

É por isso que sistemas financeiros, hospitalares e de e-commerce continuam usando SGBDRs mesmo quando a escala poderia justificar uma alternativa. E é também por isso que, quando sistemas NoSQL precisam garantir transações confiáveis, eles acabam implementando suas próprias versões dessas propriedades — como o MongoDB fez ao adicionar transações multi-documento em 2018, décadas depois de o modelo relacional já oferecê-las por padrão.

Transactions

Aprender o ACID é fundamental para entender os conceitos de BEGIN, COMMIT, ROLLBACK, SAVEPOINT. Vou supor que o você realizou a leitura anterior. Cada um desses comandos acima existem para entregar as 4 garantias do ACID na prática.

Letra	Significa	O que garante
Atomicity	Atomicidade	Tudo ou nada — a transferência bancária inteira acontece, ou nenhuma parte dela acontece
Consistency	Consistência	O banco nunca fica num estado que viole regras (ex: saldo negativo se houver constraint impedindo)
Isolation	Isolamento	Transações simultâneas não "veem" os passos intermediários umas das outras
Durability	Durabilidade	Uma vez confirmada (`COMMIT`), a mudança sobrevive mesmo a uma queda de energia logo em seguid

Antes de entrar na sintaxe, entenda o porquê. Imagine uma transferência bancária: tirar R$100 da conta A e colocar na conta B. Isso são duas operações:

UPDATE contas SET saldo = saldo - 100 WHERE id = 'A';
UPDATE contas SET saldo = saldo + 100 WHERE id = 'B';

Se o banco de dados executar a primeira linha, e exatamente nesse momento o servidor cair (falta de energia, crash, rede caiu), o dinheiro desaparece: saiu da conta A, mas nunca chegou na conta B. Isso é inaceitável.

Uma transação agrupa múltiplas operações em uma unidade atômica: ou todas acontecem, ou nenhuma acontece. Não existe meio-termo. É o mecanismo que garante que o cenário acima nunca aconteça.

BEGIN

Iniciando uma transação.

Sintaxe

BEGIN;
-- ou, dependendo do banco:
BEGIN TRANSACTION;
START TRANSACTION;

Banco	Sintaxe preferida
PostgreSQL	`BEGIN;`
MySQL	`START TRANSACTION;` (`BEGIN` também funciona)
SQL Server	`BEGIN TRANSACTION;` (ou `BEGIN TRAN`)
Oracle	Não precisa de `BEGIN` explícito — toda instrução DML já inicia uma transação implicitamente

O que acontece de fato

BEGIN marca o ponto a partir do qual todas as mudanças ficam "provisórias" — visíveis só dentro dessa mesma conexão/sessão, até que você dê COMMIT (confirmar) ou ROLLBACK (desfazer).

BEGIN;

UPDATE contas SET saldo = saldo - 100 WHERE id = 'A';
UPDATE contas SET saldo = saldo + 100 WHERE id = 'B';

-- Neste ponto, se você abrir outra conexão e consultar a tabela "contas",
-- ainda vai ver os saldos ANTIGOS (a menos que o nível de isolamento seja diferente do padrão)

COMMIT;
-- SÓ AGORA a mudança se torna permanente e visível para todo mundo

Autocommit, o modo “padrão” que você não percebe

Por padrão, a maioria dos bancos roda em modo autocommit: cada instrução SQL individual já é sua própria transação implícita, com COMMIT automático logo depois. É por isso que um UPDATE isolado "simplesmente funciona" sem você nunca ter digitado BEGIN/COMMIT.

BEGIN explícito serve exatamente para desligar esse comportamento automático e agrupar várias instruções manualmente em uma única unidade atômica.

COMMIT

Confirmar a transação

Sintaxe

COMMIT;

O que acontece de fato

COMMIT torna permanentes todas as mudanças feitas desde o BEGIN. A partir desse momento:

As mudanças ficam visíveis para todas as outras conexões/usuários.
As mudanças são duráveis — sobrevivem a uma queda de energia, restart do servidor, etc. (a letra D do ACID).
Não há mais como desfazer via ROLLBACK — se você errou, precisa fazer uma nova transação para corrigir (ex: um novo UPDATE revertendo o valor).

BEGIN;
UPDATE contas SET saldo = saldo - 100 WHERE id = 'A';
UPDATE contas SET saldo = saldo + 100 WHERE id = 'B';
COMMIT;-- agora sim, a transferência está "selada"

Ponto-chave: enquanto não há COMMIT, a transação pode ser desfeita a qualquer momento. Depois do COMMIT, é definitivo.

ROLLBACK

O padrão mais comum no código de uma aplicação (pseudo-código):

BEGIN TRANSACTION
TRY:
  UPDATE contas SET saldo = saldo - 100 WHERE id = 'A'
  UPDATE contas SET saldo = saldo + 100 WHERE id = 'B'
  COMMIT
CATCH (erro):
  ROLLBACK   -- qualquer erro no meio do caminho desfaz tudo

Isso garante que, se a segunda instrução falhar por qualquer motivo (conexão caiu, violação de constraint, timeout), a primeira instrução também é desfeita — nunca fica um saldo debitado sem o correspondente crédito.

Rollback automático em caso de erro grave

Em muitos bancos (Postgres é rigoroso nisso), se uma instrução dentro da transação falhar com erro, a transação inteira entra em estado de "abortada" e qualquer comando subsequente é rejeitado até você mandar ROLLBACK explicitamente — o banco não deixa você simplesmente ignorar o erro e continuar.

SAVEPOINT — Pontos de Rollback Parcial

ROLLBACK sozinho desfaz a transação inteira. Mas e se você tem uma transação longa, com vários passos, e só quer desfazer uma parte dela, mantendo o resto?

Sintaxe

BEGIN;

INSERT INTO pedidos (cliente_id, total)VALUES (1,500);
SAVEPOINT depois_do_pedido;

INSERT INTO itens_pedido (pedido_id, produto_id, quantidade)VALUES (1,99,3);
-- Ops, produto 99 não existe ou regra de negócio falhou

ROLLBACK TO SAVEPOINT depois_do_pedido;
-- Desfaz APENAS o insert de itens_pedido
-- O insert do pedido continua "de pé", esperando dentro da transação

INSERT INTO itens_pedido (pedido_id, produto_id, quantidade)VALUES (1,42,3);
-- Tenta de novo, com dado correto

COMMIT;-- confirma tudo: o pedido + o item correto

Múltiplos savepoints

Você pode ter vários savepoints numa mesma transação, como "checkpoints" em sequência:

BEGIN;
  INSERT INTO log (mensagem)VALUES ('passo 1');
  SAVEPOINT sp1;

  INSERT INTO log (mensagem)VALUES ('passo 2');
  SAVEPOINT sp2;

  INSERT INTO log (mensagem)VALUES ('passo 3');

  ROLLBACK TO SAVEPOINT sp1;-- desfaz "passo 2" E "passo 3", mantém "passo 1"
COMMIT;

Liberando um savepoint sem fazer rollback

RELEASE SAVEPOINT depois_do_pedido;

Isso remove o savepoint (você não pode mais voltar para ele), mas não desfaz nada — as mudanças continuam lá, esperando o COMMIT final.

Uso real: processamento em lote com itens que podem falhar individualmente

BEGIN;
-- Processar 100 pedidos de uma importação, um por um
-- Para cada pedido:
SAVEPOINT antes_do_item;
  INSERT INTO pedidos ...;
  -- se der erro de validação específico desse pedido:
  ROLLBACK TO SAVEPOINT antes_do_item;
  -- continua para o próximo pedido, sem precisar desfazer os 99 anteriores
COMMIT;-- no final, confirma todos os que passaram

⚠️ Nota de compatibilidade: MySQL (InnoDB) e PostgreSQL suportam SAVEPOINT bem. SQL Server também suporta, mas com sintaxe ligeiramente diferente: SAVE TRANSACTION nome_savepoint em vez de SAVEPOINT nome.

SQL: Views

Yuri Peixinho — Wed, 22 Jul 2026 01:57:27 +0000

Introdução

Uma view é uma consulta salva com nome — ela não armazena dados fisicamente (na maioria dos casos), apenas guarda a definição de um SELECT. Toda vez que você consulta a view, o banco executa a query por trás dela e devolve o resultado como se fosse uma tabela.

CREATE VIEW clientes_ativos AS
SELECT id, nome, email FROM clientes WHERE status = 'ativo';

-- Depois, você consulta como se fosse uma tabela normal:
SELECT * FROM clientes_ativos WHERE nome LIKE 'A%';

Pense na view como um "apelido inteligente" para uma query complexa. Em vez de reescrever um JOIN de 4 tabelas toda vez, você cria a view uma vez e reutiliza SELECT * FROM minha_view.

Por que usar views (motivação real)

Simplificação: esconder a complexidade de JOINs/subqueries repetitivos atrás de um nome simples.
Segurança: dar acesso a uma view que expõe só algumas colunas (ex: sem salário, sem CPF), sem dar acesso à tabela real.
Abstração/desacoplamento: se a estrutura das tabelas mudar, você ajusta só a view, e as queries que a usam continuam funcionando sem alteração.
Reuso: centralizar lógica de negócio (ex: "o que conta como pedido válido") em um único lugar, em vez de repetir o mesmo WHERE em 10 queries diferentes.
Legibilidade: transformar um relatório complicado em algo que qualquer pessoa entende: SELECT * FROM vendas_por_mes.

Criando Views

Sintaxe básica

CREATE VIEW nome_da_view AS
SELECT coluna1, coluna2, ...
FROM tabela
WHERE condicao;

Exemplo simples

CREATE VIEW produtos_em_estoque AS
SELECT id, nome, preco, quantidade
FROM produtos
WHERE quantidade > 0;

Agora, em vez de repetir WHERE quantidade > 0 toda vez, qualquer pessoa faz:

SELECT * FROM produtos_em_estoque ORDER BY preco DESC;

Exemplo com JOIN (caso mais comum no mundo real)

Views brilham quando escondem a complexidade de múltiplas tabelas relacionadas:

CREATE VIEW pedidos_detalhados AS
SELECT 
  p.id AS pedido_id,
  c.nome AS cliente,
  pr.nome AS produto,
  p.quantidade,
  p.quantidade * pr.preco AS total,
  p.data_pedido
FROM pedidos p
JOIN clientes c ON p.cliente_id = c.id
JOIN produtos pr ON p.produto_id = pr.id;

Sem a view, toda vez que alguém quisesse ver um pedido "completo" (com nome do cliente e do produto, não só os IDs), precisaria escrever esse JOIN triplo de novo. Com a view:

SELECT * FROM pedidos_detalhados WHERE cliente = 'Maria Silva';

Modificando Views

Existem duas abordagens, dependendo do banco:

Abordagem 1: `CREATE OR REPLACE VIEW` (PostgreSQL, MySQL, Oracle)

Substitui a definição inteira da view de uma vez:

CREATE OR REPLACE VIEW produtos_em_estoque AS
SELECT id, nome, preco, quantidade, categoria
FROM produtos
WHERE quantidade > 0;

Regra importante: CREATE OR REPLACE normalmente só permite adicionar colunas no final, ou mudar a lógica do WHERE/JOIN — você não pode remover uma coluna ou mudar a ordem das colunas existentes sem dar DROP na view primeiro. Se tentar, o banco geralmente recusa com um erro.

Abordagem 2: `ALTER VIEW` (SQL Server, também existe em outros)

ALTER VIEW produtos_em_estoque AS
SELECT id, nome, preco, quantidade, categoria
FROM produtos
WHERE quantidade > 0;

Funciona de forma equivalente ao CREATE OR REPLACE, mas é a sintaxe usada no SQL Server (que não aceita CREATE OR REPLACE VIEW — lá, CREATE VIEW falha se a view já existir, e você precisa usar ALTER VIEW para modificar uma existente).

Por que "substituir" em vez de “editar campo por campo”?

Views não têm um equivalente ao ALTER TABLE ADD COLUMN — você não "adiciona uma coluna" a uma view incrementalmente. Você reescreve a query inteira com CREATE OR REPLACE/ALTER VIEW. Isso é diferente de tabelas, e costuma confundir quem vem de ALTER TABLE.

O que acontece com permissões e dependências ao modificar

Modificar uma view preserva as permissões (GRANT) já concedidas a ela na maioria dos bancos — não precisa re-conceder acesso.
Se outras views dependem da view que você está alterando (lembra do exemplo vendas_por_mes em cima de pedidos_detalhados?), mudar a view de baixo pode quebrar as views de cima se você remover uma coluna que elas usam. Vale sempre mapear as dependências antes de alterar uma view "de base".

Funções Avançadas em SQL

Yuri Peixinho — Wed, 22 Jul 2026 01:24:28 +0000

Introdução

As funções avançadas em SQL vão além de operações básicas, como selecionar e filtrar dados. Elas permitem realizar cálculos complexos, manipular strings, trabalhar com datas e analisar dados de maneiras mais sofisticadas. Essas funções ajudam a obter insights, transformar dados e criar relatórios mais significativos a partir do seu banco de dados.

Essas funções são dividas em algumas categorias:

Funções Numéricas
Funções de String
Funções Condicionais
Funções de Data

Funções Numéricas

`FLOOR(x)` — arredonda para baixo

Sempre "empurra" o número para o inteiro menor ou igual, independente do sinal.

FLOOR(4.7)-- 4
FLOOR(4.1)-- 4
FLOOR(-4.1)-- -5  (atenção: vai para o lado mais negativo, não trunca!)

Uso real: calcular quantas "páginas cheias" cabem em uma lista, ou converter minutos em horas completas: FLOOR(minutos / 60).

`CEILING(x)` — arredonda para cima

O oposto do FLOOR: sempre vai para o inteiro maior ou igual.

CEILING(4.1)-- 5
CEILING(-4.7)-- -4

Uso real: calcular quantos caminhões/caixas você precisa. Se cada caixa cabe 10 itens e você tem 23 itens, precisa de CEILING(23/10.0) = 3 caixas (não 2, que sobraria item de fora).

`ROUND(x, n)` — arredondamento matemático padrão

n é o número de casas decimais, pode ser negativo para arredondar dezenas/centenas.

ROUND(4.567,2)-- 4.57
ROUND(4.565,2)-- 4.56 ou 4.57 (depende do motor — arredondamento bancário vs. "meio para cima")
ROUND(1234,-2)-- 1200  (arredonda para centena mais próxima)

⚠️ Cuidado: o comportamento no .5 exato (round half up vs. round half even/"banker's rounding") varia entre bancos — SQL Server e PostgreSQL não tratam igual. Nunca confie em ROUND para regras fiscais sem testar no seu banco específico.

`ABS(x)` — valor absoluto

Remove o sinal.

ABS(-15)-- 15
ABS(15)-- 15

Uso real: calcular diferença entre duas datas/valores sem se importar com qual é maior: ABS(preco_atual - preco_anterior) para medir variação, independente de subida ou queda.

`MOD(a, b)` — resto da divisão

Equivalente ao operador % em outras linguagens. Note que MOD é uma função em Oracle/MySQL; SQL Server usa o operador % diretamente.

MOD(10,3)-- 1
MOD(9,3)-- 0
MOD(-7,3)-- -1 (sinal segue o dividendo `a`, na maioria dos bancos)

Usos reais:

Paridade: MOD(id, 2) = 0 → linhas pares (útil para zebra striping em relatórios).
Distribuir dados em N grupos/partições: MOD(id, 4) gera 4 grupos (0,1,2,3).
Ciclos: dia da semana, rodízio de placas, etc.

Funções de String

`LENGTH(s)` — tamanho da string

Conta caracteres (não bytes, na maioria dos bancos com suporte a Unicode).

LENGTH('abc')-- 3
LENGTH('')-- 0
LENGTH(NULL)-- NULL (não é 0!)
LENGTH('café')-- 4 caracteres (mas pode variar em bytes se for UTF-8 e você usar OCTET_LENGTH)

⚠️ SQL Server usa LEN() em vez de LENGTH(). Cuidado com espaços em branco à direita — LEN() no SQL Server os ignora, mas LENGTH() no Postgres/MySQL não.

`CONCAT(a, b, ...)`

Antes do CONCAT existir como função padrão, cada banco usava um operador diferente para juntar strings:

Banco	Operador/Sintaxe
PostgreSQL, Oracle	`
SQL Server (antigo)	{% raw %}`+`
MySQL	`CONCAT()` (não suporta `

O {% raw %}CONCAT() como função é a forma padrão ANSI, suportada por praticamente todos os bancos modernos — por isso é a escolha mais portável.

A diferença crucial: tratamento de NULL

Essa é a parte mais importante e mais fonte de bugs:

-- Com operador (Postgres, Oracle, SQL Server antigo)
SELECT 'Rua ' || nome_rua|| ', ' || numero;
-- Se numero for NULL → resultado inteiro é NULL!

-- Com CONCAT (padrão ANSI, MySQL, Postgres 9+, SQL Server 2012+)
SELECT CONCAT('Rua ', nome_rua,', ', numero);
-- Se numero for NULL → NULL é tratado como '' (string vazia)
-- Resultado: 'Rua das Flores, '  (não quebra a linha inteira)

Por que isso importa na prática: imagine montar um endereço completo com 5 campos concatenados. Se você usar || e um único campo (tipo complemento, que é opcional) for NULL, o endereço inteiro vira NULL — some da tela. Com CONCAT(), só aquele pedaço fica vazio, o resto aparece normalmente.

-- Exemplo real: monte um endereço, onde "complemento" costuma ser NULL
SELECT CONCAT(logradouro, ', ', numero, ' - ', COALESCE(complemento, ''), ' ', bairro) AS endereco_completo
FROM clientes;

`SUBSTRING(s, início, tamanho)` — extrai parte da string

Índice começa em 1 (não em 0!).

SUBSTRING('12345678900',1,3)-- '123'
SUBSTRING('12345678900',4,3)-- '456'
SUBSTRING('abcdef',3)-- 'cdef' (sem tamanho, pega até o fim — funciona no Postgres, não em todos)

Usos reais:

Extrair parte de um documento: DDD do telefone, os 3 primeiros dígitos do CPF.
Mascarar dados sensíveis: mostrar só os últimos 4 dígitos de um cartão.

CONCAT('****',SUBSTRING(cartao,LENGTH(cartao)- 3,4))

`REPLACE(s, de, para)` — substitui todas as ocorrências

Substitui todas as ocorrências de de por para (não é case-sensitive de forma consistente — depende do collation do banco).

REPLACE('2026-07-21','-','/')-- '2026/07/21'
REPLACE('aaa','a','bb')-- 'bbbbbb'

Uso real: limpar formatação antes de salvar (remover pontos/traços de CPF/CNPJ), normalizar separadores decimais (, → .) vindos de importação de planilha.

`UPPER(s)` / `LOWER(s)` — maiúsculas/minúsculas

UPPER('sql')-- 'SQL'
LOWER('SQL')-- 'sql'

Uso real mais importante: comparações case-insensitive sem depender do collation da coluna:

WHERE LOWER(email)= LOWER('Usuario@Email.com')

Isso é comum quando o banco tem collation case-sensitive e você quer garantir que "Joao@x.com" e "JOAO@X.COM" sejam tratados como iguais.

Funções Condicionais

`CASE` — estrutura condicional

Duas sintaxes:

CASE simples (compara uma expressão contra valores):

CASE status
  WHEN 'A' THEN 'Ativo'
  WHEN 'I' THEN 'Inativo'
  ELSE 'Desconhecido'
END

CASE com busca (searched CASE) — mais flexível, permite condições complexas:

CASE
  WHEN idade < 18 THEN 'Menor'
  WHEN idade BETWEEN 18 AND 65 THEN 'Adulto'
  WHEN idade > 65 THEN 'Idoso'
  ELSE 'Não informado'
END

Regras importantes:

Avalia condições em ordem e para na primeira verdadeira — a ordem importa.
Se ELSE for omitido e nada bater, retorna NULL.
Pode ser usado em SELECT, WHERE, ORDER BY e até dentro de SUM()/COUNT() para agregações condicionais:

`NULLIF(a, b)` — retorna NULL se forem iguais

NULLIF(5, 5)   -- NULL
NULLIF(5, 3)   -- 5 (retorna 'a' quando são diferentes)

É literalmente um atalho para CASE WHEN a = b THEN NULL ELSE a END

Ou seja: compara a com b. Se forem iguais, retorna NULL. Se forem diferentes, retorna a (nunca b — isso é importante, a função não é simétrica no retorno, mesmo que a comparação seja).

NULLIF(10,10)-- NULL
NULLIF(10,5)-- 10  (retorna 'a', não importa o valor de 'b')
NULLIF(5,10)-- 5

`COALESCE(a, b, c, ...)` — primeiro valor não-nulo

Percorre a lista da esquerda para a direita e retorna o primeiro argumento que não é NULL.

COALESCE(NULL,NULL,'terceiro','quarto')-- 'terceiro'
COALESCE(telefone_celular, telefone_fixo, email,'sem contato')

Funções de Data e Hora

`DATE`, `TIME`, `TIMESTAMP` — tipos e extração

Não são bem "funções" isoladas — são tipos de dado (DATE = só data, TIME = só hora, TIMESTAMP/DATETIME = ambos), mas também aparecem como funções de conversão/cast:

CAST(coluna_timestampAS DATE)-- extrai só a data, descarta a hora
CAST(coluna_timestampAS TIME)-- extrai só a hora
CURRENT_TIMESTAMP-- data+hora atual (padrão ANSI)
CURRENT_DATE-- só a data atual

Uso real: você tem uma coluna created_at TIMESTAMP e quer agrupar por dia, ignorando a hora:

SELECT CAST(created_at AS DATE) AS dia,COUNT(*)
FROM pedidos
GROUP BY CAST(created_at AS DATE);

Sem esse cast, cada created_at com hora diferente formaria um grupo distinto.

`DATEPART(parte, data)` — extrai um componente

Sintaxe do SQL Server. Extrai um pedaço específico da data como número.

DATEPART(YEAR,'2026-07-21')-- 2026
DATEPART(MONTH,'2026-07-21')-- 7
DATEPART(DAY,'2026-07-21')-- 21
DATEPART(WEEKDAY,'2026-07-21')-- dia da semana (numérico)
DATEPART(QUARTER,'2026-07-21')-- 3 (terceiro trimestre)

Equivalentes em outros bancos:

PostgreSQL: EXTRACT(YEAR FROM data)
MySQL: YEAR(data), MONTH(data), DAY(data)

Uso real: relatórios agrupados por período — vendas por mês, por trimestre, por ano:

SELECT DATEPART(YEAR, data_pedido) AS ano,DATEPART(MONTH, data_pedido) AS mes,SUM(valor)
FROM pedidos
GROUP BY DATEPART(YEAR, data_pedido), DATEPART(MONTH, data_pedido);

`DATEADD(parte, n, data)` — soma/subtrai intervalo

DATEADD(DAY,30,'2026-07-21')-- 2026-08-20
DATEADD(MONTH,-1,'2026-07-21')-- 2026-06-21
DATEADD(YEAR,1,'2026-07-21')-- 2027-07-21

n negativo subtrai. Equivalentes:

PostgreSQL: data + INTERVAL '30 days'
MySQL: DATE_ADD(data, INTERVAL 30 DAY)

Usos reais:

Data de vencimento: DATEADD(DAY, 30, data_pedido).
Janela de tempo relativa a hoje: WHERE data_pedido >= DATEADD(DAY, -7, GETDATE()) → últimos 7 dias.
Calcular idade: DATEDIFF(YEAR, data_nascimento, GETDATE()) (função irmã do DATEADD).

DEV Community: Yuri Peixinho

Cluster 4: #10 testes rápidos e independentes, #13 simplicidade e refatoração contínua

Introdução

#10 Testes Rápidos e Independentes

Exemplo — teste lento e acoplado vs. teste rápido e isolado:

Exemplo — teste dependente de ordem vs. independente:

#13 Simplicidade e Refatoração Contínua

Exemplo — duplicação que se acumula em silêncio:

Cluster 3: #8 distância do framework, #11 organizar por ator, #9 constructs corretos

Introdução

#8 Distância do Framework

#11 Organizar por Ator

#9 Constructs Corretos

1. Escolha a ferramenta certa pro problema — não a que você "sabe usar melhor"

2. Evite variáveis globais — passe dados via parâmetros e retornos

3. Evite complexidade desnecessária

4. Control flow lógico e intuitivo

Cluster 2: #5 funções puras, #7 evitar null/booleanos, #12 command query separation

Introdução

#5 Funções Puras

#7 Evitar null/booleanos

Exemplo — null com múltiplos significados:

Exemplo — booleano que vira flag de reaproveitamento:

#12 Command Query Separation

Exemplo clássico — método que parece query mas é comando:

Correção:

Cluster 1 do Clean Code: #1 consistência, #2 nomes, #3 estilo, #4 métodos/classes/arquivos pequenos, #6 complexidade ciclomática

Introdução

#1 Be Consistent

#2 Meaningful names over comments

#3 Indentation and Code Style

#4 Keep methods / classes / files small

#6 Minimize cyclomatic complexity

4 Clusters do Clean Code Principles

Introdução

Os 13 Princípios

Cluster 1 — Limíte físico da memória de trabalho humanada.

Cluster 2 — Estado escondido é a causa rais dos bugs mais caros de rastrear

Cluster 3 — Mudança é garantida; a estrutura decisde se ela sai barata ou cara

Cluster 4 — Sem rede de segurança rápida, toda a disciplina anterior apodrece sozinha

SQL: Melhores Práticas de Segurança

Introdução

Princípio do menor privilégio

Nunca concatenar SQL, sempre parametrizar

Criptografia em trânsito e em repouso

Auditoria e Logging

Separação de ambientes e contas de serviço

Backups testados

SQL: GRANT and REVOKE

Introdução

GRANT, concedendo privilégios

REVOKE, retirando privilégios

WITH GRANT OPTION, repassando permissões

SQL: Data Integrity Constraints

Introdução

Constraints

NOT NULL, a garantia mais básica

UNIQUE, sem duplicatas

PRIMARY KEY, identidade única da linha

FOREIGN KEY, integridade referencial (a mais importante do artigo)

CHECK, regras de negócio arbitrárias

DEFAULT, preenchendo lacunas com sensatez

SQL: Stored Procedures e Functions

Introdução

Stored Procedures

Parâmetros: IN, OUT e INOUT

Lógica procedural: variáveis, IF, loops

Functions

Scalar Function vs. Table-Valued Function

Diferenças cruciais: Procedure vs. Function

Transactions & ACID

ACID

Atomicidade

Consistência

Isolamento

Durabilidade

Por o ACID que importa?

Transactions

BEGIN

Sintaxe

`NOT NULL`, a garantia mais básica

`UNIQUE`, sem duplicatas

`PRIMARY KEY`, identidade única da linha

`FOREIGN KEY`, integridade referencial (a mais importante do artigo)

`CHECK`, regras de negócio arbitrárias

`DEFAULT`, preenchendo lacunas com sensatez

Parâmetros: `IN`, `OUT` e `INOUT`

Abordagem 1: `CREATE OR REPLACE VIEW` (PostgreSQL, MySQL, Oracle)

Abordagem 2: `ALTER VIEW` (SQL Server, também existe em outros)

`FLOOR(x)` — arredonda para baixo

`CEILING(x)` — arredonda para cima

`ROUND(x, n)` — arredondamento matemático padrão

`ABS(x)` — valor absoluto

`MOD(a, b)` — resto da divisão

`LENGTH(s)` — tamanho da string

`CONCAT(a, b, ...)`

`SUBSTRING(s, início, tamanho)` — extrai parte da string

`REPLACE(s, de, para)` — substitui todas as ocorrências

`UPPER(s)` / `LOWER(s)` — maiúsculas/minúsculas

`CASE` — estrutura condicional

`NULLIF(a, b)` — retorna NULL se forem iguais

`COALESCE(a, b, c, ...)` — primeiro valor não-nulo

`DATE`, `TIME`, `TIMESTAMP` — tipos e extração

`DATEPART(parte, data)` — extrai um componente

`DATEADD(parte, n, data)` — soma/subtrai intervalo