avec explosion de la combinatoire... je crois simplement que nous ne sommes pas en train de parler de la même chose.
Explosion est peut être fort, mais je suis même pas sûr. Parce que tu va aussi devoir tester l'intéraction entre un bout de ton code métier (celui de la procédure stockée avec le reste du code métier). Un cas d'usage peu impliquer tes 2 parties par exemple.
Effectivement, je ne suis pas devin. Je vais le dire autrement, cela expliquera mieux ma pensée.
L'idée ce n'est pas d'anticiper, c'est de ne pas se fermer des portes (c'est différent). C'est différent. On ne fait pas quelque chose parce qu'on sait que dans 6 mois il y aura X, on le fait parce qu'il y aura X, X', X" ou rien du tout. On présume le moins possible de ce que sera X et de ce qu'il impliquera, parce que les besoins peuvent changer beaucoup trop entre temps.
C'est plutôt une méthode Agile dans la mesure où le client est présent tout du long du processus.
(Au passage Martin Fowler est l'un des co-auteur du manifeste agile)
Les méthodes agiles expliquent clairement que ton scope correspond à une itération et que tu n'a pas à hésiter à refactorer profondément ton code. Ton scope ce n'est pas un contrat de 18 mois, mais une itération d'un mois par exemple.
Si à un instant donné, l'adaptateur peut être bien conçu (bonne synergie entre le métier et les techno) cela ne sera pas forcément le cas par la suite (et tu le disais toi même plus haut dans ton commentaire "Non, un bon choix à un moment donné n'a pas de raison de le rester.").
Le job ça va être de trouver la techno qui permet de réduire cette glue, mais tu ne fais pas ça rien. As toi de mettre en balance ce que ça va t'apporter par rapport à ce que ça te coûte (mais ça ne te demande pas de revalider le métier c'est déjà pas mal :) ).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 3.
Explosion est peut être fort, mais je suis même pas sûr. Parce que tu va aussi devoir tester l'intéraction entre un bout de ton code métier (celui de la procédure stockée avec le reste du code métier). Un cas d'usage peu impliquer tes 2 parties par exemple.
L'idée ce n'est pas d'anticiper, c'est de ne pas se fermer des portes (c'est différent). C'est différent. On ne fait pas quelque chose parce qu'on sait que dans 6 mois il y aura X, on le fait parce qu'il y aura X, X', X" ou rien du tout. On présume le moins possible de ce que sera X et de ce qu'il impliquera, parce que les besoins peuvent changer beaucoup trop entre temps.
(Au passage Martin Fowler est l'un des co-auteur du manifeste agile)
Les méthodes agiles expliquent clairement que ton scope correspond à une itération et que tu n'a pas à hésiter à refactorer profondément ton code. Ton scope ce n'est pas un contrat de 18 mois, mais une itération d'un mois par exemple.
Le job ça va être de trouver la techno qui permet de réduire cette glue, mais tu ne fais pas ça rien. As toi de mettre en balance ce que ça va t'apporter par rapport à ce que ça te coûte (mais ça ne te demande pas de revalider le métier c'est déjà pas mal :) ).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)