Le mardi 20 octobre s’est déroulé l’événement LearnToCraft : l’après midi du développeur craftsman.
Planning de la journée
Le mouvement Software Craftsmanship
Au cours de cette session, l’animateur, Jean-Laurent de Morlhon, a retranscrit les grandes lignes du mouvement Software Craftsmanship.
Il a pour cela mis en avant les grandes idées du mouvement en s’axant tout particulièrement sur la pratique
La pratique améliore l’expertise
La pratique, à n’en pas en douter, améliore l’expertise.
A condition de ne pas s’entraîner n’importe comment : plus on s’entraîne dans un domaine, plus on excelle dans celui-ci.
Ici, la pratique et ses bien-faits ont été mis en avant par le biais de 2 exemples :
Equipe de France de Football
Lorsque les enfants jouent au foot, ils sont généralement (en cas de sureffectif), triés afin de sélectionner les 11 meilleurs.
Lorsque les enfants commencent le foot, dès l’âge de 5 ans, les meilleurs sont très généralement ceux qui approchent de leur 6 ans : ceux nés en début d’année. A cet âge, l’écart d’une année se ressent beaucoup sur le physique.
Puis, une fois les matchs passés, lorsqu’il faut sélectionner de nouveau les jeunes, qui sont les meilleurs ?
Dans le mille, ceux qui ont déjà joué, ils sont ainsi sélectionnés de nouveau.
Après cette introduction, Jean-Laurent nous a montré le camembert qu’il a établi entre les joueurs qui sont issus du premier trimestre, du second, ainsi que du troisième et on retrouve plus de 60% des joueurs de l’équipe de France qui sont issus du premier trimestre.
Théorie des 10 000 heures en musique
Afin de mettre plus en avant la pratique et sa vertue, Jean-Laurent a pris un autre exemple en se basant sur la théorie des 10 000 heures.
Celle-ci dit qu’en passant plus ou moins 10 000 heures à pratiquer sérieusement d’un instrument, on sait jouer de celui-ci.
Il a finalement recommandé une lecture légère de plage pour les intéressés :
#/media/File:Outliers.png)
Software Craftsmanship et méthodes agiles
Le mouvement craft est étroitement lié aux méthodes agiles, cependant, les méthodes agiles se détournent souvent de la technique.
Ce qui pourrait donner, si l’on s’en limite purement aux méthodologies de gestion de projet, une bonne organisation pour produire du code legacy.
En outre, on se retrouve ainsi avec certains écarts :
Processus plus que techniques
La technique est tout aussi importante que les processus.
L’un peut difficilement aller sans l’autre, et c’est là que se place le mouvement Software Craftsmanship, afin de venir contrebalancer l’aspect purement gestion de projet afin de s’intéresser à la technique pour produire du bon code.
Du code qui réponde au besoin client, qui soit donc viable sur le moment mais également sur le terme.
Respect de l’ingénieur supérieur au respect du programmeur
Le programmeur est souvent vu comme un exécutant et il est assez fréquent que son point de vue ne soit pas vraiment pris en compte ou qu’il doive se caler sur ce qui a été vendu.
Une des parties de la responsabilité du développeur professionnel est de savoir dire non. De pouvoir discuter, expliquer pourquoi et réussir à faire des compromis afin que tout le monde puisse y gagner.
Ici, lorsque nous parlons de compromis, il ne s’agit pas de dire “oui, je ferai en sorte que cela rentre en 3 jours alors qu’il en faut 6” mais de savoir discuter et prioriser le besoin.
“En 3 jours tu ne pourras pas tout avoir, cependant, la plus grosse partie du temps restant est sur la réalisation d’une interface d’administration, si on se passe de celle-ci, on pourra terminer dans 3 jours”
Voire de définir ce qui est primordial dans les fonctionnalités de cette interface, définir ce qui est amené à changer souvent afin de savoir ce que l’on peut faire rentrer dans le périmètre sans perdre en qualité.
Comment s’entraîner
Afin de s’améliorer par la pratique, le mouvement Software Craftsmanship met en avant plusieurs techniques :
Kata (seul)
Terme japonais utilisé notamment en arts martiaux pour désigner des exercices faits de mouvements, tels que des enchaînements.
Il permet l’approfondissement de techniques mais aussi le développement de la mémorisation physique à force de répétition.
Coding Dojo (groupe)
Rencontre de plusieurs personnes qui souhaitent travailler sur un défi de programmation de façon collective.
Code Retreat (plusieurs)
Evénement de pratique intensive, généralement sur une journée complète, se focalisant sur les fondamentaux du développement logiciel et du design.
Recommandations de lecture
Introduction TDD & Pair Programming
Durant cette session, nous avons assisté à un kata réalisé en pair programming.
Le nom de ce kata était “String calculator”, accessible ici pour les curieux.
Au cours de ce live coding, les deux animateurs ont codé en pair programming, en échangeant sur ce qu’ils faisaient, ils tournaient à tour de rôle entre la personne qui écrit les tests et celle qui les fait passer, comme il est souvent préconisé de le faire dans la méthodologie TDD.
En outre, ils ont utilisé une bonne pile d’outils afin de faciliter le développement, outre l’IDE et son intelliSense de base, ils avaient :
- IDE de Microsoft
- Plugin pour VisualStudio, améliorant sensiblement l’intellisense de base, particulièrement utile pour de la refactorisation
- Framework de test unitaire pour .NET. Initialement porté depuis JUnit.
- Librairie d’assertion .NET, dont Thomas PIERRAIN, l’un des deux animateurs est l’auteur
- Permet de lancer automatiquement les tests, voire de les faire tourner en continu, ils se mettent à jour sans même avoir besoin de compiler
Coding Dojo
Durant 1h30, nous avons eu l’occasion de participer à un coding dojo.
Nous avons effectué celui-ci en pair programming et en TDD. Pour ma part, j’étais avec un développeur Java, nous avons réalisé l’exercice dans les langues de Microsoft, en .NET.
Ce dernier avait pour thème la machine à café, hébergé sur le github suivant : http://simcap.github.io/coffeemachine/
L’idée est de dire que nous faisons parti de l’équipe qui doit implémenter la logique qui se trouve entre la saisie des commandes via un pad numérique et la boisson délivrée.
Première itération
Son but est de pouvoir délivrer la boisson désirée, thé, chocolat, café, avec des sucres ou non et des touillettes en fonction de ce que nous recevons depuis le PAD.
Le message de sortie doit avoir cet aspect “T:1:0” dans le cas de la commande d’un thé avec 1 sucre et une touillette par exemple.
Seconde itération
Le business arrive, la machine à café n’est plus gratuite, il y a désormais un prix pour le thé, le café et le chocolat, respectivement 0,40€, 0,60€, 0,50€.
Il faut donc prendre en compte l’argent inséré dans la machine, vérifier si le montant est suffisant, et, s’il ne l’est pas, indiquer la somme manquante à l’utilisateur.
Troisième itération
Le temps de la refactorisation est arrivé, la machine doit désormais être capable de fabriquer du jus d’orange ainsi que de délivrer des boissons très chaudes.
Il faut donc mettre à jour les méthodes afin que l’on puisse acheter un jus d’orange pour 0,60€.
Les chocolats, cafés, thés, peuvent être servis ultra chaud, mais pas le jus d’orange, qui ne peut-être servi que frais.
Le jus d’orange ne peut également pas être servi avec du sucre.
Notre temps s’est arrêté sur cette troisième itération, cependant, il y a également deux autres itérations qui peuvent être effectuées, où il faudra par exemple, sortir des statistiques de ce qui a été commandé.
