Code Retreat à Grenoble : mise en oeuvre de pratiques extrem programming

Vendredi dernier j’ai participé à une session de Code Retreat à Grenoble organisée par le CARA et le JUG. Merci aux organisateurs pour cette belle journée.

Le principe :

La scéance comporte 6 itérations. Le principe du code retreat réside dans le fait d’effacer le code à chaque itération . L’analogie aux arts martiaux tient dans l’idée de travailler plusieurs fois le même geste pour se perfectionner.

Le travaille est réalisé en TDD et en Pair programming. L’objectif est d’investiguer les pistes que l’on ne se permet pas dans un cadre industriel. Une consigne supplémentaire est d’appliquer les règles SIMPLE DESIGN :

1 – Les tests doivent passer
2 – Supprimer les doublons
3 – Nommage pertinent
4 – Faire court

Une itération se compose de :45 min de code, 10 min de rétrospective, 5 minutes de pause.

Ce que m’ont apporté ces itérations :

Pair programming de 10 minutes : l’idée est de changer de rôle toutes les 10 minutes : le pilote devient copilote et vis versa. La sensation est grisante : on a l’impression de courir une course de relais. S’échanger le clavier si souvent oblige à partager le design et la direction où l’on veut aller.

Mesurer le temps de cycle rouge : le TDD définit trois phases : une rouge pendant laquelle le test ne passe pas, une verte lorsque le test passe, et une dernière de refactoring. On s’attache à minimiser le temps de phase rouge en dessous de 5 minutes. L’exercice est intéressant car il oblige à ne pas prendre trop d’avance dans le design et à ne coder que ce qu’il faut pour que le test passe. Cela implique une réflexion sur les contraintes nécessaires pour garantir que le programme fonctionne.

Nouvel indicateur de design : facile à mettre en œuvre, si l’on a un « if » sur un état on peut éventuellement le supprimer en implémentant des classes dérivées.

Refactorisation des tests : attention à ne pas introduire des bugs dans la couverture de test sans s’en rendre compte. C’est pour moi le bémol de cette approche : comment garantie-t-on l’intégrité des tests si on les modifie ?

Le rôle du copilote : en recentrant les questions sur ce que l’on veut faire et les contraintes que l’on s’est donnée, le copilote influe directement sur la productivité. Il limite ainsi une tendance naturelle à s’éparpiller.

Le test comme guide pour le design : stressé par un design complexe, on a souvent tendance à anticiper et à écrire du code en avance alors qu’il n’est pas nécessaire. En essayant de limiter le temps rouge, le design nait de l’analyse de toutes les contraintes plutôt que des aprioris que l’on peut avoir en abordant le problème.

En conclusion :

  • Bilan très positif : 4/5 au ROTI. Il m’a peut-être manqué deux minutes de rétrospective en binôme avant de mettre en commun avec les autres participants.
  • Nouvelle facette du pair programming en changeant toute les 10 minutes : à essayer !
  • TDD : Ne pas trop se poser des problèmes de design en cours de test. Vraiment se concentrer sur l’aspect spécification. Ce sont les tests qui vont nous montrer la voie, il faut leur faire confiance.
  • Cette exercice est très bon pour enrichir ses approches. Promis j’essaierais de venir aux prochains Coding Dojos du CARA.
  • Attention au refactoring des tests.