Cette année, Nicolas, Romain et Xavier ont eu le plaisir d’aller à SoCraTes France. La Software Craftsmanship and Testing unconference est un forum ouvert axé sur l’artisanat logiciel. Ainsi, tous les participants sont également orateurs et aucun planning n’est prévu à l’avance.

Cette année avait la particularité de se dérouler non pas dans un mais deux châteaux !

Voici les retours sur quelques sessions que nos Zenika ont suivies :

Clean Feedback (@ToF_)

Lors de cette session, nous avons discuté autour de l’importance et la manière de donner des feedback constructifs.
Dans notre contexte, un feedback est défini comme toute réaction/retour fait en réponse à l’action de quelqu’un.
Un feedback est constructif s’il permet à la personne ayant réalisé cette action de faire au minimum aussi bien (si ce n’est mieux) la prochaine fois qu’elle fera cette action.
Étant donné qu’il s’agit de communication entre deux êtres humains, il arrive fréquemment que nous fassions des feedback non constructifs. Un feedback qui attaque la personne, par exemple, n’est pas constructif car cette personne va se braquer et ignorer le retour. Un feedback négatif qui ne propose pas de solution d’amélioration, n’est pas constructif non plus car la personne ne pourra pas faire mieux la prochaine fois.
Les conséquences des mauvais feedbacks sont bien plus importantes qu’on ne le pense au premier abord. L’ambiance se dégrade, la collaboration également et le travail réalisé perd grandement en qualité. On se retrouve alors à devoir débugger nos conversations plus que notre programme.
La communication non-violente s’est invitée régulièrement dans notre discussion. Je retiens en particulier une décomposition à réaliser lorsque l’on donne un feedback :

• Observation : quels sont les faits qui ont été observés (pas de sentiments ou de ressenti, que des choses qui ont été observées)
• Déduction : qu’est-ce que la personne qui fait ce feedback déduit de ces observations ? Cette étape ouvre la possibilité de discuter. Peut-être que la déduction est totalement fausse…
• Impact : quelle conséquence cela a ? Que faudrait-il à la place ? Cette étape ouvre également à la discussion. Peut-être que l’impact est faux, peut-être que la relation entre la déduction et l’impact est fausse…

Cette décomposition a l’avantage d’ouvrir à la discussion même si, au moment de donner le feedback, nous n’avons pas d’idée de solution. Cela permet ensuite de chercher une solution ensemble ou de donner un axe de réflexion à l’interlocuteur.
Exemple de mauvais feedback :
«Tu es toujours en retard, tu n’en as rien à cirer du projet, c’est inadmissible»
Exemple de bon feedback :
«J’observe que tu es en retard d’au moins 1 heure tous les jours depuis deux semaines. J’en déduis que le projet ne t’intéresse pas. La conséquence est que le projet sera en retard».
L’avantage de la deuxième forme (bien qu’elle ne change pas vraiment le fond), est qu’elle ouvre à discussion.

Idris (@johan_alps)

Idris est un nouveau langage de programmation qui permet de définir des types dépendants. Par exemple, il est possible de définir une méthode «addElement» qui prend un vecteur de taille n et un élément et retourne un vecteur de taille (n+1) élément(s).
Le type de retour est alors dépendant du type d’entrée puisque le vecteur de retour doit être plus grand que le vecteur en entrée d’exactement un élément.
Cette capacité de langage permet de typer beaucoup plus fortement ses programmes que ce dont on a l’habitude. Mais ce n’est là que la partie émergée de l’iceberg. En effet, cela permet également d’avoir une très forte assistance de la part de l’éditeur de code (génération du squelette de la fonction par exemple). Mais l’intérêt le plus important, est que les types dépendants permettent de prouver mathématiquement un programme (ce qui résout tous les bugs dus à l’informatique et ne laisse que les bugs de mécompréhension du problème).
Cette propriété a été démontrée notamment via le principe d’équivalence de Curry-Howard.
Si vous voulez vous en apprendre plus sur ce sujet, je vous recommande grandement de regarder la présentation «Propositions as Types» de Philip Wadler (https://www.youtube.com/watch?v=IOiZatlZtGU)
J’écrirai sous peu un article sur Idris sur ce même blog.

Rust (@ToF_)

Rust est un langage de programmation bas niveau édité par Mozilla. Lors de cette session, nous étions tous débutants en Rust. Nous sommes donc restés sur les bases de Rust mais il est important d’évoquer ce genre de session dans cet article car elles font le cœur d’une conférence SoCraTes.
En effet, il s’agit là d’une session où quelqu’un voulait découvrir quelque chose et a demandé de l’aide. Au final, tout le monde a beaucoup appris et s’est beaucoup amusé.

Nix (@selaux)

Il s’agit là d’une discussion en dehors des sessions ordinaires que j’ai eu avec Stefan qui utilise Nix dans son entreprise. Étant personnellement un utilisateur de NixOS (un Linux basé sur Nix), j’étais très intéressé par son retour d’expérience.
Nix est un gestionnaire d’environnement qui permet de reproduire un système de façon parfaitement identique sur différents postes.
L’entreprise de Stefan utilise entre autres cette capacité pour pouvoir réaliser des tests de non régression visuelle. En effet, il est garanti via Nix que toutes les machines auront exactement le même navigateur, avec les mêmes polices, la même résolution d’écran etc… Ainsi, s’il y a un changement d’un pixel, cela est forcément du au code qui a été changé.
J’écrirai un article sur Nix sur ce même blog.

Implementing DDD (@lilobase)

Arnaud a partagé son expérience de l’approche Domain-Driven Design (DDD) et expliqué comment elle peut être mise en place chez un client. DDD met l’accent sur le domaine comme modélisation en perpétuelle évolution du monde réel. Co-conçu et maintenu à la fois par l’équipe technique et le métier, celui-ci isole et encapsule l’intégralité de la logique métier dans de petits modules indépendants, facilitant le développement de systèmes à grande échelle. Cette présentation portait en particulier sur la notion d’Ubiquitous Language (définition d’un langage partagé entre le métier, les développeurs, le commerce…), les échanges avec le métier, ainsi que la notion de contexte. Le passage qui a peut-être le plus marqué les participants à la session était qu’une approche DDD est impossible sans une profonde adoption des pratiques XP. En effet, DDD nécessite une grande facilité de refactorer le code, puisque chaque itération vers une meilleure compréhension du métier et du problème à résoudre nécessite des modifications dans le domaine.

Cucumber beyond the calculator (@CedricRup)

Cédric, qui a animé SoCraTes avec ses désormais fameux ukulélés, nous a fait un retour d’expérience sur l’utilisation de Cucumber dans un projet qui a grossi jusqu’à plusieurs centaines de scénarios. Insistant bien sur le fait que la session n’était pas à propos de l’approche BDD (Behavior-Driven Development), mais à propos de Cucumber (un exemple d’outil aidant à sa mise en place), nous avons échangé ensemble sur les qualités et challenges que présente ce dernier.

Haskell 101 (@BenoitChiquet)

Il s’agissait d’une introduction au langage Haskell, sous la forme d’un kata sur le calcul d’une prime d’assurance. L’occasion pour les débutants d’avoir un premier aperçu des agréables fonctionnalités de ce langage de programmation fonctionnelle : typage fort, pattern matching, concision de la syntaxe… Le tout en TDD bien sûr !

Evolutionary Design (@adibolb)

Adi, qui était aussi le facilitateur de cette édition de SoCraTes France, a animé un workshop sur le concept d’Evolutionary Design, qui met en avant l’idée de développer un système en n’introduisant qu’un seul concept par boucle de TDD et donc en ne prenant qu’une seule décision à la fois. Dans le bowling kata par exemple, cela signifie que votre premier test ne peut pas parler à la fois de “lancer” et de “score”, et que le suivant ne peut pas introduire en surplus les notions de “joueur” et de “gagnant” en même temps. Une session qui a demandé beaucoup de réflexion et qui nous a poussé à questionner le contenu des tests que l’on écrit au quotidien.

Taking notes in a graphic way (@pascallemerrer)

A SoCraTes, on ne parle pas que de développement ! Dans cette session, Pascal a partagé avec nous un ensemble de petites techniques pour prendre des notes graphiques pendant les talks ou sur un paperboard pendant les réunions. Sans nous faire atteindre le niveau d’un vrai facilitateur graphique, nous avons quand même pu constater une nette amélioration de la qualité des prises de notes pendant les heures de conférences qui ont suivi !

TDD-BDD-DDD (@CedricRup et @w3ltraumpirat)

Cédric et Tobias ont organisé un faux kickoff de projet : avec l’approche de la fin d’année, le père Noël avait besoin d’automatiser certains de ses processus métier, et nous étions là pour l’aider ! L’occasion surtout d’apprendre par l’exemple et d’échanger au sujet de l’approche Event-Sourcing et de l’atelier d’Event-Sourcing associé, des approches Driven-Domain Design et Behavior-Driven Developement, le tout saupoudré d’un petit kata en TDD.

Perpetual Infancy (@Morendil)

En participant à cette session je m’attendais à ce qu’on parle de la perception du métier de développeur dans la population au sens large et des attitudes qui peuvent entretenir certains stéréotypes. Il n’en a rien été ! Laurent nous a présenté l’importance de la démarche de l’historien et de nombreuses anecdotes qu’il a découvertes en commençant à l’appliquer à notre métier. J’y ai par exemple découvert que le modèle Waterfall est une mauvaise interprétation de la publication de Winston Royce, qui était Agile sous certains égards ! Ou bien encore que la faible féminisation de notre métier était en partie imputable au test d’aptitude d’IBM ! Sans aucun doute une des meilleures sessions auxquelles j’ai participé.

Fruit Shop Kata (@gjambet)

Dans ce kata, le Product Owner de l’Enfer fait appel à votre équipe pour implémenter une application de caisse enregistreuse pour son magasin de vente de fruits. Facile, vous dites ? Le Product Owner de l’Enfer déploiera toute son énergie, et surtout ses mauvaises pratiques pour compliquer le plus possible votre tâche. Il ne communiquera ses besoins qu’au compte-goutte, méprisera la technique, vous interrompra sans cesse et ne se remettra jamais en question… J’ai particulièrement apprécié ce kata car il permet de montrer très simplement quel impact de mauvaises décisions et une pression permanente peuvent avoir sur la qualité d’une application. J’ai été presque surpris que mon premier réflexe ait été de m’éloigner du clavier pour consacrer mon temps et mon énergie à protéger mon binôme des interruptions du P.O de l’Enfer ! 🙂

Conclusion

Afin de garder ce billet de blog (relativement) court, seule une partie des sessions ont été présentées, la preuve :

Si vous voulez en savoir plus, une seule solution : venir l’année prochaine !