En tant qu’acteur du mouvement Software Craftsmanship, Zenika se devait d’être présent à la conférence NCrafts 2015. Nous ne l’avons pas regretté, les interventions étaient vraiment d’excellente qualité! Nous proposons un compte-rendu détaillé à ceux qui n’ont pas eu la chance de s’y rendre.

Event Storming

Zio Brando présente cette méthode d’analyse métier, très différente du recueil de besoins et qui utilise le concept DDD des Domain Events.
Dans une grande entreprise, la phase de recueil des besoins (requirements gathering) est souvent séquentielle:

  • Des contraintes d’emploi du temps et d’autres facteurs empêchent de réunir en même temps les responsables de chaque silo.
  • Même quand c’est possible, les réunions autour d’une table de nombreux participants sont de toute façon souvent improductives.

D’autre part un point faible du DDD est que dans la réalité, il n’existe pas d’ubiquitous language dans une grande entreprise, et pas non plus d’experts métier, à cause de la division en silos.
Les event storming permettent de pallier partiellement à ces deux problèmes, et d’aider à la conception du projet.
En effet, le goulot d’étranglement d’un projet est souvent la complexité du domaine, qui est d’autant plus difficile à appréhender à temps quand on découvre successivement la nécessité d’incorporer les préoccupations des différents intervenants du projet (les « stakeholders » métier, sécurité, logicielle, IT, ..).
Concrètement, cela se passe ainsi:

  • Tous les intervenants sont invités. Ils sont souvent réticents la première fois (peur de la perte de temps, du conflit, ..) mais sont ensuite souvent séduits par cette méthode.
  • On colle sur le mur un grand rouleau de papier. Cette méthode préconise de disposer d’un espace de modélisation illimité: On ne peut pas connaître la taille d’un problème avant d’avoir commencé à l’explorer (sur un tableau standard on ne peut dessiner qu’une douzaine d’éléments). Quand la place vient à manquer, on en revient à une communication orale, qui entraîne des aller-retour sans fin: ma préoccupation est plus importante que la tienne. Ici chacun peut ajouter ses préoccupations sur des post-it

event-storming-unlimitedspace

  • On donne à chaque participant deux marqueurs (un de rechange) et des post-its de différentes couleurs. L’idée est de ne pas perdre de temps à trouver des marqueurs qui fonctionnent, et de permettre même à ceux qui ne prennent pas la parole d’ajouter leur contribution
  • Les programmeurs et analystes doivent s’empêcher de chercher une structure prématurément, avant que tout le monde ait terminé: l’analyse sera plus pertinente en voyant tous les éléments

event-storming-phymdl
On commence par afficher les événements, de gauche à droite chronologiquement, d’où le nom de la méthode. Ceux-ci sont des participes passés: Bill Paid, Book Shipped, Customer Enrolled, …
event-storming-domainevts
L’intérêt des Domain Events réside dans:

  • Leur simplicité conceptuelle, accessible même aux participants qui ne les ont pas affichés
  • Le fait qu’ils permettent de résumer des processus complexes
  • Ils permettent déjà d’imaginer des tests de comportement: quand tel événement intervient, je dois constater que tel processus a été enclenché, ..
  • Ils font naturellement le pont vers une conception DDD

Pour ne pas oublier d’événements, il faut parfois réfléchir aux événements qui surviennent en remontant le temps: quel est le chemin qui conduit à tel événement final?
event-storming-trigger-evts
Il faut aussi penser aux événements relatifs à l’argent: quels sont les événements correspondant à un gain/une dépense/une facturation/… Pour faire réagir les plus réservés, l’organisateur peut aussi afficher des événements faux pour les faire enlever.
Cette méthode a donc l’avantage de conduire naturellement à un partage de connaissances qui sinon ne sont pas partagées en dehors de leur silo, tout en facilitant une contribution DDD.

My adventure with ELM

Après cela un intermède code-centric était bien nécessaire, je suis donc allé découvir le langage ELM présenté par Yan Cui, qui travaille pour une société britannique développant des jeux en ligne. La présentation était donc centrée sur l’implémentation de jeux dans le browser avec ELM, qui est un langage fonctionnel ressemblant très fortement à Haskell, avec quelques éléments de syntaxe de F#:
elm
Autres spécificités de ELM:

  • ELM peut être compilé vers du JS, ce qui est bien pratique pour des jeux ciblant le navigateur. Pedant son live coding, Yan avait lancé un agent elm-reactor qui recompilait automatiquement lors de changements du code
  • Des fonctions de manipulation des Signaux (ce qu’en Rx on appelerait des Observable, c’est à dire un Future à plusieurs valeurs qu’on peut observer mais aussi flatMapper etc..)
  • Des signaux « plateforme » portant sur les mouvements de la souris, les changements de la genêtre, qui sont intéressant pour développer des jeux

Il s’est très bien sorti de son live coding d’un jeu snake, qu’il avait manifestement répété de nombreuses fois (ça allait très vite). ELM n’est cependant pas encore très mature, parmi les problèmes les plus gênants signalés:

  • Les messages d’erreur incompréhensibles
  • Les migrations, une nouvelle version d’ELM pouvant brutalement casser le code existant