Coding Dojo du Mardi 15 décembre 2020

Déroulé du kata

Première partie : Design upfront

Dans un premier temps, chaque pair se trouve une salle dans discord et doit trouver un moyen de s’appropier les règles du kata. Chaque pair a 20 minutes pour comprendre ce qui est demandé. Au bout de 20 minutes chaque groupe présente son résultat. Dans cette session, il y a eu plusieurs formats:

  • Du pseudo-code
  • Des schémas UML
  • Un example-mapping

Seconde partie : TDD

La deuxième partie est un TDD classique de coding dojo:

  1. On écrit un test qui échoue
  2. On implémente le code qui fait passer le test
  3. On récrit le code pour améliorer sa qualité
  4. On revient à l’étape 1

Les retours en fin de session

Design pas optimal, pas de temps gagné sur la phase d’analyse. Analyse upfront dans la session peu efficace.
Essai de gherkin avec les PO, mais ça ne marche pas. Analyse métier uniquement.
Globalement bien aimé. Tendance à renommer en général ?
Pas arrivé à l’étape où le code montre que le design n’est pas valide. Manque de temps sur la seconde partie.
Que veut dire Design upfront ? C’est ce que Bob Martin disait que le code ne pouvait pas être design avant qu’il soit écrit, d’où le TDD.
Ça peut être un outil pour comprendre les contraintes techniques. Ça ne doit pas être une phase de 3 mois mené par un architecte qui ne code pas.
Pour un PO, les use case sont bien pratiques pour communiquer.
Crevé donc pas possible d’être attentif
Première phase pas claire, donc pas compris ce qui était attendu
Test first vs TDD : être guidé par les tests demande de l’entrainement
Essayer d’exprimer les rêgles
Dans le mob programming, il faut accepter la première solution qui est donnée et accepter d’être constructif pour éviter les phases d’échange infini

Préparation du Kata et déséquilibre des débutants/expérimentés qui n’a pas aidé la session.

Roti :

  • 2 : 1 personne
  • 3 : 3 personne
  • 4 : 10 personnes
dojo