Code Retreat

Il y a quelques mois (en juin), j’ai participé à une code retreat sur Lyon. Autant dire que pour prendre un TGV a 6h du mat, je devais être motivé !

Avant de vous parler plus du pourquoi c’est bien une code retreat, je vais quand même vous expliquez ce que c’est.

Prenez un nombre pair de personnes. Prenez un problème d’algo simple mais pas trop. Faites des sessions de 45 minutes, où les gens travaillent par paire (mais avec une seule machine, du vrai pair programming quoi) pour essayer de ‘résoudre’ le problème en TDD. La première session faite la simple, sans contrainte, puis rajouter des contraintes genre ‘ pas de boucle, vous ne pouvez pas parler , vous ne communiquez qu’à travers les tests, une fonction fait 5 lignes max’, etc etc ..

A la fin des 45 minutes, vous supprimez votre code, faites une rétrospective, vous trouvez un/une nouveau binôme et recommençait l’opération, avec un nouvelle contrainte.

Ce qu’il y a de rigolo, c’est qu’à chaque session vous pouvez (c’est conseillé) changer de langage de programmation. Vous pouvez commencer avec du python, puis faire une session PHP, puis ruby, puis C#, etc …

Pour tout dire, lors de la code retreat que j’ai fait, je me suis même retrouvé à faire, pendant une de mes sessions du C# (et ben j’ai pas aimé:) ) .

mais ça sert à quoi de passer 1 journée à faire X fois la même chose, avec des gens différents, et de jeter son travail à chaque fin de session ?

Alors, si vous lisez de la doc sur la question ( où ce billet de jérémy qui présente bien les choses), vous comprendrez que c’est une excellente forme d’entraînement. Pas de pression de la livraison (vu qu’on jette tout), pas de pression du ‘ça va partir en prod’ , vu que l’on jette tout. Pas du pression de ‘il faut finir’, vu que bon, tout va être jeter et qu’il de toute façons, ce que vous diront les orga au tout début, c’est qu’il ne faut pas chercher à finir, parce qu’en 45 minutes, on ne peut pas. Ce n’est pas le but de toute façon, le but c’est de s’exercer.

Donc oui, vous allez voir, ca sera une excellente forme d’entraînement. Mais pas seulement. Enfin, pour moi, cela ne fut pas seulement une session d’entraînement super intéressante.

J’ai trouvé que cela apprenait des choses sur soi même, pas mal et sur notre métier en général. Histoire de ne pas faire trop long, je vais simplement donner deux exemples de ce que j’ai appris lors de cette journée.

Sur moi même tout d’abord.  Ben oui. La première session, je l’ai faite avec quelqu’un qui n’avait fait que très très peu de python et qui voulait s’y ‘remettre’ le temps d’une session. Du coup on avait pas trop la barrière du langage de prog qui est connu que par l’un des deux et on sait dit allez on y va. On a commencé en TDD comme c’est imposé. Et puis on voyait le temps défiler et le code avançait et à un moment, ben c’était possible d’aller vite et de finir. Oui le but est pas de finir, c’est pas fait pour, bla bla bla. Mais on pouvait finir. Et du coup, ben on sait dit ‘ok, on finit et on écrit les tests après’. Et on a finit.. mais quand les 45 minutes ont sonnés, ils nous manquait .. 5 ou 6 lignes de tests pour prouver qu’on avait fini …’ Et on a du faire un rm -rf * … Donc on a pas fini. Et on était dégoûté. Parce qu’on était si proche ..  Mais pour arriver si proche du but (qui n’est même pas le but à atteindre), on avait du contourner les règles. En se disant ‘bon tant pis allez, on fait comme si’.

Je ne pensais pas qu’il me serait aussi facile de lâcher la consigne pour le plaisir d’atteindre un but auto fixé, juste par ‘égo’.
Et sur notre métier et la façon de le faire. Il y a quelques temps, j’avais suivi / lu quelques conférences qui parlait de l’importance de la documentation pour du code (mais de la vrai doc, pas juste des commentaires dans le code). Et sur le fait que la doc pouvait même être plus importante que des tests. Et qu’à choisir entre pas de tests ou pas de doc, il valait encore mieux ne pas avoir de doc.

Sur le coup, j’avais trouvé ça bizarre, voir plus. Après tout la doc c’est le code non ? Et les tests ? Mais j’avais entamé une réflexion sur le sujet.

Et cette code retreat a été un des éléments qui m’a fait comprendre que rien ne pouvait remplacer la doc. Et sûrement pas les tests. Nous avons en effet du faire une session en muet, où la seule communication entre moi et mon binôme c’était les tests. C’est à dire qu’un des membres du binôme écrivait un test, passait le clavier à son compère, celui-ci devait écrire le code qui passait le test puis un nouveau test, et ainsi de suite ….
Ce fut pour notre binôme, mais pour tout les binômes en général, une vraie bérézina. Et pourtant le problème a résoudre était simple, on le connaissait tout les deux. Mais l’enfer ..

Au final, les tests c’est bien pour tester. Pour expliciter des décisions de design de code, des choix d’algo, un parti pri méthodologique, j’en suis de plus en plus convaincu, c’est tout pourri et une vrai doc, c’est mieux !

Pourquoi je vous parle de cela maintenant, en octobre ? Parce que j’ai pas vraiment eu (pris) le temps d’écrire ce billet avant mais que là,  une code retreat s’organise à Marseille, le 14 décembre. Cette retreat du 14/12 était le petit aiguillon qui me manquait pour écrire un billet sur le sujet.

Parce que même si je ne pourrais malheureusement pas y être présent (et ça me chagrine énormément), je ne pouvais pas ne pas expliquer pourquoi c’est bien et pourquoi il faut y aller 🙂

(Juste une dernière chose, les code retreat sont des moments où il faut savoir preuve d’humilité. Y aller en mode ‘ninja’, ‘je vais leur apprendre comment il faut coder moi à ces codeurs du dimanche’, sans arriver à se questionner sur ses pratiques et sur leur améliorations possible, n’est pas une bonne chose. Voir une très mauvaise. Parce que vous allez vous y ennuyer et ne rien en apprendre, mais en plus vous allez occuper la place de quelqu’un qui aurait pu en ressortir avec un vrai gain … )