Planeje antes de construir

Quebre um projeto real em partes antes de escrever uma linha de código

⏱ Estim. ~7 min

01 · Ler

O maior erro de iniciantes começando um projeto novo: abrem o terminal e já saem escrevendo código.

Profissionais fazem o contrário. Eles planejam primeiro — mesmo que o plano seja rascunho e mude depois. Planejar significa pensar no que você está construindo antes de pedir ao Claude para construir.

Isso vale ainda mais ao trabalhar com IA. Um plano claro gera um output muito melhor do Claude Code. "Constrói um jogo para mim" devolve algo genérico. "Constrói um servidor que gerencia salas de jogo, faz matchmaking de jogadores em espera e valida jogadas" devolve exatamente o que você queria.

Pontos-chave

Planeje antes de codar — mesmo um plano rascunho ajuda
Um plano claro gera código melhor gerado pela IA
Divida o projeto em camadas: servidor, cliente, comunicação
Você vai construir um jogo da velha multiplayer em tempo real com matchmaking online

02 · Ler

Veja o que vamos construir: um jogo da velha multiplayer em tempo real. Dois desconhecidos abrem a mesma URL, são pareados e jogam em tempo real. Quando um jogador faz uma jogada, ela aparece na hora na tela do outro.

O jogo final tem três camadas: Servidor — a autoridade. Gerencia o tabuleiro, aplica as regras, faz o matchmaking dos jogadores e detecta vitórias. O servidor está sempre certo. Os jogadores não conseguem trapacear porque o servidor valida cada jogada.

Cliente — a interface. A página HTML que os jogadores veem no navegador. Mostra o tabuleiro, captura os cliques e exibe as atualizações do servidor.

Comunicação — a ponte. Os eventos WebSocket que fluem entre cliente e servidor. Quando um jogador clica numa célula, o cliente envia o evento 'make-move'. Quando o servidor valida, envia 'move-made' para os dois jogadores.

Pontos-chave

O servidor é dono de todo o estado do jogo — nunca confie no cliente
O cliente mostra a UI e captura as ações do usuário
Eventos WebSocket são a camada de comunicação entre os dois
O servidor valida cada jogada — protege contra trapaça

03 · Passo a passo

Passe pelas três camadas de qualquer app em tempo real e veja o que cada uma faz no nosso jogo da velha.

1. Servidor: o árbitro

Cuida do tabuleiro (grade 3x3), acompanha de quem é a vez, valida jogadas (a célula está vazia? é a sua vez?), detecta vitórias e empates e pareia jogadores em espera dentro de salas de jogo.

2. Cliente: a tela

Mostra o tabuleiro 3x3 como células clicáveis. Exibe mensagens de status ('Esperando oponente...', 'Sua vez', 'Você venceu!'). Envia eventos quando o jogador clica. Atualiza o tabuleiro quando o servidor envia mudanças.

3. Comunicação: os eventos

O contrato entre cliente e servidor. O jogador clica em 'Find Game' — o cliente emite 'find-game'. O servidor pareia dois jogadores — emite 'game-start' para ambos. O jogador clica numa célula — o cliente emite 'make-move'. O servidor valida — emite 'move-made' para os dois. O jogo termina — o servidor emite 'game-over'.

4. Matchmaking: o lobby

Uma fila de espera no servidor. Você clica em 'Find Game' e entra na fila. Quando um segundo jogador entra, o servidor coloca os dois numa sala, sorteia X e O e começa o jogo.

5. Tratamento de desconexão: limpeza elegante

Se o jogador fecha o navegador no meio do jogo, o servidor detecta a desconexão e notifica o oponente. Se desconecta na fila, o servidor remove o jogador. Sem jogos-zumbis, sem jogadores travados.

04 · Exemplo de código

Aqui está o fluxo de eventos entre os dois jogadores e o servidor. Estude com calma — esse é o blueprint que vamos implementar nas próximas 7 lições.

Fluxo de eventos: do matchmaking ao fim do jogo

Player A            Server              Player B
   |                   |                    |
   |--- find-game ---->|                    |
   |<--- waiting ------|                    |
   |                   |<--- find-game -----|  
   |<-- game-start ----|--- game-start ---->|
   |    (you are X)    |    (you are O)     |
   |                   |                    |
   |--- make-move ---->|                    |  (A clicks cell 4)
   |<-- move-made -----|--- move-made ----->|  (server: valid!)
   |                   |                    |
   |                   |<--- make-move -----|  (B clicks cell 0)
   |<-- move-made -----|--- move-made ----->|  (server: valid!)
   |                   |                    |
   |       ...more moves...                 |
   |                   |                    |
   |<-- game-over -----|--- game-over ----->|  (X wins!)
   |    (you won!)     |    (you lost)      |

Repare que toda ação passa pelo servidor. O jogador A nunca fala direto com o jogador B. O servidor recebe a jogada, valida e transmite o resultado aos dois. Essa é a arquitetura padrão de qualquer jogo multiplayer.

05 · Lista de verificação

Antes de codar, confirme que você entendeu o plano. Marque cada conceito quando estiver confortável com ele.

O servidor é dono de todo o estado do jogo — tabuleiro, de quem é a vez, quem é X e quem é O
O cliente só envia eventos (como 'make-move') e mostra o que o servidor manda
O matchmaking junta dois jogadores em espera numa sala de jogo
Cada jogada é validada pelo servidor antes de ser mostrada aos jogadores
Se um jogador desconecta, o servidor faz a limpeza e avisa o oponente

06 · Quiz

Por que o servidor deve validar as jogadas em vez de confiar no cliente?

Validação no servidor é mais rápida do que no cliente
O cliente não tem acesso ao estado do jogo
Jogadores podem editar o código do cliente para trapacear — o servidor é a única autoridade confiável
WebSocket exige validação no lado do servidor

Outras lições deste capítulo

⚠ A experiência interativa completa precisa de JavaScript. Ative-o e recarregue a página.

※ Este é um projeto educacional independente — não é um produto oficial da Anthropic. Claude™ é uma marca registrada da Anthropic, PBC.