Dijkstra & Programação Estruturada: Disciplina que Escala

Por que Dijkstra ainda importa quando o software cresce

Software raramente falha porque não pode ser escrito. Falha porque, um ano depois, ninguém consegue mudá‑lo com segurança.

À medida que bases de código crescem, todo ajuste “pequeno” começa a repercutir: um conserto de bug quebra uma funcionalidade distante, um novo requisito força reescritas, e um refatoramento simples vira uma semana de coordenação cuidadosa. O difícil não é adicionar código — é manter o comportamento previsível enquanto tudo ao redor muda.

A promessa: correção e simplicidade reduzem o custo no longo prazo

Edsger Dijkstra defendia que correção e simplicidade deveriam ser objetivos de primeira classe, não algo opcional. O retorno não é acadêmico. Quando um sistema é mais fácil de raciocinar, equipes gastam menos tempo apagando incêndios e mais tempo construindo.

• Correção reduz o custo dos erros: menos incidentes, menos regressões, menos código “não toque nisso”.
• Simplicidade reduz o custo da mudança: menos suposições ocultas, menos casos especiais, menos surpresas durante revisões.

O que “escala” realmente significa

Quando as pessoas dizem que software precisa “escalar”, muitas vezes querem dizer desempenho. O ponto de Dijkstra é diferente: complexidade também escala.

A escala aparece como:

• Mais funcionalidades: novos fluxos, casos de borda e expectativas de usuário.
• Mais pessoas: repasses, estilos diferentes e contextos variados.
• Mais integrações: APIs externas, fontes de dados e modos de falha.
• Mais tempo: decisões legadas, requisitos mutantes e reescritas parciais.

A ideia central: estrutura torna o comportamento mais previsível

Programação estruturada não é ser rígido por si só. É escolher fluxo de controle e decomposição que facilitem responder duas perguntas:

• “O que acontece a seguir?”
• “Em que condições isso acontece?”

Quando o comportamento é previsível, a mudança vira rotina em vez de risco. Por isso Dijkstra ainda importa: sua disciplina mira o gargalo real do software em crescimento — entendê‑lo bem o suficiente para melhorá‑lo.

Uma introdução simples a Edsger Dijkstra e seu objetivo

Edsger W. Dijkstra (1930–2002) foi um cientista da computação holandês que ajudou a moldar como programadores pensam sobre construir software confiável. Trabalhou em sistemas operacionais iniciais, contribuiu para algoritmos (incluindo o algoritmo de caminho mínimo que leva seu nome) e — o mais importante para desenvolvedores do dia a dia — defendeu a ideia de que programar deveria ser algo que podemos raciocinar, não só algo que tentamos até parecer funcionar.

Seu foco central: raciocinar além do “funciona na minha máquina”

Dijkstra se preocupava menos se um programa podia ser ajustado para produzir a saída correta em alguns exemplos e mais se podíamos explicar por que ele está correto para os casos que importam.

Se você pode dizer o que um trecho de código deve fazer, deveria ser capaz de argumentar (passo a passo) que ele realmente faz isso. Essa mentalidade naturalmente leva a código mais fácil de seguir, revisar e menos dependente de depurações heróicas.

Por que ele pode soar rígido — e por que isso ajuda

Alguns escritos de Dijkstra soam intransigentes. Ele criticava truques “espertos”, fluxo de controle descuidado e hábitos de programação que dificultam o raciocínio. A rigidez não é policiamento de estilo; é redução de ambiguidade. Quando o significado do código está claro, você gasta menos tempo debatendo intenções e mais tempo validando comportamento.

O que “programação estruturada” significa (alto nível)

Programação estruturada é a prática de construir programas a partir de um pequeno conjunto de estruturas de controle claras — sequência, seleção (if/else) e iteração (loops) — em vez de saltos emaranhados no fluxo. O objetivo é simples: tornar o caminho através do programa compreensível para que você possa explicá‑lo, mantê‑lo e modificá‑lo com confiança.

Correção: a feature oculta em que seus usuários confiam

As pessoas costumam descrever qualidade de software como “rápido”, “bonito” ou “cheio de recursos”. Usuários experimentam correção de forma diferente: como a confiança silenciosa de que o app não vai surpreendê‑los. Quando a correção existe, ninguém nota. Quando falta, nada mais importa.

“Funciona agora” vs “continua funcionando”

“Funciona agora” geralmente significa que você tentou alguns caminhos e obteve o resultado esperado. “Continua funcionando” significa que se comporta como pretendido no tempo, em casos de borda e mudanças — depois de refatores, novas integrações, maior tráfego e novos membros da equipe mexendo no código.

Uma funcionalidade pode “funcionar agora” e ainda assim ser frágil:

• Depende de entrada sempre limpa.
• Assume que uma chamada de rede sempre retorna rápido.
• Passa testes que cobrem só o caminho feliz.

Correção é remover essas suposições ocultas — ou torná‑las explícitas.

Como pequenos bugs se multiplicam em sistemas grandes

Um bug menor raramente fica pequeno quando o software cresce. Um estado incorreto, um off‑by‑one ou uma regra de tratamento de erro pouco clara é copiado em novos módulos, envolvido por outros serviços, cacheado, reencaminhado ou “contornado”. Com o tempo, equipes param de perguntar “o que é verdade?” e começam a perguntar “o que geralmente acontece?” — aí a resposta a incidentes vira arqueologia.

O multiplicador é a dependência: um pequeno mau comportamento vira muitos comportamentos indevidos a jusante, cada um com sua correção parcial.

Clareza é uma ferramenta de correção (não só uma escolha de estilo)

Código claro melhora correção porque melhora comunicação:

• Revisões de código capturam problemas reais quando a intenção é óbvia.
• Integração de novos membros é mais rápida quando regras são legíveis, não conhecimento tribal.
• Incidentes se resolvem mais rápido quando fluxo de controle e modos de falha são fáceis de rastrear.

Uma definição prática de correção para times de produto

Correção significa: para as entradas e situações que afirmamos suportar, o sistema produz consistentemente os resultados que prometemos — e falha de maneiras previsíveis e explicáveis quando não pode.

Simplicidade como estratégia, não preferência de estilo

Simplicidade não é sobre deixar o código “fofo”, mínimo ou esperto. É sobre tornar o comportamento fácil de prever, explicar e modificar sem medo. Dijkstra valorizava simplicidade porque ela melhora nossa habilidade de raciocinar sobre programas — especialmente quando a base de código e a equipe crescem.

O que simplicidade é (e o que não é)

Código simples mantém poucas ideias em movimento ao mesmo tempo: fluxo de dados claro, fluxo de controle claro e responsabilidades definidas. Não força o leitor a simular muitos caminhos alternativos na cabeça.

Simplicidade não é:

• Menos linhas a qualquer custo
• Truques “espertos”, one‑liners densos ou abstrações pesadas
• Evitar estrutura para parecer flexível

Complexidade acidental: o que você não quis adicionar

Muitos sistemas ficam difíceis de mudar não porque o domínio é intrinsecamente complexo, mas porque introduzimos complexidade acidental: flags que interagem de formas inesperadas, patches para casos especiais que nunca saem, e camadas que existem principalmente para contornar decisões anteriores.

Cada exceção extra é um imposto sobre entendimento. O custo aparece depois, quando alguém tenta consertar um bug e descobre que uma mudança em uma área quebra sutilmente várias outras.

Designs simples reduzem a necessidade de heroísmos

Quando um design é simples, progresso vem de trabalho constante: mudanças revisáveis, diffs menores e menos correções de emergência. Equipes não precisam de desenvolvedores “heróis” que lembram todos os casos históricos ou conseguem debugar sob pressão às 2h da manhã. Em vez disso, o sistema suporta a atenção humana normal.

Regra prática: menos casos especiais, menos surpresas

Um teste prático: se você continua adicionando exceções (“a não ser que…”, “exceto quando…”, “só para este cliente…”), provavelmente está acumulando complexidade acidental. Prefira soluções que reduzam ramificações de comportamento — uma regra consistente vence cinco casos especiais, mesmo que a regra seja ligeiramente mais geral do que você imaginou inicialmente.

Programação estruturada: fluxo de controle claro em que você pode confiar

Programação estruturada é uma ideia simples com grandes consequências: escreva código de modo que seu caminho de execução seja fácil de seguir. Em termos simples, a maioria dos programas pode ser construída a partir de três blocos de construção — sequência, seleção e repetição — sem depender de saltos emaranhados.

Os três blocos de construção (em termos humanos)

• Sequência: faça o passo A, depois B, depois C.
• Seleção: escolha um caminho com base numa condição (por exemplo, if/else, switch).
• Repetição: repita um conjunto de passos enquanto uma condição for verdadeira (por exemplo, for, while).

Quando o fluxo de controle é composto por essas estruturas, você geralmente consegue explicar o que o programa faz lendo de cima para baixo, sem “teletransportar” por todo o arquivo.

O que isso substituiu: caminhos de execução espaguete

Antes de programação estruturada se tornar norma, muitas bases de código usavam saltos arbitrários (o clássico goto). O problema não é que saltos sejam sempre ruins; é que saltos sem restrição criam caminhos de execução difíceis de prever. Você acaba perguntando “Como chegamos aqui?” e “Em que estado está essa variável?” — e o código não responde claramente.

Por que clareza importa para equipes reais

Fluxo de controle claro ajuda humanos a construir um modelo mental correto. Esse modelo é o que você usa ao debugar, revisar um pull request ou mudar comportamento sob pressão.

Quando a estrutura é consistente, modificar vira mais seguro: você pode mudar um ramo sem afetar outro acidentalmente, ou refatorar um loop sem perder uma saída escondida. Legibilidade não é só estética — é a base para mudar comportamento com confiança sem quebrar o que já funciona.

Ferramentas de raciocínio: invariantes, precondições e pós‑condições

Dijkstra defendia uma ideia simples: se você consegue explicar por que seu código está correto, pode mudá‑lo com menos medo. Três pequenas ferramentas de raciocínio tornam isso prático — sem transformar sua equipe em matemáticos.

Invariantes: “fatos que permanecem verdadeiros”

Um invariante é um fato que permanece verdadeiro enquanto um pedaço de código roda, especialmente dentro de um loop.

Exemplo: você está somando preços em um carrinho. Um invariante útil é: “total é igual à soma de todos os itens processados até agora.” Se isso permanece verdadeiro a cada passo, quando o loop terminar o resultado é confiável.

Invariantes são poderosas porque focam sua atenção no que nunca deve quebrar, não só no que deve acontecer em seguida.

Precondições e pós‑condições: contratos do dia a dia

Uma precondição é o que deve ser verdade antes de uma função rodar. Uma pós‑condição é o que a função garante depois de terminar.

Exemplos cotidianos:

• Precondição: “Você só pode sacar dinheiro se a conta tem saldo suficiente.”
• Pós‑condição: “Após o saque, o saldo é reduzido exatamente naquela quantia e nunca fica negativo.”

No código, uma precondição pode ser “a lista de entrada está ordenada” e a pós‑condição pode ser “a lista de saída está ordenada e contém os mesmos elementos mais o inserido”.

Como escrevê‑las muda o código e as revisões

Quando você as escreve (mesmo informalmente), o design fica mais afiado: você decide o que uma função espera e promete, e naturalmente a torna menor e mais focada.

Nas revisões, isso desloca o debate de estilo (“Eu escrevia diferente”) para correção (“Isso mantém o invariante?” “Enforçamos a precondição ou apenas documentamos?”).

Prática leve: comente onde bugs se concentram

Você não precisa de provas formais para se beneficiar. Pegue o loop mais problemático ou a atualização de estado mais traiçoeira e adicione um invariante de uma linha acima. Quando alguém editar o código depois, esse comentário age como um guard‑rail: se uma mudança quebra esse fato, o código não é mais seguro.

Testes vs raciocínio: o que cada um pode (e não pode) garantir

Testes e raciocínio têm o mesmo objetivo — software que se comporta como pretendido — mas funcionam de maneiras diferentes. Testes descobrem problemas testando exemplos. Raciocínio previne categorias inteiras de problemas ao tornar a lógica explícita e verificável.

Para que testes são ótimos

Testes são uma rede de segurança prática. Pegam regressões, verificam cenários do mundo real e documentam comportamento esperado de uma forma que toda a equipe pode executar.

Mas testes só mostram a presença de bugs, não a ausência. Nenhuma suíte de testes cobre todo input, toda variação de timing ou toda interação entre funcionalidades. Muitos falhas “funciona na minha máquina” vêm de combinações não testadas: uma entrada rara, uma ordem específica de operações ou um estado sutil que aparece após vários passos.

O que o raciocínio pode garantir (e o que não pode)

Raciocínio trata de provar propriedades do código: “este loop sempre termina”, “esta variável nunca é negativa”, “esta função nunca retorna um objeto inválido”. Bem feito, exclui classes inteiras de defeitos — especialmente em fronteiras e casos de borda.

A limitação é esforço e escopo. Provas formais para um produto inteiro raramente são econômicas. Raciocínio funciona melhor aplicado seletivamente: algoritmos centrais, fluxos sensíveis à segurança, lógica de cobrança e concorrência.

Uma abordagem balanceada que escala

Use testes amplamente e aplique raciocínio mais profundo onde a falha é cara.

Uma ponte prática entre os dois é tornar a intenção executável:

• Asserções para suposições internas (por exemplo, “índice está no intervalo”).
• Precondições e pós‑condições (contratos) para entradas/saídas de funções.
• Invariantes para verdades persistentes (por exemplo, “total do carrinho é soma dos itens”).

Essas técnicas não substituem testes — elas apertam a rede. Transformam expectativas vagas em regras verificáveis, tornando bugs mais difíceis de escrever e mais fáceis de diagnosticar.

Disciplina: como equipes evitam a “dívida da esperteza”

Código “esperto” costuma parecer vitória no momento: menos linhas, um truque bacana, um one‑liner que te faz sentir brilhante. O problema é que esperteza não escala no tempo nem entre pessoas. Seis meses depois, o autor esquece o truque. Um novo colega lê de forma literal, perde a suposição oculta e muda de um jeito que quebra o comportamento. Isso é “dívida de esperteza”: ganho de velocidade no curto prazo comprado com confusão no longo prazo.

Disciplina é um acelerador de equipe

O ponto de Dijkstra não era “escreva código chato” como preferência de estilo — era que restrições disciplinadas tornam programas mais fáceis de raciocinar. Numa equipe, restrições também reduzem fadiga de decisão. Se todos já conhecem os padrões (como nomear, como estruturar funções, o que significa “pronto”), você para de relitigiar o básico em cada pull request. Esse tempo volta para o trabalho de produto.

Disciplina aparece em práticas rotineiras:

• Revisões de código que valorizam clareza sobre novidade (“Alguém mais consegue mudar isso com segurança?”).
• Padrões compartilhados (formatação, nomes, tratamento de erro) para que a base de código leia com uma única voz.
• Refatoração como manutenção, não missão de resgate — pequenos limpups contínuos.

Como “disciplinado” parece no código

Há hábitos concretos que evitam acumular dívida de esperteza:

• Funções pequenas que fazem uma só tarefa, com entradas e saídas óbvias.
• Nomes claros que explicam intenção (prefira calculate_total() em vez de do_it()).
• Sem estado oculto: minimize globais e efeitos colaterais surpreendentes; passe dependências explicitamente.
• Fluxo de controle direto: evite lógica que dependa de ordenação sutil, valores mágicos ou “funciona se você souber o truque”.

Disciplina não é perfeição — é tornar a próxima mudança previsível.

Modularidade e limites: manter a mudança local

Modularidade não é só “dividir código em arquivos”. É isolar decisões atrás de limites claros, para que o resto do sistema não precise saber (ou se importar) com detalhes internos. Um módulo esconde as partes bagunçadas — estruturas de dados, casos de borda, truques de performance — enquanto expõe uma superfície pequena e estável.

Como módulos reduzem o raio de destruição

Quando chega um pedido de mudança, o resultado ideal é: um módulo muda e todo o resto permanece intocado. Esse é o significado prático de “manter a mudança local”. Limites evitam acoplamento acidental — onde atualizar uma funcionalidade quebra silenciosamente três outras porque compartilhavam suposições.

Um bom limite também facilita o raciocínio. Se você pode enunciar o que um módulo garante, pode raciocinar sobre o programa maior sem reler sua implementação inteira toda vez.

Interfaces como promessas (e como permitem trabalho paralelo)

Uma interface é uma promessa: “Dadas essas entradas, eu produzo essas saídas e mantenho estas regras.” Quando essa promessa é clara, times podem trabalhar em paralelo:

• Uma pessoa implementa o módulo.
• Outra constrói um chamador usando a interface.
• QA projeta testes em torno do comportamento prometido.

Isso não é burocracia — é criar pontos de coordenação seguros numa base de código em crescimento.

Checagens simples de módulo que evitam deriva

Você não precisa de uma grande revisão arquitetural para melhorar modularidade. Experimente checagens leves:

• Entradas/saídas: você consegue listar entradas, saídas e efeitos colaterais do módulo em poucas linhas? Se não, provavelmente faz demais.
• Propriedade: quem é responsável pelo comportamento e pelas mudanças? Módulos sem dono viram depósito de lixo.
• Dependências: depende de “tudo” ou só do que realmente precisa? Menos dependências = menos quebras surpresa.

Limites bem desenhados transformam “mudança” de um evento de sistema inteiro em uma edição localizada.

Por que essas ideias vencem na escala (times, bases de código e tempo)

Quando o software é pequeno, você pode “conseguir guardar tudo na cabeça”. Em escala, isso deixa de ser verdade — e os modos de falha ficam familiares.

Sintomas comuns parecem com:

• Outages que voltam a um caso inesperado
• Releases que desaceleram porque cada mudança parece arriscada
• Integrações frágeis onde uma atualização menor quebra três sistemas a jusante

Estrutura reduz carga cognitiva

A aposta central de Dijkstra era que humanos são o gargalo. Fluxo de controle claro, unidades pequenas e bem definidas e código que você pode raciocinar não são escolhas estéticas — são multiplicadores de capacidade.

Numa base grande, estrutura age como compressão para entendimento. Se funções têm entradas/saídas explícitas, módulos têm limites que você pode nomear, e o “caminho feliz” não está emaranhado com todo caso de borda, desenvolvedores gastam menos tempo reconstruindo intenção e mais tempo fazendo mudanças deliberadas.

Escala com times, não só com código

À medida que times crescem, custos de comunicação sobem mais rápido que contagens de linhas. Código disciplinado e legível reduz a quantidade de conhecimento tribal necessário para contribuir com segurança.

Isso aparece imediatamente na integração: novos engenheiros seguem padrões previsíveis, aprendem um pequeno conjunto de convenções e fazem mudanças sem precisar de um longo tour dos “pegadinhas”. O próprio código ensina o sistema.

Incidentes ficam mais simples de depurar — e mais seguros de desfazer

Durante um incidente, o tempo é escasso e a confiança é frágil. Código escrito com suposições explícitas (precondições), checagens significativas e fluxo de controle direto é mais fácil de traçar sob pressão.

Igualmente importante, mudanças disciplinadas são mais fáceis de reverter. Edições menores e localizadas com limites claros reduzem a chance de um rollback gerar novas falhas. O resultado não é perfeição — são menos surpresas, recuperação mais rápida e um sistema que permanece manutenível conforme anos e contribuidores se acumulam.

Aplicando Dijkstra sem ser dogmático

O ponto de Dijkstra não era “escreva código do jeito antigo”. Era “escreva código que você pode explicar.” Você pode adotar essa mentalidade sem transformar cada feature em um exercício de prova formal.

Transforme princípios em hábitos diários

Comece com escolhas que tornam o raciocínio barato:

• Prefira fluxo de controle simples: algumas funções pequenas em vez de uma rotina multi‑ramo “faz tudo”.
• Reduza efeitos colaterais: mantenha mutação próxima de onde é necessária e não deixe funções mudarem estado global silenciosamente.
• Use contratos claros: torne entradas, saídas e comportamento de erro explícitos (em tipos, nomes e comentários).

Uma heurística útil: se você não consegue resumir em uma frase o que uma função garante, provavelmente ela faz demais.

Pequenos “upgrades de estrutura” (sem rewrites)

Você não precisa de um grande sprint de refatoração. Adicione estrutura nas emendas:

• Extraia um loop complexo para uma função nomeada e defina o que permanece verdadeiro a cada iteração.
• Substitua condicionais “mágicos” por predicados bem nomeados (por exemplo, isEligibleForRefund).
• Encapsule uma transição de estado complicada atrás de uma função para que o resto da base não a use indevidamente.

Esses upgrades são incrementais: reduzem a carga cognitiva para a próxima mudança.

Prompts de revisão que mantêm a honestidade

Ao revisar (ou escrever) uma mudança, pergunte:

• “O que deve ser verdadeiro aqui?” (invariantes, suposições, estado requerido)
• “O que pode mudar com segurança?” (quais partes podem variar sem quebrar os chamadores)

Se os revisores não conseguem responder rápido, o código está sinalizando dependências ocultas.

Documente o raciocínio, não só os passos

Comentários que recontam o código ficam obsoletos. Em vez disso, escreva por que o código está correto: suposições chave, casos de borda que você está protegendo e o que quebraria se essas suposições mudassem. Uma nota curta como “Invariante: total sempre é a soma dos itens processados” pode valer mais que um parágrafo de narração.

Se quiser um lugar leve para capturar esses hábitos, reúna‑os numa checklist compartilhada (veja /blog/practical-checklist-for-disciplined-code).

Onde a construção assistida por IA se encaixa (sem perder a disciplina)

Times modernos usam IA para acelerar entrega. O risco é conhecido: velocidade hoje pode virar confusão amanhã se o código gerado for difícil de explicar.

Uma maneira alinhada com Dijkstra de usar IA é tratá‑la como aceleradora do pensamento estruturado, não substituta. Por exemplo, ao construir no Koder.ai — uma plataforma vibe‑coding onde você cria apps web, backend e mobile via chat — você pode manter hábitos de “raciocínio primeiro” tornando prompts e etapas de revisão explícitos:

• Peça contratos claros: “Defina precondições, pós‑condições e comportamento de erro para este endpoint.”
• Peça invariantes em fluxos com estado: “O que sempre deve ser verdade após cada passo desta máquina de estados do checkout?”
• Use o modo planejamento para forçar decomposição em peças pequenas e revisáveis (módulos, interfaces, responsabilidades) antes de gerar implementação.
• Apoie‑se em snapshots e rollback para manter mudanças pequenas e reversíveis — espelhando a disciplina de edições localizadas e caminhos seguros de desfazer.

Mesmo que você exporte o código gerado e o execute em outro lugar, o mesmo princípio vale: código gerado deve ser código que você consegue explicar.

Uma checklist prática para código correto, simples e disciplinado

Esta é uma checklist leve “amiga de Dijkstra” para usar em revisões, refatores ou antes de mesclar. Não se trata de escrever provas o dia todo — é tornar correção e clareza o padrão.

Auto‑checagem rápida (código novo e refatores)

• Consigo explicar o código a um colega em 60 segundos? Se a explicação exige muito “confie em mim”, simplifique.
• O fluxo de controle é óbvio? Prefira código em linha reta; mantenha loops e condicionais pequenos; evite saídas ocultas e ramos profundamente aninhados.
• Quais são as precondições e pós‑condições? Anote‑as num comentário, docstring ou nome da função. Se não consegue declará‑las, a função provavelmente faz demais.
• Cada função tem um trabalho e um limite claro? Entradas entram, saídas saem — mínima dependência de estado global.
• Qual invariante mantém este loop honesto? Mesmo uma nota de uma linha como “total sempre é soma dos itens processados” previne bugs sutis.
• Há menos truques “espertos” do que o necessário? Se o código precisa de guia turístico, está acumulando dívida de esperteza.

O que medir qualitativamente

• Facilidade de explicação: alguém não familiar com o módulo consegue dizer o que ele faz e por que está correto?
• Facilidade de teste: casos de borda são naturalmente testáveis ou exigem montagem elaborada e mocks?
• Risco de mudança: quando requisitos mudam, você consegue prever o que quebra? Se cada alteração assusta, os limites estão vazando.

Um passo prático

Escolha um módulo bagunçado e estruture o fluxo de controle primeiro:

1. Extraia funções pequenas com nomes claros.
2. Substitua ramos emaranhados por casos explícitos e mais simples.
3. Mova casos especiais para as bordas (validação de entrada, retornos antecipados).

Depois, adicione alguns testes focados ao redor dos novos limites. Se quiser mais padrões assim, navegue por posts relacionados em /blog.