Mardi 20 Octobre 2015 avait lieu chez Microsoft l’évènement “L’après-midi du Software Craftsmanship pour les développeurs .NET ou pas ! ” organisé par Eric Vernié (que tous les développeurs .Net doivent connaître : @EricVernie) et animé par Thomas Pierrain (@tpierrain) ainsi que Bruno Boucard (http://brunoboucard.com/) et Jean-Laurent De Morlhon (@morlhon) qui ont fondé Learn To Craft. Les habitués des conférences agiles, évènements développeurs et autres meetup ont déjà dû croiser ces speakers, Jean-Laurent et Bruno avaient même animé un Coding Dojo aux TechDays 2015. Les avoir tous les trois réunis en faisait un évènement à ne pas manquer.
La première session, une keynote présentée par Jean-Laurent, nous a donné sa définition et sa vision de ce qu’est le mouvement Software Craftsmanship, car c’est avant tout un mouvement, et donc un ensemble de valeurs.
Il a commencé par rappeler l’importance de l’entrainement, de l’apprentissage par la pratique, beaucoup de pratique. Il a fait le parallèle avec la théorie de 10 000 heures d’Anders Ericsson, temps nécessaire selon cette théorie pour devenir excellent dans un domaine. On pourra lire à ce sujet le livre de Gladwell “Outliers : the Story of Success”.
Parmi les valeurs prônées par ce mouvement, la première est d’inverser la tendance qui met en avant beaucoup de processus au détriment de la qualité technique. Scrum au départ, par exemple, ne parle que de processus, mais ici on veut aussi de l’excellence technique ! Ce mouvement cherche également à travailler sur le respect du programmeur. On a en effet toujours tendance à être challengé par des gens dont ce n’est pas le métier, alors que ces mêmes personnes ne se permettraient pas de remettre en cause la façon de travailler d’un ingénieur du BTP.
Enfin Jean-Laurent est revenu sur l’importance de ce que l’on peut appeler le “mentoring”. On va essayer de se trouver des “maîtres” qui vont nous apprendre des choses et qui en retour apprendrons de nous. On n’est pas dans une démarche élitiste mais plutôt dans l’envie de faire avancer un sujet. On retrouve par ailleurs ces valeurs dans un autre mouvement français : Fier d’être Développeur.
Tous ces principes sont rappelés, en pratique bien sûr on se base sur des méthodologies Agiles en mettant au centre des attentions l’utilisation du logiciel et la qualité du développement. Trois méthodologies sont à explorer : XP, Scrum et Kanban. Le conseil : pour savoir ce qu’il faut garder ou non d’une méthodologie, le mieux est de l’expérimenter à la lettre jusqu’à l’overdose au moins une fois puis de revenir à une application plus raisonnée.
Dans la pratique du développement, on peut commencer par appliquer les principes SOLID, mais n’oublions pas que ce n’est jamais aussi simple de coder. Il y a le contexte et l’expérience de chacun, dans tous les cas le pragmatisme est essentiel. Aller au plus simple reste le mot d’ordre, moins il y a de code moins il y aura de bug ! Si vous parvenez à faire rentrer le principe YAGNI dans votre culture d’équipe vous aurez fait un très grand pas. Autre bonne technique à adopter pour faire émerger un design de qualité : TDD. Je reprends ici le schémas de Jean-Laurent parce qu’il a le mérite d’ajouter au cycle classique de TDD un test d’acceptance. En partant comme ça, vous avez plus de chance de réussir vos premiers pas en TDD. En effet, commencez par vous poser la question sur ce que vous avez à faire : mais en fait quel est le problème que j’ai à résoudre ? Ce test d’acceptance rédigé, on suit un cycle classique TDD jusqu’à faire passer au vert ce test . Si vous commencez en TDD, cette méthode sera sans aucun doute moins déroutante. Essayez en outre de travailler avec une personne proche du métier pour écrire ce test d’acceptance puis codez en Pair Programming !
Pour finir cette keynote riche en référence Jean-Laurent insiste de nouveau sur l’entrainement :
- Le Kata, seul ou à deux, on le refait plusieurs fois en cherchant des variantes
- Le Coding Dojo qu’on fait en groupe
- Le Code Retreat, impérativement le samedi matin, et du coup qu’avec les gens ultra motivés.
Avec tous ces conseils on pouvait déjà repartir avec plein d’idées à essayer, mais il restait encore 3 sessions pratiques (et un Coding Dojo en parallèle où je ne suis pas allé). Nous avons donc enchainé sur un Kata en Pair Programming réalisé par Thomas et Bruno. Pour cela ils ont réalisé le Kata du String Calculator.
Pour commencer, les outils pour faire du TDD de façon fluide, Nfluent la librarie de Thomas, Ncrunch qui joue les tests en continu, NUnit et bien sûr ReSharper pour le refactoring. Difficile de résumer une telle séance, il faut la vivre pour relever les petits trucs qui nous font progresser. A retenir : le Pair Programming n’est pas du pépère programming, c’est une collaboration, comme des copilotes. On obtient alors un feedback ultra rapide sur ce qu’on code, on a eu plusieurs fois la preuve en live !
Pour commencer à développer, mettez le code de test et le code de production au même endroit, faites simple, sans astuce, Test as if you meant it. On progresse par “Baby Step” sans jamais casser les tests précédents. Puis vient le refactoring, la phrase du jour : Le refactoring c’est comme la respiration, c’est à intervalle régulier ! Bref une belle session à refaire entre amis, surtout que ce Kata est assez simple car bien détaillé, fait de petits pas. Ce découpage est un exemple à suivre, le découpage est le cœur même de l’agilité !
Après ce Kata, Thomas a enchaîné avec un nouveau Kata de refactoring sur du code legacy (entendez sans test), en prenant le Gilded Rose Kata. C’est là aussi une session assez compliquée à résumer, car beaucoup d’informations sont distillées en live durant le Kata. Dans les grandes lignes, il faut être un peu outillé et attaquer par un nettoyage pour voir un peu plus clair. Ensuite on va créer un harnais de tests, pour cela on va créer des tests verts (qui passent) en prenant les résultats produits par le code initial. Puis on copie le code initial qui va servir de référence et donner le bon résultat à nos tests pour pouvoir confronter notre code aux résultats initiaux. On peut utiliser le code coverage pour être “sûr” d’avoir couvert un maximum de cas. On parle alors de Golden Master Testing. David Gageot a popularisé cette méthode, et donné des bonnes pratiques pour ensuite mener le refactoring. L’idée principale est de commencer par développer au maximum le code avant le factoriser (un peu comme on faisait dans nos exercices de mathématiques au lycée :)). Ensuite on va essayer de rendre plus lisible le code en mettant tous les “if dans le même sens”, en utilisant des foreach plutôt que des for, etc. Grâce à Ncrunch, la moindre modification est testée immédiatement. Si on passe au rouge on revient en arrière pour repasser au vert avant de retoucher le code. Une fois complètement développé, il est plus facile d’identifier des “motifs” et de factoriser proprement le code. Quand celui-ci nous convient on peut commencer à créer des petits tests unitaires qui remplaceront le Golden Master. Pour ce genre de travail, le mieux est de le faire en Pair Programming, ou mieux encore en Mob Progamming. Cette session nous a fourni une multitude d’astuces et de bonnes pratiques, et a mis en évidence que les outils et leur maîtrise étaient indispensables. Si vous voulez maîtriser ReSharper & Co. faites des Kata.
Ensuite, c’est Bruno qui a pris le relais pour un Kata (le Trip Service de Sandro Mancuso) dans lequel il a essayé et réussi à poser des tests unitaires sur du code non prévu pour cela. Le premier travail est de nettoyer le pont à l’aide de ReSharper. On va essayer de ne pas changer les signatures publiques des objets. Ne jamais faire de big bang, mais faire des tests unitaires petit à petit. Il est nécessaire pour ne pas échouer d’avoir un seul but à la fois et faire des commit réguliers dès qu’un but est atteint. Si possible dans un cas concret il est préférable de faire cela avec un utilisateur pour nous aiguiller sur la compréhension du code. Durant ce Kata, Bruno nous a montré trois techniques pour rendre le code testable et casser les dépendances :
- Extract And Override : on extrait une dépendance qu’on encapsule dans une méthode virtuelle qu’on surcharge ensuite dans un objet de test qui hérite de l’objet qu’on veut tester.
- Introduce Instance Delegator : si une méthode est statique on peut l’encapsuler dans une méthode d’instance sans trop de risque et utiliser cette méthode à la place. On peut ensuite “mocker” cette méthode si besoin.
- Dependency Injection : injecter les dépendances par le constructeur.
Avec tout cela, nous voilà parés pour borner la dette technique, et envisager plus sereinement d’ajouter des fonctionnalités à l’application. Bruno a publié sa présentation sur SlideShare.
Voilà pour un résumé des 4h de présentations et Katas. Cet après-midi a en plus respecté un des principes du mouvement Software Craftsmanship : partager et apprendre ! J’espère que ce billet vous a donné envie de découvrir plus en détails ce mouvement et surtout de mettre toujours plus de qualité dans votre code. Exercez-vous, et faites des Katas !
Pour aller plus loin n’hésitez pas à consulter le site de référence. Et pour explorer encore plus ces sujets, rendez-vous dans les meetups :
