Modifier

Compte rendu - Kata Calculator - 29/07/20

Introduction

Aujourd'hui, cette session a regroupé 4 participants. Nous avons travaillé sur un kata que je nomme Calculator (différent de String calculator) où l'objectif est de créer une fonction qui permet de calculer le résultat d'une expression sous forme de chaîne de caractère.

Par exemple :

4+5 => 9

Ce qui est intéressant avec ce kata, c'est que dans une certaine mesure, on peut utiliser les expressions régulières pour réaliser l'exercice. En général, il est très compliqué d'écrire du premier coup la bonne expression, mais avec TDD, du moment que l'on connait la syntaxe des expressions régulières, on peut les écrire facilement.

Cet exercice a été fait en WinDev 25 avec wxUnit comme framework de test (de ma création). Nous avons fait du mob programming (un driver, 3 navigators) avec des cycles de 7 minutes. Tout cela en connexion à distance via Teams.

Pour commencer la session, nous avons énuméré les différents tests possibles. Cette idée m'est venu suite à la lecture du livre d'Emily Bache qui donne beaucoup de conseil pour l'organisation de coding dojo.

Le fait d'énumérer mes tests a permis à l'équipe deux choses :

  • Être sûr que tout le monde a compris l'exercice
  • Savoir quoi écrire pour le premier test.

Enumération des tests

Les différents tests que nous avons songé à énumérer sont les suivants :

  • Tester une chaîne vide. Que se passe-t-il dans ce cas ? Nous avons décidé de renvoyer 0.
  • Un nombre seul doit renvoyer un nombre.
  • Tester une addition : 1+1, 1+2
  • Tester les différents opérateurs : addition, soustraction, division et multiplication
  • Tester une valeur négative

Ce que l'équipe a appris

Les raccourcis claviers

Une des raisons intéressantes de participer à ces coding-dojo, c'est qu'il y a toujours un raccourci clavier que l'on ne connait pas. Les développeurs ont tendances à trop utiliser la souris. En forçant les participants à lacher leur souris, ils ont du apprendre à découvrir les raccourcis claviers.

  • Ctrl + Backspace => Effacer un mot (plus pratique que d'utiliser backspace plusieurs fois d'affilé)
  • Home / End => Se positionne au début / à la fin de la ligne
  • Ctrl + Home / Ctrl + End => Se positionne au début / à la fin du fichier
  • Shift + Home / Shift + End => Sélectionne jusqu'au début / jusqu'à la fin de la ligne
  • Ctrl + Shift + Home / Ctrl + Shift + End => Sélectionne jusqu'au début / jusqu'à la fin du fichier
  • Ctrl + A => Première fois, sélectionne la portion de code en cours, seconde fois, sélectionne la totalité du fichier
  • Ctrl + D => Duplique la ligne en cours (pas besoin qu'elle soit sélectionnée), ou les lignes sélectionnées

Les expressions régulières

Les participants connaissaient peu, voire pas du tout les expressions régulières. Ils ont donc découvert un outil pratique pour analyser et extraire des informations depuis une chaîne de caractère.

En WinDev, la fonction pour gérer les expressions régulières s'appelle MatchRegularExpression (VérifieExpressionRégulière en français). Nous avons vu sa syntaxe et la manière de l'utiliser.

Nous sommes tombés sur quelques petits détails qui auraient pu jouer des tours :

  • Le symbole + est un caractère réservé des expressions régulières. Nous l'avons mis entre crochets pour le capturer comme un caractère.
  • Le symbole - entre crochets permet de sélectionner sur un intervalle de caractères. Si on souhaite seulement capturer le -, il faut l'échapper ou le mettre au début ou à la fin de l'expression entre crochets.
  • Le symbole . permet de capturer n'importe quel caractère. Cette information n'est pas présente dans la documentation de PCSoft. J'en ai profité pour rajouter un commentaire dans la documentation.

Nous avons aussi vu un message d'erreur associé à la capture à l'aide de la fonction : "Pas assez de paramètres de récupération de sous-chaînes par rapport au format." Cela indique que l'on récupère plus d'expression que l'on a de variables pour les stocker.

TDD / clean code

L'objectif de ces sessions est surtout d'apprendre TDD et clean code. Nous avons appris plusieurs choses.

Tout d'abord, il faut se laisser guider par les tests. L'un des participants à créé une classe cCalculator qui n'a jamais été utilisée lors de l'exerice. Au final, c'est une méthode calculator qui a été utilisée pour calculer le résultat de l'expression.

En fait, si l'on suit la méthodologie TDD, tout doit commencer par un test. On crée les méthodes et les classes lorsque le compilateur nous le demande. Cela nous assure que l'élément en question va être utilisé.

Une autre chose importante que j'ai rappelé aux participantx, c'est qu'il faut penser à lancer les tests. En début de session, les périodes sans avoir fait tourner les tests étaient très longues.

Je leur ai aussi expliqué qu'au premier test, il faut faire échouer artificiellement le premier assert, en renvoyant par exemple une valeur qui est fausse. Cela nous permet d'être sûr que cette assertion est en place. Les assertions suivantes échouent forcément, sauf si elles sont déjà gérées.

J'ai aussi rappelé aux participants qu'on ne testait qu'une seule chose à la fois. Certains tests faisaient évoluer deux portions différentes du code. A la fin du cycle, ils sont repartis sur de bonnes bases.

Nous avons aussi vu la siginification de Yagni. Littéralement, "tu ne vas pas en avoir besoin". L'idée, c'est de ne développer que les choses nécessaires au projet. En TDD, cela signifie qu'on ne doit pas prévoir les fonctionnalités que les tests qui suivent vont nous demander.

J'ai aussi rappelé aux participants qu'on ne fait pas de refactoring sans être au vert. Si on ne respecte pas cela, le risque de devoir utiliser le débogueur augmente, et tout le monde le sait. Le débogueur, c'est une perte de temps.

Enfin, nous avons utilisé le code coverage pour supprimer du code mort. Pour l'activer, il faut aller dans le menu Tests Automatiques, puis cliquer sur "Afficher dans le code".

Enfin, nous avons étudié le nommage des éléments. Nous avons eu un nom de méthode de test addTwoNumberReturnResult. Le problème avec ce nom, c'est que l'addition de deux nombres retourne implicitement un résultat. Un nom de méthode intéressant serait : should_addTwoNumber qui indique que notre fonction doit savoir ajouter deux nombres. Idem pour le paramètre de notre fonction calculator, le nom initial du paramètre était str. Après réflexion, nous avons choisi expression, puisque nous souhaitions calculer le résultat d'une expression.

Bilan

A chaque fin de session, je demande aux participants de me dire ce qu'ils ont appris, aimé et ce qu'ils souhaiteraient que je change / améliore. Je n'ai jamais de réponse à cette dernière question. Il faudra peut-être que je la reformule.

Voici une idée de leur retour :

Retour de G.

G. avait déjà fait l'exercice et l'a trouvé différent de la fois précédente. Cela n'était pas facile au départ, mais il a trouvé très intéressant de travailler en groupe de 4.

Retour de M.

Il a apprécié le travail à plusieurs sur un même code. Il constate qu'il voit encore trop loin par rapport à l'approche TDD. Il a trouvé l'exercice intéressant et il va essayer de le refaire de son côté. Il aime bien le format 7 minutes avec debrief entre chaque cycle.

Retour de A.

Il se sent plus à l'aise avec les expressions régulières. Il connaissait un peu mais il ne s'en est jamais réellement servi. Il a apprécié de travailler à plusieurs. Il aime bien le format 7 minutes avec debrief entre chaque cycle.

Retour de K.

C'était intéressant de travailler à 4. Le fait de travailler avec d'autres personnes en même temps est bénéfique. Elle n'a pas eu l'impression d'être au travail au cours de l'exercice car elle trouve cela ludique. Elle aussi avait déjà fait l'exercice et elle était satisfaite d'être allée beaucoup plus loin que le précédent calculator. Le fait d'énumérer les tests en début de session a facilité l'exercice. En effet, dans les sessions précédentes, nous ne le faisions pas.

Retour de Jonathan

J'ai vraiment apprécié de travailler avec cette équipe. L'ambiance était bonne et l'équipe est très ouverte sur ce que je leur propose. J'ai constaté que l'écriture du code devenait de plus en plus fluide au fur et à mesure que le temps passait. Si le début était compliqué avec TDD, très rapidement, ils ont pris les bonnes habitudes. A chaque session, je constate qu'ils utilisent beaucoup la souris, ce qui fait perdre un temps fou par rapport à l'utilisation du clavier. Bien entendu, WinDev nécessite beaucoup la souris pour certaines actions, mais en forçant les participants à débrancher leur souris, ils ont fait de sacré efforts pour n'utiliser que le clavier. Cela a donné lieu à certaines situations amusantes où l'on voit le curseur se déplacer un peu partout sur l'écran, sauf là où il faut aller. Pour faire echo au retour de K., je n'ai pas l'impression de travailler moi non plus. C'est vraiment un moment ludique que je partage avec eux. J'espère qu'ils arriveront à trouver le temps pour refaire cet exercice de leur côté. S'ils arrivent à y consacrer un peu de temps, leur montée en compétence ne fera aucun doute.