Comment débuter un projet en C++

Bonjour,
Je suis étudiante en informatique, je dois faire un projet super important pour la suite de mon cursus. j'ai fixé l'architecture de mon système, je sais globalement ce qu'il faut faire, mais j'ai du mal a commencer mon projet, je ne sais pas comment découper mon projet, par quoi commencer, comment organiser mon code. est ce que quelqu'un pourrait bien m'aider à débuter mon projet, que faut il faire pour se lancer dans le code. peut être commencer par définir les différentes classes sur une feuille de papier..?? je ne sais pas :cry:
Merci de votre aide
Anna

Il consiste en quoi, ton projet ?

1. Décris ton projet textuellement.
2. Repère les mots clés: les noms importants, les verbes importans (surtout les actions des utilisateurs)
3. Considère les noms comme étant les données que tu vas manipuler, ainsi que le comportement associés: ce sont tes types (classes et autres)
4. Considères les verbes comme les différentes actions que ton système va devoir permettre: ce sont les fonctions, les systèmes, etc.
5. Commence par bosser avec un seul simple fichier .cpp - C'est inutile d'avoir plsu d'un fichier pour un petit projet, sauf si...
6. ...si le code deviens trop large, au sens ou il y a beaucoup de différents systèmes implémentés dans le meme fichier, sépare les différents sytèmes dans différents fichiers.


Sans aller dans "l'architecture" proprement dite, commencer comme ça devrait déjà te donner un bon départ.

Salut,

Les étapes sont, en gros :

1. Effectuer une analyse fonctionnelle : déterminer les besoins que ton projet doit rencontrer, les fonctionnalités que tu en attends. Il semblerait que tu aies rempli cette étape ;)... Cependant, il faut bien être conscient que les besoins ne cessent d'évoluer : si un nouveau besoin se fait sentir, il est bon de reprendre l'analyse afin de prendre ce besoin en compte, et de voir dans quelle mesure il risque d'interférer avec les besoins déjà analysés ;)
2. Effectuer une analyse technique : sur base des besoins que ton projet doit rencontrer,
   
   • déterminer les "cas d'utilisation" de manière à avoir une "vue d'ensemble" de la manière dont les différentes parties interagissent;
   • essayer de repérer les différents "modules" (les différentes parties de ton projet qui sont susceptibles de travailler de manière plus ou moins indépendante : le "business" qui regroupera les données plus ou moins brutes, les contrôles à mettre en place, l'aspect purement "graphique", s'il y en a, ...),
   • trouver les classes dont tu auras impérativement besoin ainsi que leur responsabilité (un petit truc est de se dire que chaque sujet représente une classe en puissance et que chaque verbe représente un comportement en puissance ;)), et avoir une idée précise de la manière dont elles interagissent (en UML, on parlerait des diagrammes de séquence, de communication et d'interaction, par exemple
3. L'implémentation : Elle devrait impérativement se faire en parallèle sur deux point de vue :
   
   • Sur base des diagrammes que tu auras créés en (2), tu devrais pouvoir mettre au point une politique de tests qui, à défaut de t'assurer que tout fonctionne bien, te permettra au moins de t'assurer que tu n'arrives pas à prendre ton application en défaut. Tu peux, bien sur, commencer par un test pour les cas "qui fonctionnent" (exemple : si tu as une fonction "divide( double dividende, double diviseur), tu peux vérifier qu'elle renvoie bien 0.25 lorsque tu l'appelle avec 1.0 et 4.0), mais il faut aussi, et surtout, essayer de trouver les cas qui risquent de "tout faire sauter" (exemple, pour la meme fonction, le fait de passer 0.0 comme diviseur ;)), et,
   • parallèlement, implémenter les classes et les fonctions pour lesquelles tu as créés tes tests unitaires.
4. Les tests d'utilisation : il ne faut jamais oublier que l'utilisateur (quel qu'il soit :D) est un imbécile distrait, et qu'il essayera forcément de faire quelque chose que tu n'avais pas prévu à la base... N'hésite pas à demander à quelqu'un qui ne connait pas la structure interne de ton projet de l'utiliser, de le tester, de "jouer" avec...Il te fera très certainement un tas de remarques très pertinentes sur des besoins que tu n'avais pas envisagés, et pourra meme t'indiquer des situations dans lesquelles il arrive à prendre ton application en défaut ;) Tu peux, bien sur, t'en charger par toi meme, mais le fait est que tu seras sans doute tellement imprégné par la structure de ton projet que tu ne travailleras sans doute que de "la manière dont tu as prévu que cela se fasse" :aie:

Soit aussi conscient du fait que ce n'est pas parce que tu considères avoir "passé une étape" qu'il ne faut plus "revenir dessus".

Il arrive régulièrement que tu en viennes,à n'importe quelle étape, à te poser la question de "C'est très bien, je dois faire de telle manière, mais si je fais ainsi, que doit il se passer:question:"

Si cela arrive (et cela arrivera au moins une fois, tu peux me croire sur parole :D), il ne faut pas hésiter à reprendre les étapes qui te permettront de répondre à ta question : cela peut aller de, simplement, revoir l'algorithme d'une fonction à, carrément, intégrer cette question dans ton analyse technique, en essayant d'y apporter une réponse qui provoquera l'ajout de un ou plusieurs cas d'utilisation et donc, l'ajout d'une série de classes qu'il faudra étudier avec soin ;)

Un dernier conseil : quelle que soit l'épaisseur de ton analyse fonctionnelle, veille à travailler de manière succinte : intéresse toi à une fonctionnalité de base, et mets toute ton énergie à la faire fonctionner correctement (avec les tests unitaires qui vont avec).

Quand cette première fonctionnalité est au point, rajoutes-y une autre fonctionnalité "de base", et ainsi de suite

De cette manière, tu devrais arriver à garder quelque chose qui fonctionne quasi en permanence, et tu pourras facilement circonscrire "ce qui a tout cassé" à... la fonctionnalité que tu es occupé à mettre au point ;)

Pour le reste :

• Penses toujours que si une fonction (ou une classe) a plus d'une responsabilité, c'est sans doute qu'elle en a trop
• Penses toujours que la solution la plus simple est la moins compliquée... Heu, pardon : la solution la plus simple est toujours la meilleure (rasoir d'Okham ;))
• Veilles à respecter les grand principes de programmation ainsi que les grand piliers de la POO (si tu décides d'utiliser le paradigme OO) que sont demeter, LSP, inversion des dépendances et ségrégation des interfaces
• N'hésites pas à remettre une décision précédente en question, si tu te rends compte qu'elle te bloque dans l'évolution du projet
• Essayes de garder des fonctions les plus simples possible, d'utiliser des noms de fonctions et de variables qui donnent une idée précise de ce qu'elles font
• hévites comme la peste les classes "fourre tout", dont on s'étonnerait presque qu'elles ne fissent pas le café
• Bon courage, n'hésite pas à poser des questions plus précises ;)

Merci a tous de vos réponses. cela m'aide énormément.

Mais je crois avoir trouvé mon problème: je n'ai jamais réellement codé, j'ai codé plein de petits algo, je sais comment faire quand c'est petit comme code, mais j'ai jamais fait un gros projet, je me perd.

je n'ai jamais osé demandé de l'aide a mes collègue par peur qu'on rigole, car logiquement un étudiant en informatique doit connaitre tout ça. c'est pour ça que j'essaye les forum. et je tiens énormément à vous remercier.

comme vous l'aviez dit, je vais essayer d'aller tout doucement, commencer par définir les besoins de mon projet, identifier les différentes classes, les coder séparément, et petit à petit je ferais les liens entre mes classes.

Souhaitez moi Bonne chance,
Anna.

N'empêche qu'on ne sait toujours pas en quoi consiste ton projet. :-)

Citation:

---

Envoyé par anna0510

Mais je crois avoir trouvé mon problème: je n'ai jamais réellement codé, j'ai codé plein de petits algo, je sais comment faire quand c'est petit comme code, mais j'ai jamais fait un gros projet, je me perd.

---

L'avantage, quand on débute en programmation, c'est qu'on n'est pas en train de construire un pont ou un gratte-ciel : on a le droit de se tromper, et on peut remettre son œuvre sur le métier pour corriger le tir si on s'est trompé.

Donc, comme tu l'as dit : mets-toi à coder en te restreignant à un ou deux modules, et fais grandir ton projet étape par étape autour de cette ébauche. Tu verras que tu vas très vite obtenir des résultats intéressants.

À terme, quand tu auras plus d'expérience, il faudra bien sûr revenir sur cette façon de faire car elle introduit un effet pervers : on part sur une hypothèse de départ et, tout au long du projet et des difficultés rencontrées, on s'efforce de trouver des solutions toujours plus sales pour essayer de valider l'hypothèse de départ au lieu d'en changer. C'est une maladie qui touche même les chefs de projets les plus expérimentés.

Citation:

---

je n'ai jamais osé demandé de l'aide a mes collègue par peur qu'on rigole, car logiquement un étudiant en informatique doit connaitre tout ça.

---

Ça, c'est dommage, car c'est comme cela qu'on apprend le plus vite. Il est impossible de tout connaître en informatique : même un codeur aguerri avec 30 ans d'expérience tombera forcément sur une technologie inconnu que le stagiaire d'à côté aura vu avant lui. C'est systématique.

Citation:

---

c'est pour ça que j'essaye les forum. et je tiens énormément à vous remercier.

---

Excellente initiative.

Citation:

---

Envoyé par anna0510

Merci a tous de vos réponses. cela m'aide énormément.

Mais je crois avoir trouvé mon problème: je n'ai jamais réellement codé, j'ai codé plein de petits algo, je sais comment faire quand c'est petit comme code, mais j'ai jamais fait un gros projet, je me perd.

---

J'ai le même problème. J'en suis a 30k lignes de code dans mon projet et ca m'arrive encore.
Le truc, c'est de diviser le travail. Si tu essaies de tout prévoir, tu te perds forcément. Tu anticipes des problèmes que tu n'auras peut être jamais. Si tu as des idées globales sur l'organisation de ton projet, tant mieux, garde les dans un coin de ta tête, même si c'est flou ou incomplet.
Mais essaies de chercher dans ton projet un objectif réalisable en peu de temps, et codes le. Peu importe la suite, atteins ton objectif. Une fois que c'est fait, fixes en un nouveau, atteignable en peu de temps. Regarde le code que tu as fait jusqu'à présent, demandes toi ce qu'il faut changer. Même s'il faut tout refaire, c'est pas grave, avec l'expérience ca arriver de moins en moins. Ensuite réalise ton objectif. Puis un suivant. Et ainsi de suite jusqu'à ce que le projet soit fait.

Citation:

---

Envoyé par anna0510

je n'ai jamais osé demandé de l'aide a mes collègue par peur qu'on rigole, car logiquement un étudiant en informatique doit connaitre tout ça. c'est pour ça que j'essaye les forum.

---

Non, je crois que seule une expérience professionnelle ou sur un vrai projet permet de trouver des méthodes de travail qui te permettent d'être efficace.
D'une manière générale, la plupart des gens sont bienveillants quand on leur demande des conseils. C'est flatteur, surtout quand la question est simple et que tu peux l'expliquer facilement.
Généralement les mauvaises réactions viennent soit des cons (et donc tu leur demande plus conseil), soit du fait que tu poses des questions trop compliquées, et le gars ne peut pas dire qu'il n'a pas la réponse sans perdre la face.
Je suppose que tu es nouveau dans ton travail. Dans ce cas, passes du temps avec tes collègues, suis les fumeurs dehors, les accros au café à la machine à café... Plus vite tu apprend a connaitre les gens, plus vite tu verras à qui tu peux poser tes questions. Leur aide est précieuse, et même indispensable dans une carrière. Une fois que tu connais les gens, tu sais éviter de poser des questions aux cons, et les gens se mettent à te répondre honnêtement. Tout bénef !

Bonjour,

La théorie voudrait qu'avant de commencer à écrire un programme, il faudrait avoir fini la conception sur papier, et "avoir tout en tête". En pratique, c'est rarement le cas. A un moment, la conception sur papier devient stérile, il faut commencer à programmer, et on ne sait pas par quel bout prendre le problème. Ce n'est pas une question d'expérience, ca fait plus de vingt ans que je programme, et j'ai exactement le même problème dès que je me trouve face à un développement un peu important.

Personnellement, j'ai tendance à commencer par un aspect secondaire du programme. Il peut s'agir de la gestion de l'interface, ou des paramètres utilisateurs, ou le chargement et l'accès à une nomenclature, ou la gestion d'une fonctionnalité non centrale (mais indispensable). Je choisis généralement quelque chose que je sais déjà faire, et où d'éventuelles "erreurs de jeunesse" ne seront pas dramatiques.

Après avoir écrit quelques modules secondaires, je suis généralement prêt à attaquer le programme proprement dit, souvent avec une bien meilleure vision du problème. Egalement, ces modules vont souvent permettre des tests plus efficaces de la partie centrale.

Cette méthode indirecte n'est généralement pas celle recommandée dans les livres, où l'on propose des approches plus modélisatrices et abstraites. Son intérêt, pour moi au moins, est qu'elle me permet de sortir des "rêvasseries" qui s'installent toujours à la fin de l'étape de conception/spécification, tout en réduisant le risque de partir sur une mauvaise idée (qui plombera durablement la conception).

Francois

Bonjour,
Je tiens à remercier tout le monde, j'ai suivis en gros vos conseil, j'ai pris mon courage entre deux mains, et ça va vraiment beaucoup mieux j'avance pas a pas. j'évite de penser au temps qui me reste je me dit tant que j'avance et que j'apprend des choses c'est l'essentiel. Quant au résultat final, j’espère vraiment que j'aurais produit un truc exploitable qui me donnera des résultats.
Merci à tous
Anna

:resolu: ?
Et bienvenue sur le forum ;)