> En gros vous faites de la BDD Oui, mais je préfère éviter de l'exprimer de manière définissante, parce que la technique de test a vite fait de devenir une fin plus qu'un moyen. Je préfère dire que nous allons du général vers le spécifique (le contraire de ça étant de penser d'abord une structure de base de donnée, comme c'est trop souvent le cas avec uml, et rajouter les couches successives, pour finalement s'apercevoir que la structure de base ne correspond pas à ce qu'on veut obtenir).
> Je pensais surtout quand les cas deviennent plus complexe. Par > exemple, j'ai un formulaire complexe qui, à la sauvegarde, active un > workflow avec l'envoi de plusieurs courriels, le changement de selon > certaines règles, envoyer des notifications sur Twitter et Facebook, > etc. Si le cas est plus complexe, alors il faut l'analyser pour le réduire en plusieurs problèmes simples :) Je ne peux pas me prononcer avec exactitude sur ton exemple parce que je ne connais pas la nature de tes mails et notifications, mais il est vraisemblable que tu puisses analyser le problème en trois parties : l'interface web, les notifications par mail et les notification via api (il y a probablement une analyse plus efficace à faire en fonction de ce qu'est "le workflow"). Si tu traites chacun de ces points de manière isolée, ce ne sont plus des problèmes complexes. On Wednesday, October 15, 2014 12:37:34 PM UTC+2, Guirec Corbel wrote: > > Bonjour, > En gros vous faites de la BDD. Je pensais surtout quand les cas deviennent > plus complexe. Par exemple, j'ai un formulaire complexe qui, à la > sauvegarde, active un workflow avec l'envoi de plusieurs courriels, le > changement de selon certaines règles, envoyer des notifications sur Twitter > et Facebook, etc. > > Dans cas là, est-ce qu'on peut encore ce fier au caractère naturel du BDD? > Ça fait quand même du bien de réfléchir avec des graphiques. Si on regarde > des livres comme POODR, de Sandy Metz, il y a des graphiques qui expliquent > correctement et ça fait du bien pour avoir un aperçu visuel rapide. > > Qu'en pensez vous? > > Bye, > Guirec. > > Le 15 octobre 2014 04:52, Olivier El Mekki <oelm...@gmail.com > <javascript:>> a écrit : > >> Nous sommes d'accord que tu parles ici de documents purement destinés >> aux développeurs ? >> >> Personnellement, mon premier niveau d'analyse consiste à réduire la >> tâche en autant de sous features que possible : il faut des tâches à >> échelle humaine. Cela passe par de la pure réflexion, sans outil >> particulier. Quelles sont les parties qui composent cette tâche ? >> Qu'est-ce qui peut faire sens tout seul ? >> >> Une fois fait, je déduis les spécifications purement sur la base du >> résultat escompté : la feature doit permettre de faire ci, ce qui >> implique que telle autre feature doit prendre en compte que ça, et une >> fois que si se produit, ça doit survenir derrière. Mon principal outil >> ici est ... les issues github :) (enfin gitlab, mais c'est pareil). Si >> aucun design n'a été produit, je fais un rapide mockup dans mon browser >> en modifiant une page existante avec l'inspector chrome, afin de fournir >> dans l'issue un screenshot du résultat attendu. >> >> Ensuite, le développeur qui prend l'issue "développe", au sens >> littéraire ou philosophique : il prend une idée abstraite et en déduis >> les conséquences immédiates, puis prend chacune de ces conséquences et en >> déduis les conséquences immédiates, jusqu'à arriver au dernier niveau de >> détail, qui est l'architecture finale. >> >> Concrêtement, ça veut dire qu'il implémente d'abord les features spec en >> décrivant ce qu'il doit se passer. Une fois fait, il écrit ce qui sera >> la base de la view et répond aux attentes de la feature spec (qui ne >> peut pas être exécutée à ce point, mais indique tout ce dont on a >> besoin). L'écriture de la vue indique ce que le controller doit fournir, >> ce qui permet l'écriture des specs de controller, ce qui permet >> l'écriture du controller, ce qui indique ce que le model doit fournir, >> ce qui permet d'écrire les specs du modèle, puis le modèle, et enfin la >> structure de la db. >> >> C'est un processus naturel qui s'applique bien à la réactivité >> nécessaire de l'environement startup, je ne sais pas si ce serait >> applicable dans une relation intervenant / client (je faisais signer des >> user stories impératives, à l'époque où j'étais freelance, donc c'était >> mon outil principal d'architecturage, mais le "développement" restait >> le même). >> >> >> On Monday, October 13, 2014 4:37:06 PM UTC+2, Guirec Corbel wrote: >> >>> Bonjour, >>> >>> J'aimerai savoir avec quels outils vous faites vos analyses. Comme >>> beaucoup, à l'école, j'ai appris l'UML et les MCD mais je trouve ces >>> outils trop lourd. J'aime bien faire des scénarios et des wireframes >>> pour décrire les besoins du client mais ça ne décrit pas l'architecture >>> à adopter. Je pense que j'aurais plutôt tendance à faire des schémas sur >>> un tableau blanc ou sur une feuille de papier et a m'adapter au fil du >>> temps. >>> >>> Et vous, vous faites comment? >>> >> -- >> -- >> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" >> de Google Groups. >> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse >> rails...@googlegroups.com <javascript:> >> Pour résilier votre abonnement envoyez un e-mail à l'adresse >> railsfrance...@googlegroups.com <javascript:> >> --- >> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes >> "Railsfrance". >> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le >> concernant, envoyez un e-mail à l'adresse railsfrance...@googlegroups.com >> <javascript:>. >> Pour obtenir davantage d'options, consultez la page >> https://groups.google.com/d/optout. >> > > -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@googlegroups.com Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscr...@googlegroups.com --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse railsfrance+unsubscr...@googlegroups.com. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
