Discussion :

[M.a.n.u.]

bonjour,

je dois créer un projet en java et je me demandais comment doit on procéder car je pense qu'il y a une différence entre un exercice qui est quand même une application en soi (minuscule soit) et un projet ! bien évidemment il doit avoir une analyse sur le but du projet mais je butte sur le comportement à adopter lors d'un développement. il se déroulera en 2 parties (même si c'est idiot), le premier sera une application en mode console et la seconde en swing & awt (pour les écouteurs etc ...) j'attends vos conseils vos indices ...

Merci

[dinobogan]

Tu peux voir ce qui est mis ici http://www.developpez.net/forums/sho...d.php?t=487635
tu peux aussi réfléchir à tes propres besoins : dans ta vie de tous les jours, quel est le logiciel qui te rendrais service ? Les prof aiment bien lorsque l'appli proposée a une vraie utilité

[Pill_S]

bah écoute c'est toujours difficile à dire...

Il faut voir en fonction de la taille du projet... Actuellement, cela fait 4 mois que je travaille seul sur notre projet. Il est bientôt terminé, et n'était donc pas vraiment gigantesque... Du coup, j'ai un peu zappé toutes les phases de conception (juste modélisé la BDD).

Le plus important, c'est de vraiment bien se représenter les choses mentallement. Si mentallement tu arrives bien à modéliser le projet, alors le support papier devient moins important (pour toi). Le contraire n'est évidemment pas vrai!

Mieux vaut bien réfléchir que faire beaucoup de paperasse

[Vespasien]

Le plus important, c'est de vraiment bien se représenter les choses mentallement. Si mentallement tu arrives bien à modéliser le projet, alors le support papier devient moins important (pour toi). Le contraire n'est évidemment pas vrai!

Il y avait un gars à l'ancienne boite ou j'étais qui se représentait les choses mentalement mais jamais sur papier. Comme il documentait pas son code, que mentalement c'était loin d'être clair et que ses capacités a communiquer étaient très réduites, on étaient tous dans la m.. Mais comme précisé '(pour toi)' çà ira.
Penses bien objet, tronçonne ce que tu peux, soit logique et documente correctement au fur et à mesure. Si tu changes des structures, c'est pas grave mais re-documente. De toute manière, tu ne connaitras réellement parfaitement bien le projet et donc son analyse qu'une fois qu'il aura été terminé. Sauf si tu fais la version 4.50.

[Pill_S]

Il y avait un gars à l'ancienne boite ou j'étais qui se représentait les choses mentalement mais jamais sur papier. Comme il documentait pas son code, que mentalement c'était loin d'être clair et que ses capacités a communiquer étaient très réduites, on étaient tous dans la m..

Idem j'ai d'ailleurs pas fait long dans cette boîte

c'est sûr que pour les autres dév, ça craint un max (et je suis le premier à m'en plaindre). Mais quand on bosse seul, faire des analyses préalables et de beaux schémas, c'est pas terros... on perd beaucoup trop de temps

Généralement, je garde la doc pour la fin... Histoire d'éviter de devoir la réécrire à chaque changement d'implémentation

[M.a.n.u.]

je comprend bien ce que vous voulez dire car j'ai deja développez une application dans le cadre de mes études mais en C et donc la manière de découpé le projet est différentes je pense et c'est plus l'aspect "Comment écrire le code ou plutôt comment le découpé !" bon maintenant c'est vrai je n'ai pas retenu un sujet particulier pour mon projet c'est peut être ça aussi le problème ...

mon réel problème est comment découpé une analyse en POO ? je v y réfléchir de mon coté ... bien sur si quelqu'un à un tuyau c'est pas de refus !

[eclesia]

si je peux me permettre des conseils... malgré ma encore faible expérience :

techniquement :
- utiliser un ou des outils comme Maven/SubVersion/CVS/Mercurial/Raven ... pour le travail de groupe c'est quand meme bien mieux.

en code :
- laisse tomber les design pattern quand tu travail sur une petite structure de classes. quand c'est quelque chose qui a vocation a grossir (ou a etre implementé), la faut y reflechir. Autrement dit ne va pas appliquer un Design pattern quand tu as 3 boutons et une liste (je dis ca car on voit souvent des messages demander de l'aide sur comment appliquer tel pattern sur un truc genre calculette).

- travailler avec les Interfaces plus qu'avec des heritages.

- diviser en partie le projet, par exemple : les objects de connexion aux bases, la gestion des impressions, les interfaces utilisateurs....etc... et essayer de rendre chaque bloc indépendant.

- ne pas toujours tout mettre en public, penser au protected/private/rien pas que pour les methodes, mais pour les classes aussi. Afin de blindé le code on peut tres bien n'avoir qu'une Factory dans un Package de 30 classes, et la factory ne fournit que des objects utilisable par leur interfaces.