Oliver, Je pense que je suis d'accord avec toi mais je pense qu'en plus il faut connaitre les design patterns et avoir de l'expérience dans ceux-ci. Je crois que c'est grâce à ça que tu vas faire face à des questions architecturale et connaitre les solutions rapidement.
Par exemple, si tu as un formulaire complexe avec un workflow complexe, je crois que c'est un bon cas d'utilisation pour un form object et un/des services objects. Il faut également que tu saches comment faire pour faire communiquer le contrôleur, le form object, les services objects et les modèles. Une fois que tu as établi un bonne recette qui fonctionne pour toi et que tu l'a expérimenté plusieurs fois ça devient simple et tu sais comment la logique et la navigation se fait. Ceci dit, je trouve qu'il est difficile trouver une bonne architecture même en simplifiant les cas aux maximum. Je pense que c'est à ce niveau là qu'il peut être nécessaire de faire un travail d'analyse un peu plus classique avec un schéma. De plus, les schémas permettraient de mieux communiquer avec un/des collègues et avoir une meilleure réflexion. Bye! Le 15 octobre 2014 07:43, Olivier El Mekki <oelme...@gmail.com> a écrit : > > 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> 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 >>> Pour résilier votre abonnement envoyez un e-mail à l'adresse >>> railsfrance...@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...@ >>> googlegroups.com. >>> 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 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 .
