Discussion :

[Neolander]

Bonjour,

Tout d'abord désolé si la question a déjà été posée. Je le soupçonne fortement mais je ne voyais pas trop quels mots clés utiliser pour rechercher ça.

Je suis (très) loin d'être un programmeur professionnel, je pratique plutôt la programmation comme un loisir : j'ai une idée tordue qui me vient à l'esprit et j'ai du temps libre, donc je vais voir de quoi moi, mon pc, et mon langage on est capables... Mais j'ai un problème : j'ai beaucoup de mal à documenter précisément ce que j'ai dans la tête avant de commencer à le coder. Souvent, j'ai dans la tête quelques points de détail que je veux absolument intégrer à mon programme... Et je suis bien embêté quand il s'agit de concevoir le programme en question parce que j'arrive pas à visualiser le reste (exemple emblématique : une super idée de moteur de magie pour rpg...).

Alors en général ce que je finis par faire c'est commencer par coder les détails que je visualise bien, avec du code très sale autour pour voir si ça marche, et c'est seulement à ce moment me dire "ah mais non ce que j'ai mis autour c'est pas bien faudrait plutôt faire ça ça et ça"... Et tout noter sur un papier (ou un fichier texte) pour ensuite reprendre l'écriture à partir de zéro sur la base de mes notes.
Mais ça m'embête toujours quand je vois la perte de temps que ça représente.
En plus, c'est un exercice fatiguant parce qu'on a le code pourri qu'on a déjà fait dans la tête et faut réussir à s'en détacher pour refaire quelque chose de tout neuf. Ce qui me fait souvent abandonner des idées bien marrantes, chose que je trouve dommage

Aussi je me demande si quelqu'un ici aurait des astuces à me proposer pour échapper à ce cycle infernal...

Merci d'avance !

[souviron34]

reflechir...

Et tenter de penser logiquement...

• De quoi on dispose au debut
• Ou on veut arriver
• Par quoi/par ou il serait souhaitable de passer

[hed62]

Un bonne manière de procéder serait de suivre une méthode comme Unified Process (UP), et/ou un peu d'ExtremProgramming (XP).

UP te donne une méthode, un cadre dans lequel tu dois rentrer pour concevoir ton programme. Par exemple, "on fait d'abord les Use case, puis les diagrammes de séquences simplifiés, etc."

L'XP, quant à lui, est une méthode beaucoup plus "agile", dont voici quelques éléments : on définit une fonctionnalité que l'on sait pouvoir réaliser en très peu de temps. On la documente un peu (diagramme de classe+séquence) pour s'assurer que ca tient la route, et la réalise. Une fois qu'elle est faite, on la fait bien. Une fois que c'est bien fait, on le fait mieux. Puisque la fonctionnalité était petite, cela n'a pas pris trop de temps, et on est content du résultat. Ensuite on ajoute une autre fonctionnalité, et ainsi de suite.

En combinant les deux, tu pourrais te donner un objectif petit ("avoir un personnage avec une réserve de mana et de vie, un sort de soin, et le personnage lance le sort") et embrayer sur UP pour avoir un cadre. Ca devrait prendre un certain temps, court, pour réaliser cela. Une fois que ca marche en une classe, on rend cela plus beau, on regarde si il n'y aurait pas des design pattern pour améliorer la souplesse, l'extensibilité, etc...

Si tu as des quesitons, n'hésites pas

[Neolander]

Merci beaucoup...

Je suis pas tout à fait sûr d'avoir bien compris en quoi l'UP ça consiste, par contre...

Si j'ai bien suivi, il faut... (avec des exemples de RPG pour rester là-dessus, on change pas un exemple efficace ^^)

=> Partir de ce qu'on veut faire et des tristes contraintes des machines réelles (ex du hack n slash : "je veux que le pj lance des boules de feu d'1m qui explosent tout. J'ai un pc courant niveau puissance et le programme se désigne à des non-geeks niveau ergonomie")
=> Analyser ça pour en tirer une architecture (ex : boule de feu d'1m => magie. tout exploser => physique. pj = joueur => personnage. Il faut donc créer quelque chose contenant de la magie, une gestion de la physique, et des personnages.
Pour celà nous aurons besoin d'un environnement. En étudiant les relations entre tout ça on peut créer un joli diagramme pour que ce soit plus facile à visualiser (ci-joint)
=> Concevoir la structure : Une fois qu'on a traité comme ça tous les besoins, on part de chaque élément de notre architecture et des contraintes qu'on a dessus (ex : la magie doit permettre la boule de feu) et on essaye de voir comment un programme pourrait gérer ça en modélisant chaque élément. (ex : la force en newtons à l'épicentre, l'atténuation avec la distance, les chances de mettre le feu à un objet inflammable, et la couleur des flammes suffisent à définir une bonne fireball)
=> Implémenter tout ça : Tout ceci étant au point, on commence à coder tout ça en sifflottant, et en gardant à l'esprit la Grande Règle de la Programmation : "Du premier Coup jamais Ca ne Marchera" => tester souvent et rendre facile à débugger
=> Tester : Trouver des gens accommodants qui ont pas peur de se faire potentiellement formater leur disque dur par un code instable et leur offrir généreusement son oeuvre magistrale avec pour mission de faire ce qu'ils veulent avec, et recenser les plaintes pour non-fonctionnement

[hed62]

C'est un peu le principe. Sachant que si tu reste en UP 'pur', tu va concevoir intégralement de cette manière, sans (ou presque) rien coder avant d'avoir exploré tous les aspects de ton futur programme.

La petite touche d'XP, ce serait de procéder ainsi :

Tu conçois les aspects de personnages et d'environnement, en disant qu'un personnage évolue dans un environnement.

Tu code ça, jusqu'à ce que ce soit propre.

Tu as une version light d'un tamagotchi, tu es content (ou pas :-p )

Tu concois les aspects de tes sorts, en disant qu'un personnage possède et peux lancer des sorts (gratuitement et sans effet autre que visuel par exemple)

Tu code ça, jusqu'à ce que ce soit propre.

etc....

[hed62]

Pour l'UP, et les autres méthodes : http://www.developpez.net/forums/sho...d.php?t=499636

[Neolander]

Oui... J'ai vu ce forum un peu tard... et me suis dit que j'aurais peut-être dû poster dedans dès le départ

En tous cas encore un grand , étant aussi bête que mon ordinateur j'adore avoir un algorithme pas compliqué dans la tête que je peux suivre sans me poser de questions

[gKsam]

J'ai une application php5 basée sur le modèle MVC. (pas mal pompée sur le fonctionnement de RubyOnRails)

Elle fonctionne (pour l'instant) pas trop mal. J'ai encore pas mal de boulot, mais j'aimerai faire partager ce travail avec les autres. Pour faire partager un travail, il vaut mieux que cela soit bien fait et documenté.

j'ai de bonnes notions d'UML (autodidacte). Mais c'est vrai que je pêche pas mal sur le déroulement d'un projet.

Je vais donc voir ce que donne l'XP. Car l'UML c'est bien. Mais au niveau de la gestion du projet je trouve que c'est un peu lourd.

Bon allé, au boulot

[hed62]

Car l'UML c'est bien. Mais au niveau de la gestion du projet je trouve que c'est un peu lourd.

Rien à voir entre UML et la gestion de projet. UML n'est jamais qu'un langage, qui permet donc de s'exprimer. Par contre, les méthodes de travail, comme XP ou UP, là, on grandement à voir avec la gestion de projet.

UML n'est pas lourd, puisqu'il n'impose rien d'autre qu'une manière de parler : il n'impose pas de faire des dossier, des réunions, etc...

En ce qui concerne la rétro documentation, inutile de te pencher trop sur la gestion de projet, puisque le projet semble déjà bien avancé. PAr contre, oui tu peut regarder l'organisation de la documentation des différentes méthodes, et choisir la mieux adaptés à ton problème.