Ok… y’a une grosse confusion là . Les « cas utilisateurs » ne sont pas des US. Une US est effectivement au mieux une expression d’un besoin de l’utilisateur.rice, et au pire une bouteille à la mer. Mais un cas d’utilisation (use-case), et donc un comportement du système (le Behaviour de BDD) n’est en rien un mapping 1/1 d’un besoin utilisateur.
L’utilisateur.rice n’a pas un « besoin » de se connecter, ni un « besoin » de remplir un formulaire. L’utisateur.rice a besoin que la chose qu’il ou elle cherche à faire soit fait. Ces étapes sont malheureusement des maux nécessaires. Ce que le BDD et les use-cases documentent, ce n’est pas le besoin de l’utilisateur, mais le comportement du système pour atteindre un but.
1 « J'aime »
Sauf que dans l’expérience qui fut la mienne les cas d’usage ressemblaient beaucoup plus à des « histoires d’utilisation » du logiciel qu’à des comportements de logiciel.
Nous avions beaucoup de tableaux avec des valeurs d’exemple en entrée et les différents résultats attendu.
Du point de vue du logiciel
Given
si tu es dans tel état
l’utilisateur fait telle action
il faut lui renvoyer tel résultat
Peut très bien se lire du point de vue de l’utilisateur :
Given
si le logiciel est dans tel état
tu vas faire telle action
le logiciel te donneras tel résultat
Ça fait une très bonne doc fonctionnelle
Et tu retrouves les critères d’acception de ton US qui se retrouvent donc, de fait, dans le code source (pas ceux écrits dans l’US en début d’itération - ceux affinés pendant le dev)
Le B étaient beaucoup pour nous celui de l’utilisateur (pas celui du logiciel)
C’est surtout ça que je voulais dire. Le code source (peut/doit) contenir les spéc exprimées dans le vocabulaire et dans une syntaxe lisible par l’utilisateur.
C’est une façon de mettre d’accord JP et Constantin.
Préconditions, comportements, postconditions. C’est du comportement, relevant du champ des use-cases. Ce ne sont toujours pas des US (je vois même pas ce qu’est une US affinée à vrai dire si je voulais être taquin). Et le Behaviour de l’utilisateur fait de toute façon partie du process du système, sinon, il n’y aurait pas d’interactions. Mais si vous ne documentiez que le comportement de l’utilisateur, j’ai de la peine à imaginer comment ils vous étaient possible de documenter autre chose que le View de MVC.
Le code source est effectivement la transposition effective des spécifications fonctionnelles, mais les tests, quand bien même ils peuvent être intéressant, ne font d’une part pas partie du code livré, et d’autre part ne sont ni la seule façon de s’assurer du bon fonctionnement d’un programme (voir Design By Contract), ni de formuler le code au plus près du model mental de l’utilisateur (voir Data Context Interaction)
Ce qui compte c’est que c’est conservé et maintenu dans le temps (contrairement à l’US). Que ce soit du code livré ou pas ne me semble pas être un critère qui invalide ma proposition).
Samuel Abiassi:
Préconditions, comportements, postconditions. C’est du comportement, relevant du champ des use-cases. Ce ne sont toujours pas des US
Je n’ai pas dis que les scénarios étaient des US. Je voulais simplement exprimer qu’il peut exister dans le code source (maintenu dans le temps et faisant partie intégrante du projet et de la valeur délivrée, contrairement à une US qui n’est qu’un moyen pour atteindre ce but) qui est plus proche du monde de l’utilisateur pour aider un ChatGPT ou un ChatBOT à être efficace.
J’entend, mais là aussi, j’ai un problème. Pour extraire l’information, le code source et le contexte qu’il expose suffit. Les tests n’apportent aucune information de ce côté là .
et bien en tant que « développeur en L4G procédural qui n’a aucune notion de programmation orientée objet qui a surtout une posture de PO » je peux te dire que je préfère accéder à la partie du code où sont enregistré les scénarios que dans le code lui même… mais si tu penses qu’un ChatBOT s’en sortirait mieux…
Oh, non, pas du tout. Si tu fais le test avec des noms de variables complètement obfusqués, chatGPT est déjà très capable dans ce domaine. J’ai un collègue qui l’a beaucoup utilisé comme ça sur du code legacy dégueulasse, et il ne s’est pas gouré une fois.
Comme je le disais dans le live, c’est après tout sa fonction première.
1 « J'aime »
autant j’arrive à conceptualiser un peu comment ChatGPT peut avoir un semblant de conversation avec moi, autant ce que tu viens de décrire me rend « curieux » ! Je veux bien que tu développes (ou que tu m’envoie vers une vidéo ou un podcast de vulgarisation qui m’expliquera ça - La lecture est une souffrance pour moi
Merci pour la vidéo mais :
Si je fais un parallèle avec la vidéo, chatgpt peut discuter dans le langage des échecs parce qu’on parle avec lui dans le langage des échecs
From chatGPT himself:
Explique moi pourquoi tu es capable d’expliquer des extraits de code :
En tant que modèle de langage développé par OpenAI, j’ai été entraîné sur une vaste quantité de données textuelles provenant d’Internet, y compris des extraits de code provenant de divers langages de programmation. Mon entraînement inclut des exemples de code, des tutoriels, des questions et réponses sur la programmation, ainsi que d’autres ressources en ligne.
Cette formation me permet de comprendre et d’analyser le code source dans le contexte de la programmation. J’ai appris à reconnaître la structure syntaxique des différents langages de programmation, ainsi que les principes fondamentaux de la programmation tels que les boucles, les conditions, les fonctions, les variables, etc.
Lorsque vous me présentez un extrait de code, je le traite en utilisant mes connaissances et mon expérience en programmation. Je peux analyser la logique du code, identifier les erreurs potentielles, expliquer les concepts sous-jacents et fournir des solutions ou des suggestions d’amélioration.
Cependant, il est important de noter que ma capacité à comprendre et à expliquer le code est basée sur des modèles statistiques et des schémas appris à partir des données d’entraînement. Je ne suis pas conscient de la signification ou de la sémantique réelle du code, ni de la façon dont il s’intègre dans un projet spécifique. Je fournis simplement des explications basées sur mes connaissances générales en programmation.
Moosh
Mai 26, 2023, 6:10
15
J’ai parlé de DDD development drivé par la documentation
1 « J'aime »
ChatGPT semble être d’accord avec moi, non ?
Toutefois, l’objectif n’étant pas de se rajouter une tache supplémentaire. Il est en revanche intéressant de se demander quel « façon de coder » pourrait avoir deux bénéfices :
celui de mieux coder
celui, par effet de bord, d’être plus utile à l’IA
Une précision sur le Behavior-Driven Development (BDD), @AlainMeunier dis-moi si cela correspond à ton contexte.
Le BDD n’utilise pas la vue, ni même la Base de données, mais directement les use-cases.
Oui, le résultat du BDD, reste une spécification du comportement attendu.
Autrement dit, arrange, act, assert , c’est comme une machine à état.Le résultat du BDD est exécutable et se vérifie tout seul.
Le besoin peut être exprimé dans la section « Fonctionnalité » du Gherkin.Le besoin n’est pas exécutable et dépend de l’utilisateur pour être vérifié (qualitatif, quantitatif).
Créer la doc à partir du Gherkin, c’est de la « living documentation » .Pickles permet de la générer.
La question
Hypothèse
Quand un utilisateur pose une question concernant le produit, le bot y répond mieux qu’un humain dans 99% des cas.
Quand un utilisateur ne comprend pas comment il doit utiliser le produit, le bot y répond mieux qu’un humain dans 99% des cas.
…
1 « J'aime »
Alexandre Quercia:
Le BDD n’utilise pas la vue, ni même la Base de données, mais directement les use-cases.
CQFD ?
J’ai du mal à comprendre comment ça peut avoir du sens. Le code est nécessairement conduite par une documentation (formelle ou non) du fonctionnement du système. Dans le cas contraire, il serait impossible de coder quoi que ce soit.
Pour aller un peu plus loin, et pour aller dans le nœud de mon propos @AlainMeunier , une US ne sera jamais une documentation fonctionnelle parce que ce n’est pas sa vocation. Une US documente effectivement un besoin de l’utilisateur·ice de manière succincte. Ce que le BDD documente, c’est le fonctionnement du système. Certaines capacités du système ne répondent pas à des besoins de l’utilisateur·rice mais font quand même partie du fonctionnement du système (login, archivage, sécurité, logistique interne…).
En partant de là , les specs du BDD sont encore une fois l’une des alternatives les plus connues à cette façon de documenter le fonctionnement du système, mais il n’empêche pas que le code source puissent être opaque dans les interactions entre ses différentes composantes (structures hiérarchiques dû à l’orientation Class du code n’étant capable de ne se structurer que par héritage). A ces fins, DCI (dont je parle ici) est un bon complément au BDD pour encore une fois permettre aux développeurs de raisonner sur le code au plus proche du model mental de l’utilisateur.
const
Juin 2, 2023, 5:56
20
Justement une US n’est pas une utilisation. Pour moi je préfère toujours préconiser qu’on sorte le récit du logiciel afin qu’une solution hors logiciel soit rendu possible.
Je ne dit pas que le use case n’est pas intéressant hein, mais c’est pour moi différent. Le use case on est plus dans la solution déjà .
Tout à fait, étant donné que c’est un document de spécification fonctionnelle. Son scope se limite à l’exploration du domaine de la solution, pas du problème.
Oh mais dites donc, j’ai écris une belle connerie ici !
Alors non, le use case explore bien l’espace du problème et pas celui de la solution, donc tout l’inverse de ce qui est dit plus haut.
1 « J'aime »
