Pourquoi le «Game of Life» de Conway est-il utilisé pour les retraites de code?

Code Retreat est un événement de formation d'une journée qui se concentre sur les principes fondamentaux du développement de logiciels. Il y a une journée de retraite "mondiale" sur les codes, et je l'attends avec impatience. Cela dit, je suis allé à un avant et je dois dire qu'il y avait une énorme quantité de chaos ... ce qui est bien.

Une chose que je ne comprends toujours pas, c'est pourquoi le "Game of Life" est un bon problème pour TDD, et à quoi ressemble le bon et le mauvais TDD.

Sachez que c'est une question assez ouverte, alors n'hésitez pas à commenter.

À l'origine, le jeu de la vie de Conway a été choisi parce que nous avions une applet Java à portée de main lors du tout premier codereteat en janvier 2009. Le but de la journée était d'expérimenter quelques idées autour de la pratique encadrée par le temps, et nous avons simplement choisi l'applet GoL parce que nous l'avons.

Après cela, cependant, en tant que facilitateurs actifs (notamment moi lors de ma tournée de compagnons en 2009 et Alex Bolboaca à Bucarest), nous avons étudié les utilisations de GoL comme outil d'apprentissage. En même temps, nous faisions évoluer le format de coderetreat vers ce qu'il est devenu aujourd'hui. En 2009, Alex a essayé au moins un autre problème (marquer des mains au poker), mais ne l'a pas trouvé aussi utile que GoL. Vous pouvez en savoir plus sur l'histoire à http://coderetreat.org/history

Coderetreat se concentre sur l'amélioration de notre compréhension de la conception simple (en particulier les 4 règles de conception simple), du développement piloté par les tests et d'autres aspects fondamentaux du développement logiciel. Le GoL a l'avantage d'être un problème très simple à comprendre tout en étant très riche d'un point de vue structurel. Il fournit facilement des parties du système qui peuvent être utilisées comme exemples de tous les sujets que nous pratiquons chez coderetreat. Par exemple, une implémentation commune qui prend des paramètres (x, y) dans plusieurs méthodes est une excellente occasion de parler du principe DRY (chaque élément de connaissance doit avoir une et une seule représentation dans votre système) en ce qui concerne la topologie du système. Il existe de nombreux autres aspects qui peuvent être utilisés comme exemples de construction d'une conception qui minimise le coût du changement.

Il y a maintenant pas mal de gens qui ont fait plusieurs traitements de codage, et ils trouvent toujours des aspects intéressants du problème à utiliser comme pratique.

Le jeu de la vie de Conway serait un bon choix car c'est un ensemble de codage assez simple qui a des résultats profondément puissants. Quant à l'utiliser pour piloter le développement piloté par les tests, je parierais parce que les tests seraient assez difficiles à écrire car les résultats que vous recherchez ne sont pas évidents d'après le code que vous écrivez. Écrire du code qui vous procure un planeur est tout à fait l'astuce si vous ne l'avez pas déjà fait ou si vous ne l'avez pas fait depuis longtemps. Ainsi, il est adapté pour étirer l'art de la discipline, en particulier lorsqu'il est exécuté en programmation par paires comme TDD l'est habituellement.

En ce qui vous enseigne des choses utiles; c'est un exercice dans une sorte de pensée latérale. Vous devez conceptualiser le fonctionnement de votre code, l'exécuter, le voir échouer, collecter des données, refactoriser et continuer l'itération. Toutes ces choses sont cruciales pour TDD. En le reliant au monde réel, cela ressemble à un client qui vous remet un vague document d'exigences qui dit simplement "Je veux X". Donc, vous leur donnez X, mais il peut être difficile d'arriver à X. Le jeu de la vie de Conway est bon pour enseigner cela. Il est également assez facile à coder et ne prend généralement pas des tonnes de code pour le faire. ( APL étant l'un des exemples d'implémentation les plus extrêmes.) Il est donc tout à fait adapté aux courtes sessions qu'une retraite aurait plutôt qu'à une ou deux semaines d'itération, comme vous pouvez généralement le trouver dans un environnement de production.

Game of Life est d'une part un ensemble très simple de règles, d'autre part contient certaines des pires mises en garde de la programmation avancée, liées à l' évolutivité . Bien que les résultats soient déterministes, il y a le défi du terrain de jeu infini et du nombre infini de cellules à traiter.

Si les spécifications du défi incluent des performances minimales et une empreinte mémoire maximale , alors les tests incluent des modèles à croissance rapide, ou des modèles qui voyagent dans diverses directions très loin, cela peut devenir un défi très frustrant.

Vous avez obtenu l'entrée et la sortie connues après X itérations, et vous connaissez toutes les étapes pour y arriver ... sauf que les étapes prennent trop et trop de temps. Vous devez effectuer des optimisations assez extrêmes pour correspondre aux spécifications. L'algorithme trivial avec l'analyse d'une matrice de bits 2d à double tampon de taille fixe devient totalement inadéquat car ses performances se dégradent avec O (n ^ 2) de la taille. Traiter les blocs remplis comme de nouveaux objets créés mange soudainement des tonnes de mémoire et devient lent. Tout séparer en tableaux de taille limitée fonctionne parfois, échoue parfois ...

Et comme la plupart des tests "globaux" échoueront à la norme de performance, vous devez développer des objectifs plus petits, des sous-tests plus petits qui éliminent les mises en garde ...

Tout dépend de quel aspect de votre processus vous souhaitez pratiquer / former.

Une seule journée ne suffit pas pour couvrir tous les aspects du génie logiciel, quel que soit le paradigme d'approche / de gestion de projet que vous choisissez. Donc, pour le rendre efficace, vous devriez probablement vous concentrer sur un petit sous-ensemble de l'ensemble.

Si vous vous concentrez sur les aspects techniques du TDD par exemple, vous voudrez peut-être laisser de côté les grandes zones grises autour des exigences et des relations avec le client et passer directement au codage d'une solution.

À cet égard, le jeu de la vie est un bon candidat car il est simple, bien compris et n'a pas beaucoup de zones grises dans son exigence qui sera ouverte au débat. Ainsi, vous pouvez commencer à écrire votre test tout de suite et coder contre eux.

Si d'un autre côté l'objectif était de voir comment nous pouvons utiliser TDD pour affiner les exigences, j'aurais peut-être choisi le jeu de la vie, mais je n'aurais pas dit aux développeurs que c'est ce que je veux. Au lieu de cela, j'aurais tourné autour en fournissant des astuces et des idées sans vraiment les mentionner par leur nom. Cela dit, le jeu de la vie peut s'avérer un peu trop simple pour ce type d'exercice, car les participants verraient très probablement le stratagème assez rapidement.

Les exemples ne sont pas toujours faciles à trouver pour un tel exercice synthétique. il faut que ce soit simple à faire en une journée, mais pas trop simple pour le faire toute la journée. Cela doit être amusant mais pas dénué de sens ... Mais pour moi, cela doit être un peu original, je ne peux pas me rappeler combien de fois on m'a demandé d'amener les élèves à créer un système de gestion de vidéoclub pour les devoirs .... iiirch.