Esse método serve só para programação?

Não. Entender, planejar, executar e revisar serve para consertar uma torneira, planejar uma viagem ou organizar um evento. Ele nasceu na matemática, virou padrão na computação e funciona em qualquer problema que tenha um objetivo claro. Programar só deixa o método mais visível.

Não perco tempo planejando em vez de já ir codando?

Parece que sim, mas é o contrário. O tempo gasto planejando é devolvido com juros na execução, que flui sem travadas, e na revisão, que encontra menos bugs. Quem pula o planejamento costuma reescrever tudo do zero uma ou duas vezes, o que é bem mais lento.

Como sei que entendi o problema de verdade?

Um bom teste é conseguir explicar o problema com suas palavras e dar exemplos de entrada com a saída esperada. Se você consegue dizer o que entra, o que sai e a regra que liga os dois, entendeu. Se ainda está vago, faltam perguntas a fazer antes de planejar.

O que é um caso de borda ou caso extremo?

É a entrada que fica nas pontas do que o programa aceita: a lista vazia, o único item, o valor máximo, o negativo, o texto em branco. Bugs adoram se esconder nesses extremos porque o programador testou só o caso comum. Revisar é caçar esses casos de propósito.

Se a revisão reprovar, começo tudo de novo?

Nem sempre do zero. Às vezes o conserto é uma linha. Mas a seta que volta de revisar para entender existe porque, quando um teste falha, muitas vezes é sinal de que faltou entender um detalhe. Voltar com essa informação nova costuma render um plano melhor.

Preciso seguir os quatro passos sempre, até em problemas fáceis?

Em problemas triviais, os passos acontecem quase juntos, na sua cabeça, em segundos. O valor do método aparece nos problemas médios e grandes, quando a tentação de sair codando no susto é maior e o custo de errar o entendimento é alto. Com prática, o método vira hábito automático.

Módulo 1 - Bem-vindo ao próximo degrau

Pensar como quem resolve problemas: o método dos quatro passos

8 min de leitura · por Cesar Gargiulo, revisado pela equipe ValorFinal e GuardiaSec · Atualizado em 08/07/2026

O que você vai aprender

Conhecer os quatro passos: entender, planejar, executar e revisar.
Perceber por que pular o entendimento é a maior fonte de retrabalho.
Aplicar o método a um problema pequeno, do enunciado ao teste.
Colocar os quatro passos na ordem certa num algoritmo de resolução.

Pensar antes de digitar

Quem está aprendendo tem um impulso natural: ler o enunciado pela metade e já sair escrevendo, na esperança de que a solução apareça no caminho. Às vezes aparece, na maioria das vezes o programa trava numa encruzilhada e a pessoa apaga tudo e recomeça, três, quatro vezes. Programador experiente faz o oposto do que parece produtivo: passa um bom tempo sem escrever nada, só pensando, e depois escreve quase de um fôlego só. O segredo não é digitar rápido, é ter um método para pensar. O mais famoso deles nasceu na matemática, com um professor húngaro chamado George Pólya, e se resume a quatro passos que servem para qualquer problema.

Um ciclo com quatro estações ligadas por setas em círculo: entender, planejar, executar e revisar. Uma seta pontilhada volta de revisar para entender, indicando que, se o teste falhar, o ciclo recomeça com mais informação. — Os quatro passos formam um ciclo: se a revisão reprova, você volta com mais entendimento.

Os quatro passos, aplicados a um problema

Vamos ver o método trabalhar num problema pequeno: dada a lista de notas de um aluno, dizer se ele foi aprovado, sabendo que a média precisa ser pelo menos 6. Parece simples, e é, mas repare como cada passo evita um tropeço. ENTENDER: a entrada é uma lista de notas, a saída é uma frase (aprovado ou reprovado), e a regra é média maior ou igual a 6. Já surge uma pergunta que salva o programa: e se a lista de notas estiver vazia? Melhor decidir agora do que descobrir na hora do erro.

Entender: entrada é a lista de notas; saída é aprovado ou reprovado; regra é média maior ou igual a 6.
Planejar: somar todas as notas, dividir pela quantidade para achar a média, comparar com 6 e decidir a frase.
Executar: traduzir o plano em pseudocódigo, com um acumulador para a soma e um contador para a quantidade.
Revisar: testar com notas [7, 8] (aprovado), [4, 5] (reprovado) e a lista vazia (evitar dividir por zero).

notas <- [7, 5, 9]
soma <- 0
quantidade <- 0
para cada n em notas faça
  soma <- soma + n
  quantidade <- quantidade + 1
fim
se quantidade = 0 então
  escreva("Sem notas para avaliar")
senão
  media <- soma / quantidade
  se media >= 6 então
    escreva("Aprovado")
  senão
    escreva("Reprovado")
  fim
fim

O plano virou pseudocódigo. Repare no cuidado com a lista vazia, decidido lá no passo de entender.

🎮 Jogo da aula

Monte o método de resolver um problema

Os quatro passos de quem resolve um problema apareceram fora de ordem. Toque na sequência certa, do primeiro ao último.

Revisar é onde mora a qualidade

O passo que iniciante mais abandona é o último. O programa rodou uma vez com um exemplo bonitinho, deu certo, e a pessoa considera o trabalho encerrado. Só que o exemplo bonitinho é o caso fácil. A qualidade de um programa se mede nos casos difíceis: a lista vazia, o número negativo que ninguém esperava, o texto com acento, o valor gigante. Revisar é justamente inventar esses casos de propósito e ver se o programa aguenta. Um programador que testa os extremos entrega software em que dá para confiar; um que testa só o caminho feliz entrega surpresas.

Teste rápido

Por que ENTENDER é considerado o passo mais importante do método, apesar de não escrever uma linha de código?

Perguntas frequentes

Esse método serve só para programação?: Não. Entender, planejar, executar e revisar serve para consertar uma torneira, planejar uma viagem ou organizar um evento. Ele nasceu na matemática, virou padrão na computação e funciona em qualquer problema que tenha um objetivo claro. Programar só deixa o método mais visível.
Não perco tempo planejando em vez de já ir codando?: Parece que sim, mas é o contrário. O tempo gasto planejando é devolvido com juros na execução, que flui sem travadas, e na revisão, que encontra menos bugs. Quem pula o planejamento costuma reescrever tudo do zero uma ou duas vezes, o que é bem mais lento.
Como sei que entendi o problema de verdade?: Um bom teste é conseguir explicar o problema com suas palavras e dar exemplos de entrada com a saída esperada. Se você consegue dizer o que entra, o que sai e a regra que liga os dois, entendeu. Se ainda está vago, faltam perguntas a fazer antes de planejar.
O que é um caso de borda ou caso extremo?: É a entrada que fica nas pontas do que o programa aceita: a lista vazia, o único item, o valor máximo, o negativo, o texto em branco. Bugs adoram se esconder nesses extremos porque o programador testou só o caso comum. Revisar é caçar esses casos de propósito.
Se a revisão reprovar, começo tudo de novo?: Nem sempre do zero. Às vezes o conserto é uma linha. Mas a seta que volta de revisar para entender existe porque, quando um teste falha, muitas vezes é sinal de que faltou entender um detalhe. Voltar com essa informação nova costuma render um plano melhor.
Preciso seguir os quatro passos sempre, até em problemas fáceis?: Em problemas triviais, os passos acontecem quase juntos, na sua cabeça, em segundos. O valor do método aparece nos problemas médios e grandes, quando a tentação de sair codando no susto é maior e o custo de errar o entendimento é alto. Com prática, o método vira hábito automático.

Fontes

Seu progresso fica salvo neste aparelho. Assinantes sincronizam entre os aparelhos.

← O que muda agora: de valores soltos a dados organizados Concluir e avançar →