Projet d'un weekend : Go Game Of Life

15/11/2016 | Tags: projet go

Il y a quelques semaines de çà, j’ai assisté à un code retreat day sur Bordeaux avec une quinzaine d’autres développeurs. Le but de la journée était de faire des pairs et pendant 45 min essayer de faire le fameux “Game of Life” avec différentes contraintes. Il était évidement impossible de compléter le jeu en si peu de temps, surtout car il fallait le faire en test first.

J’ai donc décidé de m’attaquer au “Game of Life” sur un weekend et en profiter pour apprendre un nouveau langage: GoLang. Armé de Go In Action, je me suis lancé avec ce cahier des charges :

  1. Le joueur décide du modèle de départ
  2. L’évolution se fait étape par étape afin que le joueur puisse apprécier le résultat

Pour information, il existe déjà un exemple fait par l’équipe de GoLang. Mais il ne répond pas à mon cahier des charges et j’ai donc décidé de tout simplement l’ignorer sans même m’en inspirer.

Après un après-midi de “travail” voilà le résultat :

Affichage des instructions
Préparation, le joueur choisi l'état initial
Evolution : tour numéro 1
Evolution : tour numéro 2
Evolution : tour numéro 3

Je suis plutôt content de moi bien qu’il y ai surement beaucoup à redire sur le code. Notamment sur la séparation entre la logique et la présentation. Le code est disponible sur mon compte GitHub.

Je n’ai pas encore touché à l’asynchrone donc mes remarques sont purement sur le coté synchrone de Go.

Ce que j’ai aimé

Le mot clé defer est plutôt cool. Il permet de déclencher des actions après le retour d’une fonction; comme la fermeture d’une ressource ouverte par exemple. L’intégration avec Visual Studio Code est parfaite. Lint et formatage automatique à chaque enregistrement. Je n’ai pas eu l’occasion de tester le debugger.

Ce que j’ai moins aimé

Lire les flèches du clavier fut laborieux. Les fonctions de bufio ne peuvent que lire des strings suivis de la touche entrée. Pas moyen de lire ces maudites flèches ! Après 30 minutes de recherche, j’ai décidé de partir sur la bibliothèque termbox-go qui permet de le faire grâce à du voodoo interne (plus 1 millions d’autres choses dont je n’avais pas besoin…). Je comprend que ce n’ai pas un cas d’utilisation classique mais enfin…

Je trouve le système de package très confus. Si l’on utilise plusieurs fichiers dans un même dossier (ce que j’ai fait), ils font partie du même package et donc tout est partagé. Ce qui rend le code illisible car dans un fichier on utilise une fonction d’un autre sans aucun préfixe. Il n’y a qu’à regarder le fichier main.go pour voir de quoi je parle:

 package main  
 import "os"  
 func main() {  
   switch showMenu() {  
   case StartGame:  
     showGame()  
   case Quit:  
     os.Exit(0)  
   }  
 }  

C’est le code complet ! Tout le monde se pose la question: d’où viens showMenu(), StartGame, showGame() et Quit ?!

L’utilisation des pointeurs me semble être un retour en arrière. J’ai pas poussé très loin mais s’il est possible d’avoir 2 threads qui utilise le même pointeur, c’est la porte ouverte aux Dangling pointers.