Ataxx
Il gioco da tavolo Ataxx in Java, sviluppato in team con metodo Scrum.
Dentro il progetto
Le scelte, collegate.
Segui ogni ramo dal vincolo all’effetto. Apri una scelta per approfondire il ragionamento e consultare le fonti.
Punto di partenza
Trasformare le regole di Ataxx in un gioco costruito in squadra.
Un’applicazione Java da terminale: mosse, catture e turni devono restare coerenti mentre il team consegna funzionalità in iterazioni.
- Il mio contributo
- Ho riorganizzato il codice in package, implementato l’acquisizione e l’esecuzione delle mosse, inclusi i salti, scritto test per Color e Message ed esteso quelli di GameController. Ho integrato pull request e inserito i diagrammi delle classi nel report.
- Lavoro di squadra
- Modello, controller, interfaccia e documentazione sono stati sviluppati da più membri del team. La struttura iniziale di GameControllerTest è di un collega; i miei commit ne estendono i casi di test.
Vincolo
Comandi testuali e regole del tavoliere hanno responsabilità diverse.
Scelta 01
Separare entità, controllo e interfaccia
Esplora la sceltaChiudi il dettaglioIl mio contributo
Ho separato il codice nei package model, controller, views e utils, sviluppato la lettura delle coordinate delle mosse e implementato movePiece, estendendolo al salto di due caselle.
- Perché questa scelta
- Il pattern Entity-Control-Boundary distingue Game, Field e Move dalle classi di input/output. GameController coordina la validazione della mossa, l’aggiornamento del tavoliere e le catture.
- Il compromesso
- Il controller resta il punto di coordinamento e richiama anche l’output: la separazione organizza il codice, ma non elimina ogni dipendenza dall’interfaccia.
- Nel progetto
- Il report dichiara ECB. Move calcola la distanza; GameController distingue duplicazione e spostamento e controlla le caselle coinvolte.
Esplora le fonti
Effetto
Le regole hanno oggetti e responsabilità riconoscibili, verificabili con test.
Vincolo
Più persone devono integrare modifiche senza perdere il filo del lavoro.
Scelta 02
Consegnare per sprint e revisioni
Esplora la sceltaChiudi il dettaglioIl mio contributo
Ho integrato pull request nel ramo principale, fra cui quella sui test del controller, e inserito e organizzato i diagrammi delle classi nel report. Questi interventi documentano il mio lavoro di integrazione e documentazione nel team.
- Perché questa scelta
- Il team organizza il lavoro in tre sprint, con planning, incontri di avanzamento e una board GitHub. Issue e pull request collegano le attività alle modifiche; le retrospettive rendono visibile il processo.
- Il compromesso
- Coordinamento, review e documentazione richiedono tempo oltre all’implementazione delle regole.
- Nel progetto
- Il report descrive sprint e board. Gli ultimi interventi correggono la fine della partita e la stampa delle mosse vuote, mostrando anche il lavoro di rifinitura.
Esplora le fonti
Effetto
Le funzionalità e le correzioni lasciano una storia condivisa e consultabile.
Vincolo
Un gioco consegnato deve poter essere verificato e avviato altrove.
Scelta 03
Ripetere i controlli e preparare la consegna
Esplora la sceltaChiudi il dettaglioIl mio contributo
Ho scritto i test di Color e Message ed esteso GameControllerTest, verificando anche mosse non valide e conferma dell’abbandono. Ho aggiunto setTestCommand per fornire input controllati durante i test.
- Perché questa scelta
- JUnit 5 verifica le classi; Gradle esegue test e analisi statica e produce un JAR eseguibile. GitHub Actions avvia la build sulle pull request che cambiano src; il Dockerfile prepara l’ambiente di esecuzione.
- Il compromesso
- Checkstyle, PMD e SpotBugs sono configurati con ignoreFailures: i loro rilievi richiedono revisione e non bloccano automaticamente la build.
- Nel progetto
- build.gradle configura JUnit e il fat JAR. Il workflow esegue la build su JDK 19; il Dockerfile avvia il JAR prodotto. Le suite di test sono raccolte in src/test.
Esplora le fonti
Effetto
La consegna comprende codice, verifiche ripetibili e istruzioni di esecuzione.
Dove portano le scelte
Un gioco e un processo di sviluppo leggibile.
Il repository raccoglie applicazione da terminale, test, diagrammi di progettazione e report del lavoro in team. La storia mostra sia la costruzione delle funzionalità sia le correzioni prima della consegna.
Il progetto in pratica
