Code Retreat Toulouse 2011

Le GDCR 2011 (Global Day of Code Retreat) s’est tenu le samedi 3 décembre un peu partout dans le monde. Toulouse a été l’une des trois villes à en organiser en France. J’ai eu la chance de m’y retrouver avec 16 autres personnes pour coder toute la journée (oui, il y en a pour qui ça sonne bizarrement un samedi). Comme stipulé dans la définition même du code retreat, nous avons été accueillis gratuitement et les locaux et le repas au restaurant le midi nous ont été fournis par Docdoku qui sponsorisait l’évènement.

C’est quoi un code retreat ?

Pour ceux qui connaissent, l’événement se rapproche assez d’un coding dojo dans le sens où il permet à des développeurs passionnés de se retrouver pour partager leurs connaissances et confronter leur façon de résoudre les problèmes de développement à celles des autres participants. Il s’agit donc avant tout d’un moment d’échange et de convivialité, animé par la passion du code.

Une séance d’introduction en début de journée permet de présenter le concept et le sujet du jour. Dans notre cas, nous nous sommes basés sur le Jeu de la vie sur lequel nous reviendrons dans le prochain paragraphe. Ce jeu a été le fil rouge des différentes sessions. La particularité du code retreat provient du fait qu’il se compose d’itérations d’une heure (6 dans notre cas), dont 45 minutes de développement par paires, et 15 minutes de retours sur la session. Le langage n’étant pas imposé, les participants étaient incités à venir avec leur propre environnement de développement. La seule contrainte liée au langage est qu’il faut qu’il permette d’effectuer des tests unitaires, les séances étant basées sur du TDD en ping-pong : un développeur code un test, le second prend alors la main pour écrire le code correspondant et le test suivant et on itère autant de fois que nécessaire. Le Toulouse JUG étant partenaire de l’événement, il y avait une majorité d’environnements de développement Java avec JUnit, mais on a quand même pu noter la présence d’un développeur Javascript (oui oui, les tests unitaires existent aussi en JavaScript), Python, Php, .NET. Un animateur imposait des contraintes pour pimenter le tout au début de chaque session et faisait le tour de la salle, regardant comment cela se passait et poussant les participants à se poser des questions sur leur façon de faire, le nommage de leurs variables, méthodes etc…

J’ai volontairement omis la règle qui à mes yeux est la plus importante! A la fin de chaque itération on supprime TOUT le code. Cela peut sembler étrange au premier abord, et on a vraiment mal au cœur de supprimer 45 minutes de travail les premières fois. Mais on comprend vite que c’est la condition sine qua non au bon fonctionnement de cet événement. Il faut vraiment coder sans même chercher à avoir un résultat fonctionnel, et en repartant de zéro, et non pas s’appuyer sur une base commune établie.

Le jeu de la vie

Le jeu de la vie est un jeu à 0 joueur, qui est basé sur 4 règles simples :

• Une cellule vivante meurt de solitude si elle n’a pas au moins 2 cellules vivantes voisines.
• Une cellule vivante meurt de surpopulation si elle a plus de 3 cellules vivantes voisines.
• Une cellule vivante reste en vie si elle a 2 ou 3 cellules vivantes voisines.
• Une cellule mort (re)vient à la vie si elle a exactement 3 cellules vivantes voisines.

Malgré l’apparente simplicité, il est tout bonnement quasiment impossible d’arriver à une implémentation finie au bout des 45 minutes. De plus, de nombreux choix s’offrent à vous et la solution que vous avez en tête risque fort d’être différente de celle de votre partenaire. Comment représenter l’ensemble des cellules? Sous forme de quelle structure de données? Comment récupérer le nombre de voisins d’une cellule? Autant de questions ayant de multiples réponses possibles !

Consignes imposées et solutions de contournement

Entrée en matière

Comme je l’avais évoqué, des contraintes étaient imposées à chaque itération. Les deux premières heures étant surtout dévouées à l’assimilation du contexte et à la réflexion sur les implémentations, les règles imposées étaient très peu contraignantes : se mettre en paire avec un total inconnu pour la première, et considérer la possibilité d’avoir une “carte” des cellules infinie en N dimensions pour la seconde.

Aucune structure de contrôle

La troisième a, quand à elle vraiment marqué les esprits : n’utiliser aucune structure de contrôle. Donc pas de boucle (ni for, ni while), pas de if, ni de switch etc. Les cervelles ont surchauffé pour trouver des contournements pour parcourir des ensembles d’éléments notamment. On peut par exemple utiliser une liste chaînée d’éléments avec un élément final d’un type différent pour arrêter l’itération, comme :

public class ElementChaine {
	private ElementChaine elementSuivant;

	public void setElementSuivant(ElementChaine elementSuivant) {
		this.elementSuivant = elementSuivant;
	}

	public void traiterChaine() {
		traiterElement();
		elementSuivant.traiterChaine();
	}


	public void traiterElement() {
		//Appliquer ici le traitement sur l'élément
	}
}

et la surcharge de l’élément final

public class ElementFinal extends ElementChaine {
	@Override
	public void traiterChaine() {
		traiterElement();
	}
}

Tell don’t ask

Cette itération était placée sous le signe du tout objet. Les types primitifs ne devaient être utilisés que s’ils étaient vraiment justifiés, les getters/setters étaient interdits, le but du jeu étant que les méthodes de la classe lui permettent de modifier elle-même son état interne, pas d’intervenir sur leurs valeurs directement. Nous avons donc privilégié des énumérations au lieu de booléens et pensé notre code de façon plus objet.

Ping-pong muet

Tout l’intérêt de cette contrainte est de faire comprendre l’importance du choix des noms des variables et des méthodes, même celles de test. Les deux protagonistes de la paire ne pouvant pas se parler. J’ai eu la chance de discuter brièvement avec une personne ayant une façon de voir la chose diamétralement opposée à la mienne pendant le retour précédent, et voyant cette confrontation de points de vue, l’animateur nous a conseillé de nous mettre ensemble afin de régler notre “différent” d’opinion par le code. L’expérience a donc de ce fait été particulièrement intéressante. Ça prend forcément un peu plus de temps pour faire passer le message que l’on veut, mais on s’en sort.

Au choix

Pour la dernière séance, en fin de journée, notre “animateur” a décidé de nous laisser choisir notre contrainte dans une liste :

• Le pire code pour que les tests passent : le principe est assez simple, si on veut qu’une méthode retourne 0 si x < 3, il suffit de lui faire retourner 0 tout le temps. En se basant sur ce principe du “coder juste pour avoir des tests verts”, on se rend vite compte comment avoir une couverture optimale, et des tests bien adaptés.
• Être toujours en contradiction avec son partenaire : le principe est assez intéressant, et je l’avais quelque peu expérimenté en version muette plus tôt dans la journée. C’est cependant une bonne chose que de se forcer à voir systématiquement une autre façon de faire ou de voir la chose.
• Sans les mains : ou presque, le vrai intitulé était “sans la souris”. Les amateurs de vi s’en sont donné à cœur joie. Cet exercice n’est vraiment pas facile du tout, il faut connaître les raccourcis de son IDE sur le bout des doigts : changements d’onglets/fenêtres d’options rapides… Je n’ai malheureusement pas eu le courage de m’y attaquer cette fois mais promets de m’entraîner à l’occasion.
• Pas plus de 3 lignes par méthode : c’est l’option que nous avons choisie avec ma partenaire pour la dernière session. 3 lignes suffisent dans la plupart des cas, sauf le plus souvent pour les initialisations (de listes notamment). Pour contourner cela, vous pouvez retourner l’objet sur lequel vous avez appelé votre méthode et chaîner les appels. Par exemple :

maListe.add(objet1).add(objet2).add(objet3);

Qui ajoute 3 éléments à une liste en une seule ligne.

Ce qu’on en a pensé

Cette journée a apporté énormément à tous les participants. Les moins expérimentés ont appris et pu mettre en pratique le TDD ainsi que certains design patterns. Les plus expérimentés ont pu coder pour le plaisir, sans la contrainte d’une livraison, avec la possibilité de se faire plaisir à chaque lettre tapée pour avoir le code le plus parfait possible. Ils ont pu partager leurs connaissances et confronter leurs points de vue à ceux des autres participants.

Personnellement, j’ai vraiment pris beaucoup de plaisir lors de cet événement, et y reviendrais avec plaisir si l’occasion se représente. J’espère vous y croiser !