Cartes de responsabilité

En ce début 2021, nous poursuivons les séances de mob avec Anthony et Guillaume avec le challenge de code “Rover on Mars”.

Après un premier cycle rapide directement dans le code, nous sommes gênés par la complexité croissante de certaines classes qui font beaucoup trop de choses et chaque petite modif commence à coûter. Nous nous posons la question de comment séparer tout ça avec des avis partagés. Ce qu’appelle la noirceur du fond d’écran de VSCode, c’est qu’il nous manque un tableau blanc.

Au bout d’une vingtine de minutes de conversation acharnée et voilà le résultat illustré :

Nous sommes alignés sur une option d’implémentation après avoir répondu à quelques questions de la responsabilité d’un PO. Y a plus qu’à mettre en place petit à petit en TDD.

Plusieurs approches :

1. Créer de nouveaux tests pour faire apparaître le besoin de nouvelles classes et les changements de responsabilités sans toucher aux anciennes classes.

2. Modifier les tests existants…

Nous choisissons la première option pour assurer le codage des nouvelles fonctions et le nettoyage progressif.

Pratique NR ?

Evaluons le résultat :

• le code est plus facilement modifiable car

• les classes sont réduites ne portant q’une seule responsabilité

• la décision a été partagée dans l’équipe.

• pas de code ni de test superflu.

• le code est documenté par les tests et par les diagrammes de CRC sous réserve d’avoir vérifié et adapté le schéma par rapport au résultat obtenu

Sur les moyens :

• 3 personnes se sont mises d’accord sur une solution consensuelle quant aux responsabilités de chacune des classes.

• pas d’étape de revue de code. La connaissance est partagée by social design.

Travailler les cartes de responsabilité des classes au moment où l’on en a besoin et en les mettant en oeuvre immédiatement après, pour un saut qualitatif du code et de la connaissance de l’équipe.

Je propose de baptiser ce type de cycle minimal une boucle d’écoconception.