Tuto: Business First Development

Notes pour Barim : pourquoi le BFD n’est pas une bonné idée

• Le BFD ne vaut que si tu connais ton business et que tu as déjà des règles bien établis. Si ce n’est pas le cas, tu risques de faire des aller-retours entre le développement de la partie business et l’IHM pour adapter le comportement vis-à-vis des clients, voire même de faire des adaptations côté stockage car on n’a pas clairement défini les données manipulées.

• Quand tu pars d’un projet “from scratch”, le BFD est trop rigide et s’apparente à du dév en waterfall parce que tu dois spécifier à l’avance tes règles métiers… Or tu es en train de les apprendre/définir.

• Dans ton développement de la gestion des ateliers d’Escarcelle, tu n’as pas arrêté de faire des aller-retours entre les couches : d’abord l’IHM pour voir comment on intéragit, ensuite l’api pour le transport du client vers le serveur, puis le métier pour traiter la demande de l’api, en récupérant les données en base (dernière couche) et en appliquant les régles métiers.

“Business First Development”

1. On donne le contexte : l’environnement, les acteurs, le coeur business et l’objectif (faire du chiffre ? accroitre le nombre de prospects ? diminuer les coûts ?)

2. On décrit les besoins selon le principe du “business d’abord”. A chaque fois qu’on établit un besoin, on le remet dans le contexte du business : est ce le plus important ? Cela me permet-il d’atteindre mon objectif ? Est ce bien au coeur de mon business ? Et on ordonne les besoins !

3. On code la partie business indépendamment de tous les éléments extérieurs (stockage, IHM, …) et c’est là le point crucial du BFD. Le contexte et les besoins, priorisés par le business, nous permettent de coder le coeur de notre sytème, sans tenir compte des “détails d’implémentation”. Le coeur de notre système reste imperméable aux changements technologiques.

4. On introduit les éléments extérieurs un à un : d’abord l’IHM (c’est plus fun), ensuite le stockage (c’est plus sûr), etc. Et là aussi, c’est crucial dans l’approche BFD, les éléments extérieurs s’adaptent en fonction du business, … et non l’inverse !

Conclusion

Nous avons vu comment partir du besoin métier pour développer non pas une mais deux applications : une application en mode ligne de commande et une application en mode web.

Nous avons appliqué les principes de séparation des responsabilités et d’injection des dépendances pour rendre flexible notre architecture logicielle et permettre de réutiliser au mieux la couche métier.

Et nous avons utilisés deux technologies, Go et Svelte.

Du business au code

Je suis un utilisateur en phase d’achat d’un produit. Pour confirmer ou annuler cet achat, j’aimerai obtenir le descriptif, le poids ou volume, ainsi que le nutriscore de ce produit. J’en connais le nom et le code-barre.

• service = fournir des infos sur des produits

  • en tant qu’utilisateur
  • j’indique le code barre d’un produit
  • afin d’obtenir ses informations

• métier = gérer une base d’information produit à chaque produit correspond une fiche qui contient ses caractèristiques (nom, poids, nutriscore, etc.)

  • Search : rechercher une fiche produit
  • Add : ajouter une fiche produit
  • Check : contrôler les infos de la fiche produit
  • View : voir une fiche produit
  • Update : actualiser une fiche produit
  • Remove : supprimer une fiche produit

• Les specs non dites :

  • générer et stocker la base d’infos

  • rechercher dans ces infos le produit par une de ses propriétés (code barre)

  • vérifier la validité du code barre selon le calcul de la clé EAN13

    Calcul de la clé de contrôle EAN13

    • pour chaqu’un des 12 premiers chiffres du code de gauche à droite
    • sommer le chiffre s’il est de rang impair (le 1er, le 3eme, etc.)
    • sommer le triple du chiffre s’il est de rang pair (le 2nd, etc.)
    • calculer le reste de la division par 10
    • prendre le complément à 10 => c’est le 13ème chiffre

    exemple : 471951200288 | 9

Spécification

Développer un programme en ligne de commande pour afficher les informations d’un produit à partir du code barre passé en paramètre.

Par exemple :

infoprod 1234567890123

marque: SuperMilk
descriptioncourte: Lait de vache 1L
nutriscore: C
poids: 1
unité: litre

Réutiliser le code pour développer une application web qui permet de saisir un code barre et d’afficher les informations correspondantes.

• ressources: https://fr.openfoodfacts.org/data

Plan

1. définir les structures d’accueil des données

   • un produit
   • une liste de produits

2. développer le minimum d’opérations

   • créer un produit
   • créer une liste de produits
   • ajouter un produit dans la liste
   • rechercher un produit dans la liste par son code barre et retourner ses infos

3. développer l’infrastructure minimum

   • cli pour interroger le système : param code barre
   • alimenter la base à partir d’un fichier json

4. étendre en webapp

   • coder le serveur avec les web handlers
   • coder le client web

Draft

1. justifier le clean code pour réutiliser un max de code métier et de bien différencier ce qui est de l’implémentation et ce qui est du code métier (réutilisable)

2. essayer de mettre en évidence toutes les bonnes pratiques : tests unitaires, tests UI, clean code (séparation des responsabilités et injection des dépendances)

3. montrer l’intérêt de l’automatisation (watcher, docker, …) ou l’outil qui permet de mapper automatiquement la structure du json vers du go (https://github.com/mholt/json-to-go)

4. montrer le bout en bout : du dév au déploiement avec tous les points qu’on montre jamais (acheter une bécane en ligne, un nom de domaine, paramétrer le tout, …)