2010-11-16 9 views
3

Vous vous demandez simplement comment démarrer un projet à partir d'un concept, de spécifications, de dev, etc. En cours de développement, commencez-vous par la conception d'une base de données? ou peut-être une ressource que vous savez que je peux regarder.Comment démarrer un projet

+3

C'est une question très ouverte qui variera énormément d'un projet à l'autre et d'une équipe à l'autre. Il ne peut vraiment pas y avoir de réponse définitive. Peut-être que l'un des autres sites d'échange de pile serait un meilleur ajustement pour cette question? –

+0

Je ne l'ai jamais lu mais il semble que vous pourriez être intéressé par L'Art de commencer par Guy Kawasaki - http://www.amazon.com/Art-Start-Time-Tested-Battle-Hardened-Starting/dp/ 1591840562/ref = sr_1_1? Ie = UTF8 & qid = 1289869199 & sr = 8-1 – dhable

Répondre

0

Tout dépend de ce qui a motivé la création d'un projet en premier lieu. Cela peut varier de s'asseoir et d'étaler des détenus de quelque chose qui bouillonne dans votre esprit depuis des années, ou s'asseoir et faire un prototype rapide et sale pour vous convaincre que l'idée de génie que vous aviez si simple est vraiment épineuse buisson qui vous oblige à s'asseoir et à s'étendre.

Je ne commence jamais par la conception de base de données, car c'est un détail d'implémentation. Je ne pourrais même pas vouloir utiliser une base de données. Je commence par le design fonctionnel. Qu'est-ce que je veux qu'il fasse? Pourquoi? Comment? Comment le fait-il différemment des autres approches? Est-ce que le bénéfice est suffisant pour même le faire? Vous avez eu l'idée. La conception de la mise en œuvre est abordée une fois que je sais clairement ce que je fais et, surtout, pourquoi.

0

C'est très général mais la première étape consiste toujours à comprendre et documenter ce que vous voulez que l'application fasse. Ensuite, je développe habituellement et ERD qui définit les tables nécessaires pour accomplir ces fonctions avec la structure de classe qui se trouve en face de ces tables. Une fois ces deux grandes parties terminées, la navigation est généralement fluide.

1

Commencer par la conception de base de données est en fait une grosse bête de ma part. Bien sûr, ça va pour certains projets. Des applications simples de formulaires sur données, des trucs comme ça. Mais pour quelque chose de plus complexe, tout ce qui a un «domaine» de la logique, ne commence pas avec la conception de la base de données. Commencez avec la modélisation de domaine. Si vous prenez la logique métier et la mettez dans le code, il est fort probable que les utilisateurs professionnels qui définissent le flux logique ne pensent pas en termes de données SQL ou relationnelles au repos. Ils pensent en termes d'interactions logiques de concepts concrets et abstraits. Comme l'a déclaré Eric S. Raymond, «Les structures de données intelligentes et le code bête fonctionnent mieux que l'inverse. Habituellement, quand on commence avec la conception de la base de données, on crée une structure de données "stupide" plate. Pas bête dans le sens où c'est un mauvais design, mais dans le sens où il n'y a pas de logique intégrée. C'est plat et sans dimension. Toute l'intelligence devrait aller dans le code qui l'utilise. En revanche, un modèle de domaine riche intègre directement la logique métier et les concepts dans les structures de données. Il améliore les données elles-mêmes grâce à l'intelligence d'affaires réelle, en apportant cette intelligence dans tout le domaine. Maintenant, cela ne signifie pas que vous ne devriez pas du tout penser à la persistance lors de la conception du domaine. Mais la persistance devrait être construite pour accompagner le domaine, et non l'inverse. Nilsson suggère de commencer avec le domaine et pendant le développement de celui-ci prendre des pauses pour penser et travailler sur la persistance. C'est parce que le modèle de domaine est vraiment le noyau, mais vous devrez évaluer tous les compromis sur la persistance pour rester réaliste. Aller pour une véritable persistance ignorance pourrait vous creuser dans certains trous.

+0

Bons points. Je considère que l'étape de documenter ce que l'application devrait faire, mais mon commentaire était moins formalisé. Une grosse erreur que j'ai vue à maintes reprises ne définit pas le vocabulaire et tout le monde est confus parce que différentes personnes utilisent des termes différents pour la même chose. – JOTN

+0

@JOTN: Absolument.La création d'un «langage spécifique au domaine» que tous les participants peuvent comprendre est un premier pas critique. Trop souvent, des logiciels d'entreprise sont développés qui ne font pas tout à fait ce que l'entreprise pense devoir faire. Cela met les futurs développeurs en contradiction avec les utilisateurs professionnels parce que leur travail consiste à soutenir le logiciel, et l'entreprise les met en face d'un logiciel qui n'a pas de sens. – David

Questions connexes