programmation évolutive sans bugs ?

[keke]

Bonjour,

Un atelier s'est ouvert en janvier dernier intéressant un certain nombre de créateurs de jeu en herbe. Le thème était "Donner une existence légale à son jeu". J'y étais ^^.

Ben dans quelques jours, le 28 février 2009 à 15h00 un nouvel atelier va avoir lieu : "Techniques de programmation pour faire évoluer un jeu dans le temps sans générer de bugs"

Même lieux, sujet différent, intervenant différent.

"Ces ateliers sont entièrement gratuits. Ils se déroulent sur Paris, dans les locaux de la société Aziluth."

Bref, moi j'ai trouvé le moyen de m'y rendre. Je serais moins chargé que la dernière fois ;-) et je serais ravis en plus de rencontrer ceux qui y étaient la dernière fois, mais avec qui j'avais pas eu l'occasion de discuter ^^.

Kéké
PS : plus d'info ici

[Mycroft]

Je comprends rien à la question ni aux items.

[pascal]

pas seulement les tests unitaires, il faut aussi de la méthodologie et des outils. et un jeu.

A+

Pascal

[pascal]

un truc qui marche bien, c'est résoudre les bugs avant d'en ajouter de nouveaux.

A+

Pascal

[keke]

Je comprends rien à la question ni aux items.

Coucou Mycroft ^^,

Pour expliquer la question (on est toujours limité en taille dans une question). Quand tu as finalisé ton premier jeu, tu as parfois (moi c'est souvent) envie de l'améliorer : Rajouter des fonctionnalités, rajouter des dessins, des sons, du roleplay.

Lorsque ça y ai, tu as finalisé ta nouvelle évolution, il faut vérifier qu'elle fonctionne .... mais ce n'est pas tout. Il faut aussi vérifier que le reste fonctionne au moins aussi bien qu'avant (cas de non-regression).
Par ailleurs, si tu es plusieurs à développer il faut à un moment réunir tous les différents travaux. Parfois certaines fonctions ont été modifiées à leur manière par différents codeurs ce qui peut entrainer quelques bugs ( cas de recoupement)
Quand tu as tous les éléments en main qui sont testés, tu dois modifier ton serveur. On appelle ça "patch", "mise en prod", "mise en service" ... Et parfois, tu oublies une modification (BDD ou fichier) ... (cas de mise en service)

Tout ces cas (et bien d'autres) peuvent générer des bugs ... appelé des bugs de versionning.

Cet atelier semble proposer des méthodes pour éviter quelques écueils ... cela me permettra aussi d'exposer ma méthode de travail au Tokken auprès d'autres concepteurs de jeux pour voir si cette méthode leur semble efficace. Peut-être que l'on parviendra à me démontrer des failles dans ma méthode ?

- Les Test Unitaires et bien évidement la seule et unique réel solution au problème.

- Les Tests Unitaires ne garantissent pas aucun bug bien entendu.

Me semble que ces phrases ne s'appliquent pas à tous les cas. La notion de tests unitaires comprend-t-elle aussi la recherche de l'exhaustivité des tests et le listing via cahier de test ? Au bout d'un moment, n'y a-t-il pas trop de tests récurrents et plus aucune recherche de tests pertinents ?
A mon boulot, j'ai parfois à jouer un cahier de test de 360 pages avec minimum 20 tests par pages. Bien évidement je ne le jouerais pas systématiquement à chaque évolution ^^. Il me faudrait plus d'un mois pour le jouer (évaluation rapide car je ne l'ai jamais fais) alors que j'ai 2 à 3 évolutions par mois.

kéké, conscient de laisser des pistes pouvant amener à des contres-argumentations.

[Mycroft]

C'était un peu ironique parce que les items sont pas vraiment des solutions, et sont des réponses un peu naïves. C'est juste légérement orienté .

[pascal]

A mon boulot, j'ai parfois à jouer un cahier de test de 360 pages avec minimum 20 tests par pages. Bien évidement je ne le jouerais pas systématiquement à chaque évolution ^^. Il me faudrait plus d'un mois pour le jouer (évaluation rapide car je ne l'ai jamais fais) alors que j'ai 2 à 3 évolutions par mois.

comment marchent ces tests ? peux tu les lancer automatiquement ou pas ?

A+

Pascal

[P0ulp0r]

D'après une conférence qu'on a eu, la pluspart du temps ces tests se passent la nuit.
Cela permet d'éviter de surcharger le serveur pendant que les personnes travaillent dessus et c'est entièrement automatisé. Après les dev reçoivent un mail de compte rendu des tests avec une hiérarchie des erreurs.

C'est l'une des manières, il doit sûrement en exister d'autres et peut être que certains ne sont pas automatisés

[keke]

Sur les techno que j'utilise, il n'y a pas d'automatisation. (forms 6i)
Ici, on fait le choix de tester les éléments que l'on souhaite, et le reste passe à lasse.

C'était un peu ironique parce que les items sont pas vraiment des solutions, et sont des réponses un peu naïves. C'est juste légérement orienté .

Oui, orienté dans le sens remise en question. Pensez-vous tout connaitre sur le sujet ? Si non, l'atelier semble particulièrement intéressant. Le fait que les questions et les réponses soient naïves font que les gens y répondent facilement. Peut m'importe les réponses en définitive car le questionnaire à pour intérêt de VOUS faire poser la question. C'est une des formes de rhétoriques adaptés au modèle forum, avec pour synthèse le message : Allez faire un tour à l'atelier ; au pire vous vous ferez des copains et vous apprendrez des trucs utiles pour vos projets personnels et/ou professionnels ; en plus c'est gratuit.

Après, comme toutes questions rhétoriques, si ça n'intéresse pas les gens, ben la discussion s'arrête là. Y'a aucune obligation à y assister, ni morale, ni religieuse, ni physique, ni financière, ni intellectuelle, ...

Maintenant sur la forme, la présentation ne concerne que moi ^^. Vaux mieux débattre sur le fond du sujet non ?

Mycroft > Si tu travailles à plusieurs sur du code, utilises-tu du SVN ? comment procède-tu au niveau des merges ? combien de mise en prod pratiques-tu annuellement ou mensuellement ? sous quelle forme ? quid du G0R0C0 ? etc.

Et ça pourrait-être bien de se préparer des questions pour dans 2 jours ^^.
Et sinon, qui pense y aller ?

Kéké

[Blarg]

Dommage qu'il n'y a pas d'atelier tel que celui-ci au Québec (à ce que je sache), ça m'aurait beaucoup intéressé ^^