Perché "Game of Life" di Conway viene utilizzato per i ritiri di codice?

Code Retreat è un evento di formazione che dura tutto il giorno e si concentra sui fondamenti dello sviluppo del software. Sta arrivando un giorno di ritiro del codice "globale" e non vedo l'ora. Detto questo, ci sono già stato e devo dire che c'era un enorme caos ... il che va bene.

Una cosa che ancora non capisco è il motivo per cui il "Game of Life" è un buon problema per TDD, e come si sente bene e male TDD.

Renditi conto che questa è una domanda piuttosto aperta, quindi sentiti libero di commentare.

Inizialmente, Conway's Game of Life è stato scelto perché avevamo un'applet Java a disposizione per lavorare al primo vero programma di programmazione nel gennaio 2009. L'obiettivo della giornata era sperimentare alcune idee sulla pratica a tempo, e abbiamo appena scelto l'applet GoL perché ce l'avevamo.

Dopo ciò, però, un paio di facilitatori attivi (in particolare io durante il mio tour di giornalista nel 2009 e Alex Bolboaca a Bucarest) hanno studiato gli usi di GoL come strumento di apprendimento. Allo stesso tempo, stavamo evolvendo il formato di coderetreat a quello che è diventato oggi. Nel 2009, Alex ha provato almeno un altro problema (punteggio della mano di poker), ma non lo ha trovato utile come GoL. Puoi trovare ulteriori informazioni sulla storia su http://coderetreat.org/history

Coderetreat si concentra sul miglioramento della nostra comprensione del design semplice (in particolare le 4 regole del design semplice), dello sviluppo guidato dai test e di 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 pratichiamo in coderetreat. Ad esempio, un'implementazione comune che accetta parametri (x, y) in più metodi è un'ottima opportunità per parlare del principio DRY (ogni pezzo di conoscenza dovrebbe avere una e una sola rappresentazione nel tuo 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.

Ci sono un bel po 'di persone ora che hanno fatto più coderetreats e trovano ancora aspetti interessanti del problema da usare come pratica.

Il gioco della vita di Conway sarebbe perfetto perché è un set di codifica abbastanza semplice che ha risultati profondamente potenti. Per quanto riguarda l'utilizzo per guidare lo sviluppo guidato dai test, scommetterei perché i test sarebbero abbastanza difficili da scrivere perché i risultati che stai cercando non sono evidenti dal codice che stai scrivendo. Scrivere un codice che ti dia un aliante è un bel trucco se non l'hai mai fatto prima o non lo fai da molto tempo. Quindi è adatto a estendere l'arte della disciplina, in particolare quando eseguito nella programmazione di coppia come di solito è TDD.

Per quanto riguarda insegnarti cose utili; è un esercizio in una sorta di pensiero laterale. Devi concettualizzare come funzionerà il tuo codice, eseguirlo, vederlo fallire, raccogliere dati, refactor e continuare a iterare. Tutte queste cose sono cruciali per TDD. Collegandolo al mondo reale, è simile a un cliente che ti consegna un documento di requisiti vaghi che dice semplicemente "Voglio X". Quindi dai loro X ma arrivare a X potrebbe essere difficile. Conway's Game of Life è bravo a insegnarlo. È anche abbastanza facile da programmare e in genere non ci vogliono tonnellate di codice per farlo. (L' APL è uno degli esempi più estremi di implementazione.) Quindi è abbastanza adatto per le brevi sessioni che un ritiro avrebbe invece di una o due settimane di iterazione come si potrebbe 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 del numero infinito di celle da elaborare.

Se le specifiche della sfida includono prestazioni minime e il minimo ingombro di memoria , i test includono modelli in rapida crescita o modelli 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 ... tranne 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 un array di bit 2D a doppio buffer di dimensioni fisse diventa totalmente inadeguato quando le sue prestazioni diminuiscono con O (n ^ 2) delle dimensioni. Trattare i blocchi riempiti come nuovi oggetti generati improvvisamente consuma tonnellate di memoria e rallenta. Separare tutto in schede di dimensioni limitate a volte funziona, a volte fallisce ...

E poiché la maggior parte dei test "globali" fallirà lo standard prestazionale, è necessario sviluppare obiettivi più piccoli, sotto-test più piccoli che risolvono gli avvertimenti ...

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

Una sola giornata non è sufficiente per coprire tutti gli aspetti dell'ingegneria del software indipendentemente dall'approccio / paradigma di gestione del progetto che scegli. Quindi per renderlo efficace dovresti probabilmente 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 direttamente alla codifica di una soluzione.

A questo proposito, Game of Life è un buon candidato perché è semplice, ben compreso e non ha molte aree grigie nei suoi requisiti che saranno aperti al dibattito. In questo modo puoi iniziare subito a scrivere il tuo test e codificare contro di loro.

Se d'altra parte l'obiettivo fosse vedere come possiamo usare il TDD per perfezionarmi sui requisiti, allora avrei potuto scegliere il gioco della vita ma non avrei detto agli sviluppatori che questo è quello che voglio. Invece avrei cercato in giro di fornire suggerimenti e idee senza effettivamente menzionarlo per nome. Detto questo, il gioco della vita potrebbe rivelarsi un po 'troppo semplice per questo tipo di esercizio, poiché i partecipanti molto probabilmente vedrebbero lo stratagemma abbastanza rapidamente.

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