Garder le Cap ?

[Shudrum]

Quand je développe, j'ai mon cahier à côté. Je suis un gros maniaque des ActiveBook, d'Oxford et des blocs Idéa. Quand ma mère m'a ramené ça du boulot, j'étais aux anges. Et depuis j'ai une consommation assez énorme de cahier et de bloc notes.

Je m'arrange toujours pour avoir un environnement de travail impecable. Avec toujours de quoi noter.

Mouahahahah, trop vrai ! Plutôt que me faire chier à faire des docs sur PC et tout et tout, je fais tout sur ces fameux bloc notes, et j'ai investi dans un scanner pour envoyer mes notes à mon graphiste, plus simple, plus propre, plus rapide, etc, etc, etc ...

[Anthor]

La rédaction d'une documentation est inutile pour les langages avec lesquels on peut générer une documentation à partir des sources tel PHP, Java, haXe, ...

Pour que cette documentation soit générée, il faut bien documenter quelque part, soit dans son code ! Donc outils ou pas, il faut bien le faire un jour...

[Plume]

Rédiger une documentation et taper un commentaire, c'est pas la même. Je ne t'apprendrais pas que la rédaction de commentaire est indispensable. Et ce n'est pas si lourd que ça quand c'est bien fait et que c'est fait au fur et à mesure.

[QuentinC]

A ce propos, je ne suis pas d'accord avec toi sur le fait que la créativité vient en codant. Justement, il faut la contenir au maximum et éviter de rajouter
des choses pendant qu'on code.
Selon moi, la meilleure façon est de définir au départ une version 1, une version beta avec le minimum de fonctionnalités, de décrire tous les modules
et fonctionnalités dans un cahier des charges, et de s'en tenir jusqu'à ce que cette première version soit en ligne !

C'est vrai que c'est un peu se disperser, mais la tentation est grande. C'est un pari difficile à tenir mais tu as raison, sinon on ne finit jamais. Mais ça c'est ce qui se passe encore au moment où le projet est assez neuf et qu'on bouillonne d'idées.

Un truc que je viens de voir : si je regarde mes trucs pas finis de plus près, à 5 ou 6 reprises c'était au moment de coder l'algo de combat. JE sais pas pourquoi...

[Zamentur]

Ben moi je suis pas d'accord en ce qui concerne la définition complète de ce qu'on fait avant de se mettre à coder surtout pour un projet comme un jeu en ligne.
Bien sur au départ il faut réfléchir de manière global sur ce qui va se faire, mais une fois que çà s'est fait, on peut se lancer sur une partie précise sans connaitre tous les tenant des autres parties.

Et le grand intérêt de çà c'est qu'au moins on a quelques choses de concret à la fin de la réalisation de la partie. On peut alors obtenir déjà des retours, prévoir des améliorations etc...
Puis on recommence avec d'autres implémentations de fonctionnalités qui semble les plus importantes parmi notre liste, et au bout d'un moment on finis par avoir un résultat.

Évidement il faut commencer par les choses les plus critiques, par exemple choix du framework, une super carte qu'on se demande si çà ne va pas tout faire ramer et dont tous le jeu dépend...

Et je pense que d'obtenir des choses rapidement montrable aide beaucoup du point de vue motivation, rester trop sur le papier c'est aussi prendre un risque car on a pas de retour et on peux aussi se disperser sur papier et penser des aspects inutiles qui prendront un pourcentage du temps de dev important.

Sinon pour ce qui est des multiples jeux, je n'en ai pensé que 2, et je travaille sur le deuxième depuis 5 ou 6 ans. D'ailleurs je dois dire que la v2 du deuxième inclue de nombreuses idées issues du premier jeu que j'avais imaginé. Donc j'ai pas ce problème là.

Par ailleurs, après avoir perdu de nombreuse feuille de papier ou j'ai pris des notes, j'ai choisis de les accrocher sur mon mur. Et puis je trouve çà drôle et çà fait toujours parler les gens qui viennent chez moi et permet donc d'avoir des retours.

Quand j'ai le courage je les retranscris sur le wiki si je trouve que çà en vaut la peine.

[pascal]

+1 zamentur :
Il faut trouver un équilibre dans la quantité de documentation, le niveau de description.

Décrire le jeu imaginé de A à Z puis revenir au premier module décrit et se lancer dans le code de l'inscription & du profil, c'est clairement perdre du temps.

Lister les modules dans l'ordre puis décrire et coder un module est plus productif : je fais le point précisément sur les régles de validation du formulaire d'inscription au moment de coder ce formulaire (un peu avant de coder)

Bref, une approche agile et modulaire est plus adaptée qu'écrire un pavé en détail, le réécrire et éventuellement tenter de le coder.

++

Pascal

[Colmea]

Zamentur > Je crois que ça dépend de l'expérience et des qualités de chacun.
Maintenant je sais que je suis incapable de terminer un projet si je ne m'en tient pas à une petite version définie à l'avance.
Si ce n'est pas le cas, je pars dans tous les sens. Commence un module puis un deuxième sans terminer le premier. Puis au final j'ai un demi-site avec des demi-modules et des demi-fonctionnalités. Tout est implémenté, mais rien n'est vraiment complet.
J'ai donc fait mon choix entre un gros demi-site ou un petit site complet.

[Shudrum]

Un ptit HS, mais ce tshirt n'existe pas pour rien :

[Sephi-Chan]

Il est cool.

Moi j'aime bien celui-ci :




Sephi-Chan

[Shudrum]

Ahah, excellent !