9 Nov 2015

Evénement Learn To Craft du 20 octobre 2015

Mardi 20 octobre dernier se déroulait de 14h à 18h « Learn To Craft ». Cet événement gratuit était hébergé par Microsoft France et animé par Bruno Boucard, Thomas Pierrain et Jean Laurent de Morhlon. Je vais ici retracer le déroulé assez riche de cet après-midi et surtout les techniques et outils présentés.

L’agenda proposé était le suivant :

ProgrammeLearnToCraft2015

Le mouvement software crafts(wo)manship

Jean Laurent commence par présenter le mouvement software craftsmanship. Le début de cette présentation reprend “la culture du programmeur”. Personnellement, j’adore ! Après la théorie des 10kH, Jean Laurent donne les moteurs clés du craftsman :

  • rééquilibrer le niveau de la technique face aux processus
  • le programmeur doit savoir donner sa vision technique (pour expliquer, par exemple, un délai)
  • suivre un mentor pendant un temps puis en changer

L’objectif du craftsman est de s’améliorer et non d’être le meilleur.

Dans sa pratique du développement, le craftsman suit en général certains principes techniques, dont :

Le craftsman peut s’entrainer selon 3 formats principaux :

En synthèse, la clé de l’amélioration réside dans l’entrainement seul et surtout en groupe.

Maintenant que l’audience est entrée dans le bon mindset, on passe à la pratique.

Atelier : TDD & Pair Programming

Bruno et Thomas ont alors pris la suite avec une session de pair programming autour du Kata StringCalculator. Lors de cette session TDD, Bruno et Thomas utilisent la technique “TDD as if you meant it“. Ainsi, dans la classe de test, ils ajoutent la classe d’implémentation et codent dans le même fichier. Le but est de conserver le code proche du test puis de déplacer son code au bon endroit. A chaque nouveau test, Bruno utilise son snippet “TU” qui créé le squelette de la méthode de test avec son nom prérenseigné à Should_behaviour_when_condition. On découvre également les outils utilisés mais je reviendrais dessus à la fin de cet article.

Après une petite pause, les participants avaient le choix de pratiquer dans un coding dojo (coffee machine) ou de continuer sur des session de live coding autour du legacy. Pour ma part, j’ai souhaité continuer sur les pratiques de refacto legacy.

Atelier : une stratégie contre intuitive

Thomas est au clavier et nous présente le sujet de cette session le kata Guiled Rose. L’objectif est d’ajouter une fonctionnalité sans casser l’existant. Avant de positionner des tests de caractérisation, Thomas utilise les fonctionnalités de l’IDE/Resharper pour faire un premier ménage sans risque : renommage de variables, suppression de code mort mais, dans un premier temps, pas d’extraction de méthodes. Ensuite, Thomas produit des tests de caractérisation et exploite quelques fonctionnalités sympathiques de son framework de tests unitaires au niveau des listes d’Item. On constate qu’il faut itérer plusieurs fois pour passer dans les différentes branches du code. Thomas utilise alors la technique du Golden Master. L’idée de cette technique est de dupliquer la classe à refactorer puis de confronter les résultats du code d’origine à ceux du code refactoré. Le fait de devoir boucler pour faire évoluer le système est, à mon avis, un indice pour penser à utiliser cette technique. A cette étape, on peut attaquer une refacto plus en profondeur de notre méthode. En regardant le code, on constate qu’il y a beaucoup de similitude dans le code mais pas code dupliqué (autre smell). Au lieu d’extraire des méthodes, on part dans l’autre sens en dupliquant le code où nécessaire (çà, c’est contre intuitif). On homogénéise les comparaisons (même si on a un if vide et du code dans le else) et on ordonne nos if imbriqués pour faire apparaitre du code dupliqué. Une fois que les duplications sont biens visibles, on factorise en nommant explicitement les méthodes.

Au final, au bout de 50min, deux constats :

  • Le premier : nous n’avons pas eu le temps de développer la nouvelle fonctionnalité, il nous manque une petite vingtaine de minutes.
  • Le second : le code est transformé, prêt à recevoir un nouveau test pour avancer en toute sécurité.

Vous pouvez revoir une démonstration assez proche faite par David Gageot sur ce sujet en Java

Atelier : How to test untestable code

Bruno poursuit les ateliers avec un classique du cassage de dépendances : TripService. Vous trouverez les slides de Bruno sur SlideShare. Comme sur l’atelier précédent, on commence par nettoyer le code à l’aide de notre IDE/Resharper. On nettoie le pont (“clean the deck”) pour découvrir le code et de fait y voir un peu plus clair. Bruno pose ensuite des tests et casse différentes dépendances à l’aide de 3 techniques principales :

  • Parametrized constructor : on crée un nouveau constructeur pour injecter via paramètre la dépendance. Le constructeur existant est modifié pour utiliser notre nouveau constructeur.
  • Extract and override call : on encapsule notre dépendance dans une méthode virtuelle. Dans notre projet de test, on crée un héritier de la classe à tester et on surcharge la méthode virtuelle créée pour fixer notre comportement pour le test. Enfin, dans le test, on utilise cette classe fille.
  • Introduce instance delegator : on encapsule/wrap une méthode de type (static) dans une méthode d’instance.

Chacune de ces technique permet de positionner des tests de caractérisation. Le code obtenu en première itération ne doit pas rester ainsi. Il faut encore refactorer notre code pour aboutir à du code testable ET propre.

Les outils et framework utilisés

Les outils

Lors des ateliers, plusieurs outils et frameworks ont été utilisés. En dehors du “classique” Visual Studio ici dans sa version 2015, l’équipe a utilisé des outils assez bluffant.

Une des base de la productivité par Visual Studio, les snippets, qui évitent de retaper toujours le même code. Le snippet “TU” de Bruno, un must do sur vos projets !

Le très connu Resharper qui étend les capacités de refacto de Visual Studio. Allié à une bonne connaissance de raccourcis clavier, Resharper augmente fortement la productivité du programmeur. Certains regretterons l’aspect intrusif de Resharper dans leurs habitudes, je n’ai qu’un chose à dire : n’ayez pas peur du changement !

J’ai pu découvrir NCrunch. Et là, j’ai clairement pris une claque. Tout simplement ENORME ! Le principe est simple : NCrunch joue vos tests unitaires alors que vous êtes en train de taper votre code. Pour avoir le feedback sur vos tests, plus besoin de sauvegarder, d’aller chercher l’explorateur de tests, chercher la classe de test et exécuter juste la partie qui va bien (pour ceux qui utilise le clavier, la différence arrive), compiler, charger les assemblies, exécuter les tests et chercher le résultat. NCrunch s’intègre dans Visual Studio à merveille et permet d’avoir dans l’éditeur de texte toute les informations utiles. NCrunch m’a semblé assez rapide – léger lags sur une VM Windows sous mac. Je vous laisse regarder la présentation sur le site et pourquoi pas faire une évaluation du produit. Attention aux projets legacy et aux tests d’intégration, il faut configurer NCrunch avant de l’activer sinon vous allez au devant de gros problèmes (entre autre : appels BDD, WebService). Ce qui me freine sur cet outil, c’est le cout de la licence company seat à 290$ (oui, 290$ par développeur!). A ce prix là, il n’y a même pas l’exécution des tests JavaScript!

Les frameworks

Nous avons l’environnement de développement standard de l’après midi. Lors des sessions, l’équipe exploite ces outils pour faire du TDD. Pour développer, Bruno et Thomas utilisent les frameworks suivant :

  • NUnit pour les tests unitaires. J’ai aimé les tests unitaire paramétrés avec l’attribut TestCase et l’attribut de test de levé d’exception qui permet de spécifier le type et le message.
  • NFluent pour réaliser les assertions. J’aime ces méthodes d’extensions qui révèlent bien l’intention du test.
  • NSubstitute pour les stubs et les mocks. Je n’ai pas particulièrement vu de différence avec Moq pour mon usage quotidien. A tester 🙂
  • FakeItEasy également pour les stubs et mocks mais non démontré dans les sessions. Une autre évaluation à faire.

Où rencontrer des crafts(wo)man

En conclusion de cet après-midi, l’équipe a communiqué des points de rencontres (très parisien, mais vu le lieu, c’est normal).

Pour 2016 :

Il n’y a pas que des garçons qui dev, allez voire duchess france !

Un peu d’auto promotion sur Lille : Meetup Software Craftsman Lille.

Une interview de Cyrille Martraire sur le craftsman et la communauté parisienne.

Mon avis sur ces sessions

J’ai beaucoup aimé le dynamisme des ateliers, rien ne remplacera la pratique du code. J’ai pu découvrir de nouveaux outils/framework. Il va maintenant falloir travailler sur ces différents sujets pour voir leurs capacités et limites. Je retiens également les techniques de travail sur du code legacy certaines nouvelles pour moi, d’autres connus et bien efficace

Share