Recherche simple
Lettre d'information
Inscrivez-vous à la lettre d'information pour recevoir des nouvelles du blog et des contenus exclusifs.
S'inscrireAujourd'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 :
Les différents tests que nous avons songé à énumérer sont les suivants :
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.
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 :
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.
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.
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 :
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.
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.
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.
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.
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.