Dans l'hypothèse où l'on aurait commencé par le développement, puis écrit les tests, outre le fait qu'on prend le taureau par les cornes (on écrit la solution avant d'avoir écrit les spécifications), le risque est d'avoir conçu une solution qui ne va pas répondre à 100% des besoins, ce qui veut dire qu'on doit faire du refactoring ou qu'on accepte une couverture partielle des besoins.
Pour moi tu passe à coté. Ce n'est pas le fait de commencer par l'un ou par l'autre qui va changer quoi que ce soit. C'est le fait ta façon de communiquer avec l'utilisateur/le product owner/le client (appel le comme tu veux) qui va changer cela. Et le TDD n'aide pas vraiment à faire ça. C'est plus le BDD car il va permettre de faire valider les tests par le client (l'objectif théorique étant que ce soit le client qui écrive les tests).
Bah le TDD permet d'écrire la spec (en termes de dév, certes, mais au moins ça définit le fonctionnement). Le BDD est une extension de ça et va plus loin.
Mais globalement ce que j'essaie d'exprimer c'est ce que tu dis (avec probablement un vocabulaire plus modeste sur le sujet;)
le principe est simple : "un module = une responsabilité". Et inversement.
Si le concept est simple son application ne l'est pas vraiment. C'est quoi une responsabilité ? C'est quoi un module ? Une classe ? Une fonction ? Quelle est la granularité de tes responsabilités ? Je pense savoir faire un découpage correct et appliquer des pattern qui vont me permettre de définir les abstractions correctes entre les responsabilités, mais de là à affirmer que je produit quelque chose de bon, je ne m'avancerais pas.
Il n'y a pas de règle pour dire "granularité trop faible" ou "granularité trop importante". Ce qui compte, c'est déjà de se poser la question, et souvent naturellement on va se rendre compte que des composants sont à responsabilité multiple ou responsabilité éclatée.
Et on travaille rarement seul, donc si tu discute sur un module donné, tu vas probablement arriver à un consensus.
Enfin qu'est-ce qu'un module, bah tout dépend du niveau de vision que tu as. Ca peut être une classe, une fonction, un ensemble de classes... tout dépend des technos que tu utilises, mais globalement "plus tes composants peuvent être considérés comme des boîtes noires, mieux c'est".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pleins de remarques
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 2.
Bah le TDD permet d'écrire la spec (en termes de dév, certes, mais au moins ça définit le fonctionnement). Le BDD est une extension de ça et va plus loin.
Mais globalement ce que j'essaie d'exprimer c'est ce que tu dis (avec probablement un vocabulaire plus modeste sur le sujet;)
Il n'y a pas de règle pour dire "granularité trop faible" ou "granularité trop importante". Ce qui compte, c'est déjà de se poser la question, et souvent naturellement on va se rendre compte que des composants sont à responsabilité multiple ou responsabilité éclatée.
Et on travaille rarement seul, donc si tu discute sur un module donné, tu vas probablement arriver à un consensus.
Enfin qu'est-ce qu'un module, bah tout dépend du niveau de vision que tu as. Ca peut être une classe, une fonction, un ensemble de classes... tout dépend des technos que tu utilises, mais globalement "plus tes composants peuvent être considérés comme des boîtes noires, mieux c'est".
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo