Warning: Trying to access array offset on value of type null in /home/clients/dc78d9bd76a9c0bea6db7e87b0d67b05/web/wp-content/themes/filmic-child/page-templates/page-header.php on line 40
Avr

 

Le 8 avril dernier c’était le Lyon Craft ! On a eu le plaisir de faire à nouveau partie de l’aventure en tant que sponsor, partenaire mais aussi en tant que participants car nos Kaïbers lyonnais ont pu assister à cette journée de talks. Pour l’occasion, on vous propose un REX de cette journée avec un condensé des sessions préférées de nos consultants présents.

 

L’architecture hexagonale autrement, une explication from the bottom-up – Julien Lenormand

Sans slide. Julien Lenormand est parti d’un problème qu’il avait rencontré dans sa boîte : ils utilisaient Bitbucket comme gestionnaire des repositories Git et ils avaient du mal à suivre et gérer le statut des PR.

Ils ont ainsi décidé de développer leur propre solution en utilisant les APIs que bitbucket mettait à leur disposition.

La session consiste à commencer à développer en live la solution (en Python, mais la conf se veut techno agnostique).

On est parti d’une solution simple (juste les repos bitbucket) pour aboutir à une solution en architecture hexagonale, facilement testable qui permettait d’exploiter plusieurs autres plateformes (github, gitlab, etc) sans pour autant casser l’objectif métier initial.

 

Le TDD : du Kata à la production – Maxime Dezette

Pas un enième kata sur TDD, une approche originale par rapport à ce qui se fait d’habitude : ça part d’une application réelle et l’objectif est d’ajouter une fonctionnalité, coder le front et le back à la fois. Donc un Kata, mais en mode Real Life !

En bonus, la finesse et le niveau de code de Maxime. Presque de l’art…

 

Mieux collaborer avec les testeurs grâce au BDD : Davy Metangmo et Edouad Mangel

Une session ludique pour illustrer la collaboration avec les testeurs grâce au Behaviour-Driven Development à travers un cas concret. On suit étape par étape la relation entre le PO, le dev et le testeur et on comprend comment tout le cycle de développement peut être amélioré juste en optimisant la manière dont les tickets sont rédigés. Un ticket / une tâche bien rédigé permet :

  • au développeur de mieux cerner le besoin, prendre en considération tous les cas de tests en utilisant les bons jeux de données,
  • au testeur de facilement tester les livrables, pouvoir facilement automatiser ses tests grâce aux éléments présents dans le ticket.

Have fun.

Une architecture pour tester votre frontend – Alexia Souvane

Dans le monde du développement, tout le monde parle de test : « Si tu n’écris pas de test, ton code ne peut pas être de qualité ». Tester unitairement son backend semble approprié car il contient une grande partie du cœur métier.

Mais est-ce aussi simple côté frontend ? Où l’on doit gérer un état, le garder synchronisé avec les données provenant de sources distantes et afficher le tout à l’utilisateur. Il y a bien quelques logiques d’affichage et transformations de données, mais les tester unitairement semble parfois difficile et ne semble pas toujours couvrir la globalité d’un comportement, de l’interaction utilisateur jusqu’à l’affichage à l’écran.

 

On a aussi beaucoup aimé le sujet de Romain Koenig qui nous parle de l’adoption du Trunk Based Dev chez Indy ou encore la présentation du biomimétisme au secours des dévs par Christophe Breheret-Girardin. On aurait pu citer tous les sujets mais voici une sélection qui devrait vous donner envie de participer à la prochaine édition du Lyon Craft.

Tous les talks sont à voir ou à revoir sur la chaîne YouTube des Software Crafters Lyon.

 

La team Kaïbee

Related Posts

Leave A Comment