Pianificare prima di costruire
Scomporre un progetto reale in parti prima di scrivere una sola riga di codice
⏱ Stima ~7 min
01 · Leggi
Il più grande errore dei principianti con un nuovo progetto: aprono il terminale e iniziano subito a scrivere codice.
I professionisti fanno il contrario. Prima pianificano — anche se il piano è grezzo e cambierà. Pianificare significa pensare a cosa stai costruendo prima di chiedere a Claude di costruirlo.
Con l'AI questo è ancora più importante. Un piano chiaro produce output di Claude Code nettamente migliori. "Costruiscimi un gioco" ti dà qualcosa di generico. "Costruisci un server che gestisce le stanze di gioco, abbina i giocatori in attesa e valida le mosse" ti dà esattamente quello che vuoi.
Punti chiave
- Pianifica prima di scrivere codice — anche un piano grezzo aiuta
- Un piano chiaro produce codice generato dall'AI di qualità superiore
- Dividi il progetto in livelli: server, client, comunicazione
- Costruirai un gioco di tic-tac-toe multiplayer in tempo reale con matchmaking online
02 · Leggi
Ecco cosa costruiremo: un gioco di tic-tac-toe multiplayer in tempo reale. Due sconosciuti visitano lo stesso URL, vengono abbinati e giocano in tempo reale. Quando un giocatore fa una mossa, appare immediatamente sullo schermo dell'altro.
Il gioco completo ha tre livelli: Server — l'autorità. Gestisce il tabellone, applica le regole, abbina i giocatori, rileva le vittorie. Il server ha sempre ragione. I giocatori non possono barare perché il server valida ogni mossa.
Client — l'interfaccia. La pagina HTML che i giocatori vedono nel browser. Mostra il tabellone, cattura i clic, visualizza gli aggiornamenti dal server.
Communication — il ponte. Gli eventi WebSocket che scorrono tra client e server. Quando un giocatore clicca su una cella, il client invia l'evento 'make-move'. Quando il server lo valida, invia 'move-made' a entrambi i giocatori.
Punti chiave
- Il server gestisce tutto lo stato del gioco — non fidarti mai del client
- Il client mostra l'UI e cattura le azioni dell'utente
- Gli eventi WebSocket sono il livello di comunicazione tra loro
- Il server valida ogni mossa — protezione anti-cheat
03 · Passo dopo passo
Vediamo i tre livelli di qualsiasi app in tempo reale e cosa fa ciascuno nel nostro gioco di tic-tac-toe.
1. Server: l'arbitro
Gestisce il tabellone (griglia 3x3), tiene traccia di chi è il turno, valida le mosse (la cella è libera? È il tuo turno?), rileva vittorie e pareggi, abbina i giocatori in attesa nelle stanze di gioco.
2. Client: lo schermo
Mostra il tabellone 3x3 come celle cliccabili. Mostra messaggi di stato ('Aspettando l'avversario...', 'Tocca a te', 'Hai vinto!'). Invia eventi quando il giocatore clicca. Aggiorna il tabellone quando arrivano modifiche dal server.
3. Communication: gli eventi
Il contratto tra client e server. Il giocatore clicca 'Find Game' — il client emette 'find-game'. Il server abbina due giocatori — emette 'game-start' a entrambi. Il giocatore clicca su una cella — il client emette 'make-move'. Il server valida — emette 'move-made' a entrambi. La partita finisce — il server emette 'game-over'.
4. Matchmaking: la lobby
Una coda di attesa sul server. Clicchi 'Find Game' e entri in coda. Quando arriva un secondo giocatore, il server vi abbina in una stanza, assegna X e O casualmente e avvia la partita.
5. Gestione delle disconnessioni: pulizia elegante
Se un giocatore chiude il browser durante la partita, il server rileva la disconnessione e avvisa l'avversario. Se si disconnette mentre è in coda, il server lo rimuove. Niente partite zombie, niente giocatori bloccati.
04 · Esempio di codice
Questo è il flusso di eventi tra i due giocatori e il server. Studialo bene — è il progetto che implementeremo nelle prossime 7 lezioni.
Flusso di eventi: dal matchmaking alla fine della partita
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) |
Nota che ogni azione passa attraverso il server. Il giocatore A non parla mai direttamente con il giocatore B. Il server riceve la mossa, la valida e trasmette il risultato a entrambi i giocatori. Questa è l'architettura standard di qualsiasi gioco multiplayer.
05 · Lista di controllo
Verifica di capire il piano prima di scrivere codice. Spunta ogni concetto quando ti senti sicuro.
- Il server contiene tutto lo stato del gioco — tabellone, di chi è il turno, chi è X e chi è O
- Il client si limita a inviare eventi (come 'make-move') e mostrare ciò che il server gli dice
- Il matchmaking abbina due giocatori in attesa in una stanza di gioco
- Ogni mossa viene validata dal server prima di essere mostrata ai giocatori
- Se un giocatore si disconnette, il server fa pulizia e avvisa l'avversario
06 · Quiz
Perché il server dovrebbe validare le mosse invece di fidarsi del client?
- La validazione lato server è più veloce di quella lato client
- Il client non ha accesso allo stato del gioco
- I giocatori possono modificare il codice client per barare — il server è l'unica autorità di cui ci si può fidare
- WebSocket richiede la validazione lato server
Altre lezioni di questo capitolo
⚠ L'esperienza interattiva completa richiede JavaScript. Attivalo e ricarica la pagina.
※ Questo è un progetto educativo indipendente — non è un prodotto ufficiale di Anthropic. Claude™ è un marchio di Anthropic, PBC.