Bonjour,

Bon la question n'est pas très explicite je l'avoue donc je vais la faire en plus longue.

Je me suis mis a créer un petit tower defense en C++, j'ai donc définie quelque features dans un fichier texte (map, entité joueur, entité "maléfique") et des idées de base pour leur implémentation. De plus j'utilise SFML2 que je ne maitrise pas encore mais ça vient petit à petit.

Durant des projets tels que celui-ci (j'en ai fait à la fac par exemple), il m'est souvent arrivé de vouloir rajouter des choses à la fin (gestion d'un menu, sauvegarde de paramètre dans un fichier etc) qui n'étaient pas prévu au début par exemple.

La vu que je refait un gros projet (du moins pour moi tout seul c'est assez gros pour l'instant) j'essaye d'organiser au mieux dès le début, mais on se rend vite compte que par exemple le tableau 2D qu'on avait fait au début, ba on le transforme en 1D car finalement c'est mieux et qu'on a lu ça quelque part entre temps.

Du coup j'ai l'impression de patcher mon code toutes les séances et de ne pas avoir un plan bien définie dès le départ (alors que j'ai bien l'idée de se que je veux faire et des différentes entités à mettre en place ... par contre je ne vois qu'après coup comment les relier entre elles et/ou des problèmes de mon implémentation).


Vous vous organisez comment dans vos codes pour pas que se soit patcher 40 fois et que toutes les entités ne soit pas relié entre elles par des pointeurs de toutes sortes (j'en abuse car mettre 50 paramètres à une fonction me file de l'urticaire) ?

C'est moi qui ai un problème avec les patchs et que tout développeur fait comme cela ou alors il y a vraiment une méthode à adopter ?

Salut

ne commence pas par programmer mais écrire. Ecris ce que tu souhaites puis écris comment tu souhaites l'implémenter.
N'hésite pas à faire des schémas, des dessins même pourris sur une feuille.

Ainsi tu vas énormément clarifier tes idées.

Une autre pratique est d'écrire un premier jet, faire une pause genre 1h puis le relire. Tu verras plein de choses qui ne te plaisent pas, tu corriges.
Puis tu refais une pause, genre 24h ou plus sans penser à ton projet. Tu reviens ensuite dessus, tu relis et corriges.

Il te manquera la relecture par une personne tierce mais c'est plus difficile pour qqun qui travaillle seul.

Et enfin tu peux programmer

-
Edité par tsez 1 mai 2015 à 20:40:55

Oui mais par exemple, là j'ai un cas : je veux poser une tour et l'afficher.

Je choisis quelle implémentation ?

    Soit le joueur à une liste de tour et on affiche les tours en parcourant cette liste.
   Ou la carte à sur chaque case un enum qui indique le nom de la tour et on affiche les tours si il y en a sur la case
   Ou la carte a des case avec un pointeur vers la tour et on parcour la carte et on appel les draw de chaque tour spécifique.


Bref 3 possibilités, je choisis comment mon implémentation ? elles ont l'air a peu pret toute valide : une tour appartient à un joueur donc logique de parcourir els tour du joueur, ou alors la tour est posée sur la carte donc rebelotte c'est logique ....

Après faire l'enum sur la carte semble bancal si je veux faire une animation différente par tour etc...




La pour ma carte j'ai un enum qui définie une texture de base, un pour des détails non bloquant, et un autre pour les détail bloquant.
Vu que les détails ne sont pas animé ça passe .... le jour où j'ai une idée d'animation jrisque d'etre dans la merde jpense ... mais si jamais je ne met pas d'animation c'est clairement plus simple de faire comme ça.

-
Edité par Driiade 1 mai 2015 à 22:10:58

Pour choisir la meilleure implémenation, décris d'abord tous les objets que tu souhaites gérer. Une fois que tu auras écris ce que tu souhaites alors tu pourras réfléchir à l'implémentation.

L'idée est d'avoir une vue globale de ton projet et surtout claire. Tant que tu gardes toutes ces informations uniquement dans ta tête alors tu ne pourras pas implémenter correctement tes besoins.

Même si cela paraît contraignant d'écrire ces informations, tu verras par la suite que tu gagnes un temps fou lors de l'implémentation et surtout tu n'auras plus ces remises en cause du code qui sont si coûteuses.

-
Edité par tsez 2 mai 2015 à 10:06:40

benoit_CONSTANTIN a écrit:

Bonjour,

Bon la question n'est pas très explicite je l'avoue donc je vais la faire en plus longue.

Je me suis mis a créer un petit tower defense en C++, j'ai donc définie quelque features dans un fichier texte (map, entité joueur, entité "maléfique") et des idées de base pour leur implémentation. De plus j'utilise SFML2 que je ne maitrise pas encore mais ça vient petit à petit.

Durant des projets tels que celui-ci (j'en ai fait à la fac par exemple), il m'est souvent arrivé de vouloir rajouter des choses à la fin (gestion d'un menu, sauvegarde de paramètre dans un fichier etc) qui n'étaient pas prévu au début par exemple.

La vu que je refait un gros projet (du moins pour moi tout seul c'est assez gros pour l'instant) j'essaye d'organiser au mieux dès le début, mais on se rend vite compte que par exemple le tableau 2D qu'on avait fait au début, ba on le transforme en 1D car finalement c'est mieux et qu'on a lu ça quelque part entre temps.

Du coup j'ai l'impression de patcher mon code toutes les séances et de ne pas avoir un plan bien définie dès le départ (alors que j'ai bien l'idée de se que je veux faire et des différentes entités à mettre en place ... par contre je ne vois qu'après coup comment les relier entre elles et/ou des problèmes de mon implémentation).


Vous vous organisez comment dans vos codes pour pas que se soit patcher 40 fois et que toutes les entités ne soit pas relié entre elles par des pointeurs de toutes sortes (j'en abuse car mettre 50 paramètres à une fonction me file de l'urticaire) ?

C'est moi qui ai un problème avec les patchs et que tout développeur fait comme cela ou alors il y a vraiment une méthode à adopter ?

Il est impossible de tout écrire de A à Z sans revenir en arrière. La méthode proposée par tsez fonctionne exactement de la même façon que ce que tu fais déjà : on décrit le programme dans les grandes lignes, puis on ramifie, et éventuellement on corrige des choses qui ne nous semblent pas adaptées. Seulement, tsez te propose de faire ça sur papier parce que c'est plus simple que de coder directement en C++. Mais dans le fond ça ne change pas grand chose : concevoir une application, ça n'est pas un travail "unidirectionnel", ça demande de sans arrêt revenir à ce qu'on a déjà fait. Après, tsez a raison de te conseiller d'utiliser un papier et un crayon pour réfléchir, je ne dis pas le contraire.

Bref, comme il est impossible d'échapper à ce travail permanent de réécriture (ce que tu appelles "patch"), tu comprends bien que ton application doit se poser des questions de maintenabilité dès le début. Comme tu risques de passer ton temps à redéfinir des trucs, il est dans ton intérêt, dès le début du développement, de chercher à proposer des interfaces propres et opaques entre les différents composants de ton programme. Tu donnes l'exemple de ton tableau 2D qui devient un tableau 1D. En C++, les deux tableaux ont un type différent. Quand tu t'es rendu compte que tu devais faire ce changement, as-tu dû réécrire tous les morceaux de code qui faisaient intervenir ce tableau, même sans l'utiliser directement (juste réécrire le type, par exemple) ? Si oui, c'est un problème de conception. Il faut donc que tu apprennes à définir des modules les plus indépendants possible (on parle de "faible couplage"). Malheureusement, c'est une connaissance qui vient avec l'expérience.

Concernant ce problème, et la question des "tours" que tu nous poses, la réponse est : "ça dépend du code que tu vas écrire après". De manière générale, commence par écrire le code qui utilise tes définitions plutôt que de t'attaquer directement à ces définitions. Essaye ensuite d'appliquer des principes simples (faible couplage, "don't repeat yourself", utiliser des fonctions plutôt que des classes quand des fonctions suffisent, etc.), et ton code sera plus facile à maintenir. Oui, tu continueras de réécrire des morceaux de code au fur et à mesure que ton projet avance, mais ça sera des morceaux plus petits à chaque fois.

Et puisque tu as bien identifié que tout ceci revenait à "patcher" ton logiciel au fur et à mesure, je te conseille aussi d'utiliser un gestionnaire de versions.