Jeudi 6 octobre avait lieu la première édition des "Jams de Code". En référence aux Jam Sessions entre musiciens, il s'agit de se retrouver pour partager et pratiquer ce qui nous intéresse.
"Amenez votre laptop et votre langage préféré, nous fournissons la bière et les chips."
Lors de cette première nous étions 4 développeurs motivés sur 6 inscrits, ce qui est un nombre pair, parfait pour faire du pair-programming !
Code Katas
Nous avons choisi un code kata "Supermarket Pricing", qui commence sans code:
"Some things in supermarkets have simple prices: this can of beans costs $0.65. Other things have more complex prices. For example:
- three for a dollar (so what’s the price if I buy 4, or 5?)
- $1.99/pound (so what does 4 ounces cost?)
- buy two, get one free (so does the third item have a price?)"
Le sujet est rapidement passionnant, et on découvre une profondeur insoupçonnée à une problématique qui semblait banale. Celles et ceux familiers avec la finance ou le pricing des forfaits de téléphonie reconnaitront aussi des enjeux similaires (arrondis, règles de comptage...).
Après pas mal de discussions et d'idées (tellement de bonnes idées que ça me donnait envie de tout noter), mais aucune conclusion concrète, il était temps de se frotter à la réalité du code ! Un binôme en C# 4.0, un autre en Java, nous avons commencé le même exercice en code, test par test.
TDD as if you meant it and Tranformation Priority Premise
Nous avons tous fait du TDD en code de production, mais pas tant que ça en TDD extrême. Commencer par un "Canary Test" pour vérifier l'environnement, puis ajouter un premier test ultra trivial, puis un autre encore trivial, et ainsi de suite. C'est lent, et c'est justement la raison de pratiquer en dehors de la pression du bureau.
Ensuite, on se retient de sauter sur des abstractions trop rapidement: pas besoin d'introduire de classe, une fonction suffit. Et dans le style TDD as if you meant it on commence par écrire une implémentation dans le test. On s'oblige à une assertion par test. On consacre du temps à bien nommer chaque test.
Ce qui était très sympa en étant peu nombreux et face à face, c'est qu'on pouvait échanger en direct entre binômes sur nos hésitations et conseils, dans une sorte de "pairing à basse fréquence entre pairs à haute fréquence".
On a aussi évoqué et tenté de respecter l'idée de Tranformation Priority Premise proposée par Robert Martin, qui consiste à ne jamais sauter d'étape dans l'élaboration d'une implémentation: "on refuse de prendre une décision [ajouter du code d'une complexité supérieure] tant que le test ne nous y oblige pas".
Remarques
On estime souvent que l'exercice de notre métier ne permet pas une pratique suffisante; j'étais néanmoins surpris quand Mathieu nous dit avoir codé les "Roman Numerals", non pas comme un kata mais pour son employeur, et néanmoins en TDD, test après test ! Ça me rappelle que le choix d'une mission ou d'un poste qui offre des vrais défis en est un véritable plus pour progresser plus rapidement à effort égal.
Lors de la mini rétrospective finale nous avons comparé le temps passé à discuter de possibles solutions avec le temps passé à faire grossir une implémentation guidée par les tests, avec le sentiment que l'approche par les tests, bien que lente, progresse au moins mécaniquement vers une conclusion, ce qui n'est pas le cas des discussions "en l'air". Néanmoins de telles discussions sont passionnantes et finalement assez proches d'un brainstorming, qui a aussi son utilité.
Nous nous sommes quittés en discutant de nos techniques pour intervenir sur du code legacy. Il s'agit d'un vaste sujet qui revient en force sur le devant de la scène, et c'est tant mieux car c'est un enjeu majeur de notre métier !
Rendez-vous le premier jeudi de chaque mois à 19h30 au siège d'Arolla (21 rue du Bouloi, Paris 1er) pour participer à ces Jams de code!
Directeur Technique d'Arolla