Perché il "gioco della vita" di Conway è utilizzato per i ritiri del codice?

Originariamente, il Game of Life di Conway è stato scelto perché avevamo a disposizione un applet Java per lavorare al primissimo editor di codice nel gennaio del 2009. L'obiettivo della giornata era di sperimentare alcune idee sulla pratica del time boxing, e abbiamo appena scelto l'applet GoL perché ce l'avevamo.

Dopodiché, però, un paio di facilitatori attivi (in particolare me durante il mio tour in tournée nel 2009 e Alex Bolboaca a Bucarest) hanno studiato gli usi del GoL come strumento di apprendimento. Allo stesso tempo stavamo evolvendo il formato di coderetreat in quello che è diventato oggi. Nel 2009, Alex ha provato almeno un altro problema (punteggio di mano di poker), ma non l'ha trovato utile come GoL. Puoi trovare ulteriori informazioni sulla storia al link

Coderetreat punta a migliorare la nostra comprensione del design semplice (in particolare le 4 regole del design semplice), lo sviluppo basato sui test e altri aspetti fondamentali dello sviluppo del software. GoL ha il vantaggio di essere un problema molto semplice da capire pur essendo molto ricco da una prospettiva strutturale. Fornisce prontamente parti del sistema che possono essere utilizzate come esempi di tutti gli argomenti che esercitiamo su coderetreat. Ad esempio, un'implementazione comune che richiede parametri (x, y) in più metodi è una grande opportunità per parlare del principio DRY (ogni conoscenza dovrebbe avere una e una sola rappresentazione nel proprio sistema) per quanto riguarda la topologia del sistema. Ci sono molti altri aspetti che possono essere usati come esempi di costruzione di un progetto che minimizza il costo del cambiamento.

Ora ci sono parecchie persone che hanno fatto più codificatori, e trovano ancora aspetti interessanti del problema da usare come pratica.

Conway's Game of Life sarebbe una buona idea perché è un set di codifica abbastanza semplice che ha risultati profondamente potenti. Per quanto riguarda l'utilizzo di Drive Test Driven Development, lo scommetterei perché i test sarebbero abbastanza difficili da scrivere perché i risultati che stai cercando non sono ovvi dal codice che stai scrivendo. Scrivere un codice che ti fa diventare un aliante è abbastanza difficile se non lo hai fatto prima o non lo hai fatto da molto tempo. Quindi è adatto per estendere l'arte della disciplina, in particolare quando viene eseguito nella programmazione di coppie come lo è solitamente TDD.

Per quanto riguarda l'insegnamento di cose utili; è un esercizio in una sorta di pensiero laterale. Devi concettualizzare come funzionerà il tuo codice, eseguirlo, vederlo fallire, raccogliere dati, refactoring e continuare l'iterazione. Tutte queste cose sono fondamentali per TDD. Collegandolo al mondo reale, è come un cliente che ti consegna un vago documento dei requisiti che dice semplicemente "Voglio X". Quindi dai loro X ma arrivare a X potrebbe essere complicato. Conway's Game of Life è bravo a insegnarlo. È anche abbastanza facile da codificare e in genere non richiede tonnellate di codice per farlo. ( APL è uno degli esempi più estremi di implementazione.) Quindi è abbastanza adatto per le sessioni brevi in cui un ritiro avere piuttosto che una settimana o due settimane di iterazione come in genere si può trovare in un ambiente di produzione.

Game of Life è in una mano un insieme di regole molto semplice, dall'altra contiene alcuni dei peggiori avvertimenti della programmazione avanzata, relativi alla scalabilità . Mentre i risultati sono deterministici, c'è la sfida del campo di gioco infinito e il numero infinito di celle da elaborare.

Se le specifiche della sfida includono prestazione minima e impronta di memoria massima , i test includono modelli a crescita rapida, o pattern che viaggiano in varie direzioni in lungo e in largo, questo può diventare una sfida molto frustrante.

Hai ottenuto l'input noto e l'output noto dopo X iterazioni e conosci tutti i passaggi per arrivarci ... eccetto che i passaggi richiedono troppo e troppo tempo. È necessario eseguire alcune ottimizzazioni piuttosto estreme per adattarsi alle specifiche. L'algoritmo banale con la scansione di una matrice di bit a doppio buffer a dimensione fissa diventa totalmente inadeguato in quanto le sue prestazioni diminuiscono con O (n ^ 2) della dimensione. Trattare blocchi riempiti come nuovi oggetti generati improvvisamente mangia tonnellate di memoria e diventa lento. Separare tutto in schede di dimensioni limitate funziona a volte, a volte non riesce ...

Dal momento che la maggior parte dei test "globali" falliscono nello standard di prestazioni, è necessario sviluppare obiettivi più piccoli, test secondari più piccoli che risolvono i caveat ...

Tutto dipende da quale aspetto del tuo processo vuoi esercitare / allenare.

Un solo giorno non è sufficiente per coprire tutti gli aspetti dell'ingegneria del software indipendentemente dal paradigma approccio / gestione del progetto che si sceglie. Quindi per renderlo efficace probabilmente dovresti concentrarti su un piccolo sottoinsieme del tutto.

Se ti concentri sugli aspetti tecnici di TDD, ad esempio, potresti voler lasciare andare le grandi aree grigie intorno ai requisiti e alle relazioni con il cliente e tagliare dritti alla codifica di una soluzione.

In questo senso, il Game of Life è un buon candidato perché è semplice, ben compreso e non ha molte aree grigie nel suo requisito che sarà aperto al dibattito. In questo modo puoi iniziare subito a scrivere il tuo test e codificali contro di loro.

Se d'altra parte l'obiettivo era vedere come possiamo usare TDD per affinare i requisiti, potrei aver scelto il gioco della vita ma non avrei detto agli sviluppatori che questo è quello che voglio. Invece avrei cerchiato intorno fornendo suggerimenti e idee senza in realtà menzionarlo per nome. Detto questo, il gioco della vita potrebbe dimostrarsi un po 'troppo semplice per questo tipo di esercizio, visto che i partecipanti probabilmente vedrebbero il trucco abbastanza rapidamente.

Gli esempi non sono sempre facili da trovare per questo esercizio sintetico. deve essere semplice da fare in un giorno, ma non troppo semplice per superare la giornata. Deve essere divertente ma non insignificante ... Ma per me deve essere un po 'originale, non ricordo quante volte mi è stato chiesto di portare gli studenti a creare un sistema di gestione videoclub per i compiti .... iiirch.