SnowCamp 2019

Deux piliers du Software Craftsmanship manifesto sont : des logiciels bien conçus et l'ajout constant de la valeur. Pourtant les développeurs ont tendance à subir leur premier outil : le langage de programmation, et développent pour lutter contre un outil mal choisi des pratiques telles que le TDD à l'excès... Avec le Type Driven Design, toutes une catégorie de tests peut être encodée dans votre application grâces à un système de types algébriques, et surtout vous permet de mieux raisonner votre application.
Avec la montée en puissance de langage statiquement typé et tel que F#, OCaml, Haskell, Scala, Swift, Kotlin, ReasonML, Rust, Nim, ... c'est un sujet d'actualité.

Note de l'auteur : j’ai eu l’occasion de tester ce workshop lors de l’agile tour Lille. Actuellement il est prêt en ReasonML, OCaml, Rust et Kotlin sera ajouté pour le SnowCamp.
Il est tout à fait accessible à une personne ne connaissant rien aux ADT (c’est même au final l’objectif premier de ce workshop que d’amener ce concept) et une itération 0 est même prévu pour découvrir le langage choisi pour quelqu’un qui ne le connaîtrait pas. ReasonML est le plus accessible pour quelqu’un qui ne connait aucun des langages car pose moins de problème de syntaxe.
Mais dans l’absolu quelqu’un qui souhaiterait participer au workshop pour découvrir l’un des langages proposé est aussi une bonne motivation pour participer. Lors de l’agile tour un groupe a choisi d’utiliser le temps disponible pour découvrir RUST (sûrement le moins accessible des langages proposé) et cela c’est très bien passé, je pense même qu’ils ont tiré une certaine fierté d’avoir pu mettre en œuvre certains concepts même sans aller au bout de l’exercice.
Le but est de jouer avec les systèmes de types et pas nécessairement avec la programmation fonctionnelle. L’atelier ce veux principalement orienté pour des débutants en programmation statiquement (bien

Vous allez étudier des bugs afin de comprendre les faiblesses dans le design qui a permi et facilité leur introduction. Une fois compris vous allez inventer de designs alternatifs qui rendraient impossible ou du moins peu probable leur introducition. Nous allons également chercher des faiblesses du design, où ce serait probable que l'on introduise un bug dans le futur.

En comprenant mieux puis en corrigeant la cause racine des bugs, nous tranformons les échecs de hier en force pour demain.

Le geste à répéter :

1. Identifier soit une faiblesse du design susceptible de causer un bug lorsque l'on étend le code, soit un bug existant.
2. Expliquer comment le design actuel a contribué à l'introduction du bug ou comment il risque d'y contribuer dans le futur.
3. Trouvez un design qui rend impossible ce bug ou du moins qui le rend peu probable.

Pré-requis : faire tourner un des langages du répo https://github.com/martinsson/BugsZero-Kata