lundi 24 septembre 2012

Initiation TDD en entreprise


Dans mon ancienne entreprise, une SSII de 50 consultants, nous étions 4-5 personnes à pratiquer le TDD ou à tenter de le pratiquer le plus possible et souhaitions qu'il devienne la norme sur nos projets.

Malgré mon peu d’expérience (junior et loin d'être un expert TDD), j'ai décidé d'essayer de le promouvoir à travers un atelier, voici donc un retour d'expérience qui pourrait aider ceux et celles qui souhaitent convaincre de l'utilité de cette technique sans se sentir les talents de Kent Beck.



Format

Le choix du format est primordial et dépend surtout de la cible. Là nous ne parlons pas d'un atelier fait le soir entre geeks passionnés mais bien d'une initiation en interne.
L'activité principale de mon (ancienne) entreprise est l'intégration d'une solution propriétaire.
Nous avions donc des profils "développeur" mais aussi des profils "administrateur" (développement ponctuel de routines, customisations légères).
Dans cet atelier j'avais donc un panel large de profils: du pratiquant TDD convaincu à des profils moins techniques en passant par des stagiaires curieux.

Il y avait différentes solutions envisageables. Il fallait que l'atelier:

          - Ne dure pas plus de 2h. Etant organisé après le travail, il est dur de motiver des gens à rester tard pour une première session
          - Montre l'utilité du TDD
          - Fasse pratiquer les participants

J'ai envisagé plusieurs formats.

Code Retreat
Un code retreat est une journée pendant laquelle nous codons en binômes sur un exercice donné dont la durée est timeboxé.  Toutes les 30mn (par exemple) les binômes tournent et on recommence de zéro. L’intérêt est de parfaire sa technique, et d'apprendre de nouvelles astuces voir d'essayer de nouveaux langages.
N'ayant vécu à l'époque que des codes retreat, je souhaitais transposer ce principe sur un atelier de 2h.
J'ai du écarter cette solution à cause de la nature éclectique de l’auditoire. En effet je pense qu'un fonctionnement par binômes est constructif lorsque la majorité des participants sont rodés à ce type d'exercice. Ayant peur que certains binômes ne s'égarent ou ne s'ennuient j'ai donc du y renoncer. C'est le retour d’expérience d'un ami qui a finit de me convaincre.

Coding Dojo: Kata
Une personne ou un binôme implémente une solution devant un auditoire en expliquant son cheminement. Ce type de manifestation est surement digne d’intérêt lorsque la personne en question est une rockstar. La seule chose plus ennuyeuse que de regarder quelqu'un coder est de me regarder coder moi précisément. De plus je souhaitais que tout le monde code donc ce format ne collait pas avec les pré-requis. J'ai donc aussi écarté cette solution.

Coding dojo: Randori
Le principe est simple:
- Un défi à résoudre
- Un pilote qui code
- Un co-pilote qui explique à l'auditoire et donne la direction au pilote
- Un groupe qui regarde

Toute les 7mn le pilote deviens co-pilote, le co-pilote rejoint le groupe et on prend un nouveau pilote dans le groupe.
Le coding dojo randori permet de résoudre un défi de maniére collaborative.

N'ayant pas envie de "donner un cours", le coté collaboratif du Coding Dojo m'a séduit.

Exercice

Je cherchais un exercice dont l'énoncé soit trivial : pas question de perdre du temps à assimiler et répéter les règles.

Il est possible de trouver toutes sortes de Kata sur le net:
http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue
http://www.cyber-dojo.com/

Mon choix s'est porté sur le Kata Roman Numerals car tout le monde connait les règles, et surtout parce qu'il permet de partir sur une implémentation "naïve" à l’extrême pour ensuite promouvoir le refactoring, qui était pour moi le point clé à montrer lors de cet atelier.

En effet le TDD induit certes une bonne couverture, mais surtout :
Bonne couverture -> risque moindre de régression -> possibilité accrue de refactoring 

Modifier le code ne fait plus peur !


Déroulement

J'ai commencé par une présentation sommaire des tests (bon test unitaire, avantages,ect), du TDD puis du coding dojo randori. La présentation est disponible ici:  [[présentation prezi]]

Je propose donc de commencer en tant que co-pilote, le pilote est prit au hasard dans le groupe.
Je le fais commencer par un test qui vérifie le premier cas:

@Test
public void convert_1_to_roman() {
     int toConvert = 1;
     String expectedRomanValue = "I";
     String actualRomanValue = RomanNumeralsConverter.convertIntToRoman(toConvert);
     Assert.assertEquals(expectedRomanValue, actualRomanValue);
}
De là s'ensuit la création de la classe (nous choisissons de partir sur une classe avec une méthode statique) et de la méthode.

Nous lançons le test, il échoue.
Pour l'implémentation, nous écrivons une implémentation "naïve":


public static String convertIntToRoman(int toConvert) {
     return "I";
}
A ce stade en général (vu sur mes 2 sessions) certains auront des réticences: après tout ils sont venu pour faire du code propre, qu'est ce que c'est que cette embrouille !
Il faudra alors les calmer et expliquer que chaque ligne écrite doit être couverte, et qu'il ne sert à rien de régler des problèmes que nous n'avons pas encore.

Le mieux est d'essayer de faire passer les 3 premiers tests (I,II et II) avant la fin de vos 7mn.
Dans un Coding Dojo Randori, le binôme est seul maître à bord lors des phases 'écriture de test' et 'écriture de l'implémentation'. Cependant entre chaque cycle peut avoir lieu la phase de refactoring:
Tout refactoring effectué doit être approuvé par l'ensemble de l'auditoire.

Au bout d'un certain moment le code deviendra très moche (suite de if et de else) et les refactoring commencerons.

Par exemple l'étape :
public static String convertIntToRoman(int toConvert) {
     if(toConvert==2){ return "II"; }
     if(toConvert==3){ return "III"; }
     return "I";
}


Sera refactorable (dans un premier temps) par exemple en
public static String convertIntToRoman(int toConvert) {    
    StringBuilder romanRepresentation = new StringBuilder(); 
    for (; toConvert > 0; toConvert--) {
 romanRepresentation.append("I");
     }
    return romanRepresentation.toString();
}

Au fil des refactoring, l'auditoire verra alors peu à peu se dessiner un algorithme: il faut impérativement emmener l'algorithme vers un état cohérent et concis, sinon l'atelier n'aura pas été convainquant. Vous pourrez, en tant qu'animateur, profiter de ces phases de refactoring pour orienter la session dans la "bonne" direction.
N'oubliez pas de faire remarquer l'utilité des tests lorsqu'ils deviennent rouge pendant les phases de refactoring: Il y en aura surement car les gens ont tendance à aller trop vite lorsqu'ils sont en public.


Vous trouverez divers implémentations sur le net (notement sur github) si cela vous intéresse.


Astuces
- N'oubliez pas les chips et les marshmallows !
- Ne pas hésiter à augmenter la police sous eclipse pour que tout le monde puisse voir.
- 3 plugins sympas pour ce genre d'ateliers: http://www.happyprog.com/
- Faites l'exercice seul avant, pour être sûr que l'atelier aboutisse à quelque chose de concret.
- Profitez en pour placer des notions de bonne pratique: bon nommage, commentaires, .

Conclusion
Cela a été globalement réussit:
- Des curieux repartis convaincus. Certains s'y sont mis et voilà déjà plusieurs mois qu'ils codent en TDD.

- J'avais initialement prévu 1 session de 6-7 personnes (maximum pour un confort optimal) et j'ai du remplir 2 sessions de 10 personnes.

- Une moyenne de 4,5 sur le ROTI (à relativiser: c'est plus le lancement de ce genre d'ateliers au sein de l'entreprise que l'atelier en soit qui a suscité cet engouement à la base)

Cela m'a montré qu'il peut y avoir une réelle attente de ce genre d’évènements même quand cela n'est pas flagrant au sein d'une entreprise.

Grosse victoire: Coté management cela a été remarqué, et des efforts sont faits dans ce sens; Une session a même été prévue sur les heures de travail pour permettre de "former" plus de gens au TDD.

Personnellement cela a été une très bonne expérience et j'ai pu restituer ce que j'ai apprit auprès d'autres personnes.

J'ai découvert un autre type d'exercice qui aurait pu être pertinent: L'ajout de fonctionnalité dans du code Legacy (vieux code sans tests). Demande plus de préparation mais peut être beaucoup plus amusant.

Aucun commentaire:

Enregistrer un commentaire

Crédits

Thème dérivé du GUI Set Retro-pixel.