Modifier

Compte rendu - Kata Diamond - 29/07/20

Introduction

Aujourd'hui, cette session a regroupé 3 participants. Nous avons travaillé sur le kata Diamond où l'objectif est de créer un diamant en fonction d'une lettre passée en paramètre.

Par exemple

A : A   B : A   C : A    D :  A
           B B     B B       B B 
            A     C   C     C   C
                   B B     D     D
                    A       C   C
                             B B
                              A

Ce kata peut être résolu de plusieurs manières, l'une des méthodes intéressantes étant l'utilisation de PBT (Property Based Testing). Cependant, pour les besoins de la journée, nous avons utilisé du TDD classique. Il se trouve que dans le cas de cet exercice, on passe plus de temps à refactorer qu'à écrire des tests et les faire passer au vert.

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

Enumération des tests

L'énumération des tests a été assez rapide.

  • Tester le diamant A
  • Tester le diamant B
  • Tester le diamant C
  • Tester les 26 diamants ?

Bien entendu, on ne testera pas les 26 diamants. On espère trouver l'algorithme à partir du 3ème ou 4ème.

Ce que l'équipe a appris

Les raccourcis claviers

Il y a toujours des raccourcis claviers à apprendre. Encore une fois, les participants se sont améliorés au niveau de l'utilisation du clavier.

  • Ctrl + E => Accéder aux fenêtre. En cochant accéder aux sous éléments, on peut aussi faire une recherche sur le nom des procédures
  • F2 => Accéder au code de la fenêtre active
  • Ctrl + S => Sauvegarder le fichier courant et activer le compilateur
  • Ctrl + F9 => Exécute le projet. Lorsqu'on utilise wxUnit, cette option lance tous les tests
  • Ctrl + Alt + Espace => Retrouver les différentes options du menu en tapant le nom du menu qui nous intéresse. Si on valide par Entrée, on lance l'action correspondante
  • Ctrl + F4 => Fermer la fenêtre en cours
  • Ctrl + Shift + W => Fermer toutes les fenêtres
  • F4 => Créer une procédure à partir de l'élément courant
  • Ctrl + D => Dupliquer la ligne de code courante ou les lignes de code sélectionnées
  • F12 => Aller sur la prochaine erreur de compilation. Dans ce cas, je préfère désactiver les warnings qui s'affichent en premier et perturbent la navigation
  • Ctrl + L => Supprimer la ligne de code courante ou les lignes de code sélectionnées
  • Ctrl + A => Sélectionner toutes les lignes
  • Ctrl + R => Réindenter toutes les lignes
  • Ctrl + Y => Annuler le Ctrl + Z

Paramétrage de l'IDE

Nous avons regardé les paramétrages de l'éditeur de code :

  • passage du code en anglais
  • quand on colle du code, il est automatiquement traduit en anglais (seulement la syntaxe du wLangage)
  • désactivation de l'indentation en cas de copier / coller
  • désactivation des entêtes automatiques lorsqu'on crée une procédure
  • changer la police du code

wLangage.

Nous avons vu la syntaxe permettant de définir une chaîne de caractères sur plusieurs lignes en utilisant les crochets [].

Nous avons vu aussi les fonctions repeat, asc et charact très pratiques pour cette exercice.

TDD / clean code

Nous avons vu comment mettre en place le projet KataExemple et comment installer wxUnitViewer. W. qui a déjà fait du pair programing avec moi a montré comment faire à ses camarades. C'était un plaisir de le laisser faire.

Le premier test est toujours le plus compliqué. L'équipe a commencé à écrire un test, puis à écrire le code qui va avec, sans lancer le test... Au changement de cycle, je leur ai rappelé ce petit détail. Par la suite, les tests ont tous été lancés correectement et plusieurs fois. Toujours dans l'écriture du test, nous nous sommes posés la question si on commençait avec une classe ou directement une méthode. Nous avons décidé de faire simple et de partir sur une méthode. Il sera toujours possible de l'extraire plus tard...

Nous nous sommes forcés à créer les fonctions seulement lorsque le compilateur nous le demande. Ainsi, pas de code inutile. Pour cela, on commence par écrire le code de test qui utilise la fonction, Ctrl + S pour activer le compilateur. L'appel passe aussitôt en rouge et là, on crée la fonction.

Petit débat sur l'utilisation d'un IF ou d'un SWITCH. Personnellement, j'ai une préférence pour utiliser le IF au début du code et lorsque le code est fini d'écrire, on utilise le SWITCH si on en a toujours besoin. En effet, le SWITCH est plutôt verbeux et compliqué à utiliser par rapport à plusieurs IF.

Nous avons eu un autre débat sur le fait d'écrire du code en prévision des besoins ou pas. Je leur ai expliqué le terme YAGNI comme dans la session précédente. Je leux conseille d'écrire le code seulement s'ils en ont besoin.

Refactoring

Durant cette session, nous avons vu les refactorings Extract method et Extract parameter, toujours tèrs pratiques à utiliser.

Extract method

Ce refactoring consiste à créer une nouvelle procédure à partir d'une portion de code sélectionné.

Pour faire un extract method en WinDev le plus simplement possible (à savoir que l'option de menu qui permet de le faire ne marche pas correctement et bloque sur certain cas), il suffit de suivre la procédure suivante.

  • Sélectionner le code que l'on souhaite mettre dans la procédure
  • Copier le code
  • Remplacer le code sélectionné par le nom de la procédure que l'on souhaite créer
  • Créer la procédure (raccourci F4)
  • Coller le code (en rajoutant un RESULT / RENVOYER si c'est une fonction qui doit renvoyer une valeur)
  • Corriger les erreurs de compilation de la nouvelle procédure en rajoutant les paramètres manquants
  • Corriger l'appel de la nouvelle procédure en rajoutant les arguments manquants
  • Relancer les tests pour vérifier que tout fonctionne

Extract parameter

Ce refactoring consiste à passer en paramètre une valeur utilisé dans la procédure courante.

Pour le mettre en place, il suffit de suivre la procédure suivante :

  • Sélectionner le code que l'on souhaite remplacer par un paramètre
  • Copier le code
  • Remplacer le code par le nom du nouveau paramètre
  • Corriger l'erreur de compilation en ajoutant le nouveau paramètre à la procédure
  • Corriger les appels de la procédure modifiée en collant le code
  • Relancer les tests pour vérifier que tout fonctionne

Bilan

Nous avons terminé l'exercice et nous pouvons désormais créer tous les diamants que nous voulons !

Retour de R.

Il a aimé les raccourcis claviers. Il a mis en place TDD dans l'un de ses développements. Il faudra qu'il fasse un point avec moi un peu plus tard. Il a trouvé les étapes du début trop triviales.

Retour de M.

L'exercice était intéressant. Il doit travailler la méthode de refactoring. Il a aussi apprécié les raccourcis clavier qu'il ne connaissait pas.

Retour de W.

Il trouve qu'on apprend quelque chose de nouveau à chaque exercice. Ca vaut la peine de prendre le temps de faire du refactoring. Il a constaté qu'il brule des étapes et qu'il fait des erreurs "bêtes". Il va essayer d'améliorer ça. Il faut pratiquer et se forcer à travailler. Il faut s'entrainer, ce n'est pas inné. Il a appris plein de fonctions WinDev.

Retour de Jonathan

Cette équipe aussi m'apporte beaucoup de plaisir. Il y a une bonne entente et ils se donnent à fond dans l'exercice. Afin de progresser, il faut constamment se remettre en question, ce que j'ai constaté avec eux. Cet exercice repose totalement sur l'art du refactoring et j'ai senti qu'ils ont appris des choses intéressantes. J'ai hâte de voir s'ils vont pouvoir le mettre en oeuvre. J'ai hâte aussi de la prochaine session avec eux.