Tu commence par snober la notion de MVP puis 2 de tes 3 première techniques (la 2 et la 3) en reprennent en bonne partie les principes. Il va falloir un peu plus m'expliquer :)
Technique n°4 — faire du « test-driven » sur les interfaces
[...]
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).
Ce dont tu parle c'est d'avoir des tests d’acceptante, pourquoi pas mais tu peux faire du TDD hors de ça et inversement ;)
Dans l'idée de l'agilité les patterns d'itérations et des démo aident beaucoup là dessus.
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.
Technique n°8 — Écrire un script de setup d'un environnement fonctionnel
Je le mettrais bien plus tôt dans l'ordre. Parce qu'il apporte beaucoup plus de choses que ce que tu décris. Monter en environnement en 18μs, ça peut être utile, mais bof. Avoir la maîtrise de l'environnement technique sur le quel on travail permet d'avoir des boucles de feedback qui sont rapides (et ça c'est très important pour être efficace). Ça permet de produire un environnement de test customisé. Ça donne aussi une vision (pas complète, mais ça peut montrer des signes) de la complexité architecturale de ce que t'es entrain de produire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Pleins de remarques
Posté par barmic . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 6.
Tu commence par snober la notion de MVP puis 2 de tes 3 première techniques (la 2 et la 3) en reprennent en bonne partie les principes. Il va falloir un peu plus m'expliquer :)
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).
Ce dont tu parle c'est d'avoir des tests d’acceptante, pourquoi pas mais tu peux faire du TDD hors de ça et inversement ;)
Dans l'idée de l'agilité les patterns d'itérations et des démo aident beaucoup là dessus.
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.
Je le mettrais bien plus tôt dans l'ordre. Parce qu'il apporte beaucoup plus de choses que ce que tu décris. Monter en environnement en 18μs, ça peut être utile, mais bof. Avoir la maîtrise de l'environnement technique sur le quel on travail permet d'avoir des boucles de feedback qui sont rapides (et ça c'est très important pour être efficace). Ça permet de produire un environnement de test customisé. Ça donne aussi une vision (pas complète, mais ça peut montrer des signes) de la complexité architecturale de ce que t'es entrain de produire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)