Comment commencer à concevoir un grand système ?[fermé]

Question

On m'a dit que je serais le seul développeur derrière un nouveau système de grande envergure.Entre autres choses, je concevrai un schéma d'interface utilisateur et de base de données.

Je suis sûr que je recevrai des conseils, mais j'aimerais pouvoir les épater.Que puis-je faire en attendant pour me préparer, et que dois-je garder à l'esprit lorsque je m'assoirai devant mon ordinateur avec les spécifications ?

Quelques points à garder à l’esprit :Je suis étudiant à mon premier vrai travail de programmation.J'utiliserai Java.Nous avons déjà configuré SCM avec des tests automatisés, etc... donc les outils ne sont pas un problème.

Answer 1

Connaissez-vous beaucoup de choses sur la POO ?Si tel est le cas, examinez Spring et Hibernate pour garder votre implémentation propre et orthogonal.Si vous obtenez cela, vous devriez trouver que TDD est un bon moyen de garder votre conception compacte et allégée, d'autant plus que vous avez des « tests automatisés » opérationnels.

MISE À JOUR:En regardant la première série de réponses, je ne pourrais pas être plus en désaccord.En particulier dans l'espace Java, vous devriez trouver de nombreux mentors/ressources pour élaborer votre application avec des objets, pas une approche centrée sur la base de données.La conception d'une base de données est généralement la première étape pour les utilisateurs de Microsoft (ce que je fais quotidiennement, mais je suis dans un programme de récupération, euh, Alt.Net).Si vous restez concentré sur ce que vous devez livrer à un client et laissez votre ORM déterminer comment conserver vos objets, votre conception devrait être meilleure.

Answer 2

Cela ressemble beaucoup à mon premier emploi.Dès ma sortie de l'université, on m'a demandé de concevoir la base de données et la couche de logique métier, tandis que d'autres personnes s'occuperaient de l'interface utilisateur.Pendant ce temps, le patron regardait par-dessus mon épaule, peu disposé à lâcher ce qui était autrefois son bébé et qui était maintenant le mien, et il mettait son doigt dedans.Trois ans plus tard, les développeurs fuyaient l'entreprise et il nous restait encore X mois avant de vendre quoi que ce soit.

La grosse erreur a été d’être trop ambitieux.S'il s'agit de votre premier emploi, vous volonté fais des erreurs et toi volonté devez changer la façon dont les choses fonctionnent longtemps après que vous les ayez écrites.Nous avions toutes sortes de fonctionnalités qui rendaient le système plus compliqué qu'il ne devrait l'être, à la fois au niveau de la base de données et dans l'API qu'il présentait aux autres développeurs.En fin de compte, le tout était bien trop compliqué à gérer d’un seul coup et est mort.

Alors mon conseil :

1. Si vous n’êtes pas sûr de pouvoir entreprendre seul un travail aussi important, ne le faites pas.Parlez-en à vos employeurs et demandez-leur de trouver ou d’embaucher quelqu’un avec qui travailler et qui peut vous aider.Si des personnes doivent être ajoutées au projet, cela doit être fait au début plutôt qu'après que les choses commencent à mal tourner.

2. Réfléchissez très attentivement à l'usage du produit et résumez-le au le plus simple ensemble d'exigences auxquelles vous pouvez penser.Si les personnes qui vous donnent les spécifications ne sont pas techniques, essayez de voir au-delà de ce qu'elles ont écrit ce qui fonctionnera réellement et rapportera de l'argent.Parlez aux clients et aux vendeurs et comprenez le marché.

3. Il n'y a aucune honte à admettre que vous avez tort.S'il s'avère que l'ensemble du système doit être réécrit, parce que vous avez commis une erreur dans votre première version, il est préférable de l'admettre le plus tôt possible afin de pouvoir y accéder.En conséquence, n'essayez pas de créer une architecture capable d'anticiper toutes les éventualités possibles dans votre première version, car vous ne savez pas ce qu'est chaque éventualité et vous vous tromperez tout simplement.Écrivez une fois dans l'optique de jeter et de recommencer - vous n'êtes peut-être pas obligé de le faire, la première version peut convenir, mais admettez-le si vous le faites.

Answer 3

Je ne suis pas non plus d'accord sur le fait de commencer par la base de données.La base de données est simplement un artefact de la façon dont vos objets métier sont conservés.Je ne connais pas d'équivalent en Java, mais .Net dispose d'outils exceptionnels tels que Subsonique qui permettent à la conception de votre base de données de rester fluide au fur et à mesure que vous parcourez la conception de vos objets métier.Je dirais avant tout (avant même de décider quelles technologies introduire) concentrez-vous sur le processus et identifiez vos noms et verbes...puis construisez à partir de ces abstractions.Hé, cela fonctionne vraiment dans le « monde réel », tout comme la POO 101 vous l'a appris !

Answer 4

Avant de commencer à coder, planifiez votre schéma de base de données - tout le reste en découlera.Obtenir la base de données raisonnablement correcte dès le début vous fera gagner du temps et vous évitera des maux de tête plus tard.

Answer 5

L'essentiel est de pouvoir faire abstraction de la complexité du système pour ne pas s'y enliser dès le démarrage.

• Lisez d’abord la spécification comme une histoire (en la parcourant).Ne vous arrêtez pas à chaque exigence pour l'analyser sur-le-champ.Cela vous permettra d’avoir une image globale du système sans trop de détails.À ce stade, vous commencerez à identifier les principaux composants fonctionnels du système.Commencez à les noter (utilisez un outil de carte mentale si vous le souhaitez).

• Ensuite, prenez chaque composant et commencez à l'exploser (et à lier chaque détail aux exigences du document de spécifications).Faites cela pour tous les composants, jusqu'à ce que vous ayez couvert toutes les exigences.

• Maintenant, vous devriez commencer à examiner les relations entre les composants et s'il existe des répétitions de caractéristiques ou de fonctions entre les différents composants (que vous pouvez ensuite extraire pour créer des composants utilitaires, ou autres).À l’heure actuelle, vous auriez en tête une bonne carte détaillée de vos besoins.

• MAINTENANT, vous devriez penser à la conception de la base de données, des diagrammes ER, de la conception des classes, des DFD, du déploiement, etc.

Le problème en commençant par la dernière étape est que vous pouvez vous enliser dans la complexité de votre système sans vraiment acquérir une compréhension globale en premier lieu.

Answer 6

Je le fais dans l'autre sens.Je trouve que le faire en fonction du schéma de base de données d'abord bloque le système dans une conception basée sur les données qui est difficile à faire abstraction de la persistance.Nous essayons d'abord de concevoir des modèles de domaine et puis basez le schéma de la base de données sur ceux-ci.

Et puis il y a la conception de l’infrastructure :l'équipe doit avant tout se mettre d'accord sur des conventions sur la façon de structurer le programme.Ensuite, nous travaillons ensemble pour convenir d'abord d'une conception des fonctionnalités communes du système (par exemple, les éléments dont tout le monde a besoin comme la persistance, la journalisation, etc.).Cela devient le cadre du système.

Nous travaillons tous là-dessus ensemble avant de partager le reste des fonctionnalités entre nous.

Answer 7

D'après mon expérience, les applications Java (.NET également) qui considèrent la base de données en dernier sont très susceptibles d'avoir de mauvaises performances lorsqu'elles sont placées dans un environnement d'entreprise.Vous devez vraiment penser à votre public.Vous n'avez pas dit s'il s'agissait d'une application Web ou non.Quoi qu’il en soit, l’infrastructure sur laquelle vous mettez en œuvre est importante lorsque vous réfléchissez à la manière dont vous gérez vos données.

Quelle que soit la méthodologie que vous envisagez, la manière dont vous obtenez et sauvegardez vos données et leur impact sur les performances devraient figurer parmi vos priorités n°1.

Answer 8

Je suggère de réfléchir à la manière dont cette application sera utilisée.Comment les futurs utilisateurs l’utiliseront-ils ?Je suis sûr que vous savez au moins quelques choses sur ce que cette application doit gérer, mais mon premier conseil est de "penser à l'utilisateur et à ce dont il a besoin".

Rédigez-le sur du papier ordinaire, en pensant à l'endroit où couper le code.N'oubliez pas de ne pas mélanger la logique avec le code GUI (erreur courante).De cette façon, vous serez prêt à étendre la portée de vos applications à l'avenir aux servlets et/ou applets ou à toute autre plate-forme proposée.Divisez en couches afin que vous puissiez répondre plus rapidement aux changements importants sans tout reconstruire.Les calques ne doivent voir aucun autre calque que leurs calques voisins les plus proches.

Commencez par les véritables fonctionnalités de base.Toutes ces choses qui prennent beaucoup de temps (qui retarderont votre projet de 4 semaines) n'auront pas beaucoup d'importance pour la majorité des utilisateurs.Il peut être ajouté plus tard une fois que vous êtes sûr de pouvoir livrer à temps.

D'ailleurs.Même si cela n'a rien à voir avec le design, je voudrais juste dire que vous ne livrerez pas à temps.Faites une estimation réaliste de la consommation de temps, puis doublez-la :-) Je suppose ici que vous ne serez pas seul dans ce projet et que des gens vont et viennent au fur et à mesure de l'avancement du projet.Vous devrez peut-être former des personnes à mi-chemin du projet, certaines personnes partent en vacances/ont besoin d'une intervention chirurgicale, etc.

Answer 9

Divisez le grand système en morceaux plus petits.Et ne pensez pas que ce soit si complexe, car ce n’est généralement pas le cas.En pensant trop complexe, cela ruine simplement vos pensées et éventuellement la conception.À un moment donné, vous réalisez que vous pourriez faire la même chose plus facilement, puis vous la repensez.

Au moins, cela a été ma principale erreur de conception.

Rester simple!

Answer 10

J'ai trouvé des idées très perspicaces sur le démarrage d'un nouveau grand projet, basées sur

• bonnes pratiques communes
• Développement piloté par les tests
• et approche pragmatique

dans le livre Développement de logiciels orientés objet, guidés par des tests.

Il est encore en développement, mais les 3 premiers chapitres peuvent être ce que vous recherchez et, à mon humble avis, valent la peine d'être lus.