keke a écrit :Citation :Je ne sais pas si tu utilises les exceptions, mais elles suffisent généralement à détecter les problèmes sans avoir besoin de l'utilisateur car tu peux en mettre vraiment partout.
Ensuite, si tu fais des tests de tes méthodes, tu n'as pas de bugs.
Mon idéal est de ne pas faire participer les utilisateur au débogage du programme. J'essaye d'améliorer mon système pour que des logs provoqués lors des levées d'exceptions suffisent.
Un utilisateur ne peut pas être précis dans le rapport des problèmes car un système bien bâti ne devrait pas afficher d'erreurs (idéalement, il ne devrait pas en avoir 16), il ne peut donc pas te renseigner sur l'endroit du script où ça a merdé.
Ho l'utopiste 
.. tu peux avoir un bug sans pour autant qu'il y ai un problème d'affichage ou une exception. Se gourer sur un montant, se tromper sur un id, etc. L'utilisateur a certes, sa manière de parler, mais il est très utile pour trouver des bugs... parfois à son insu.
Ben je vois pas quelles erreurs
du système peuvent échapper aux exceptions. J'en mets partout.
Par exemple, après une requête SQL, je teste si mysql_error() vaut bien une chaîne vide, sinon je lève une exception avec la requête et l'erreur. Ensuite, je teste si le nombre de lignes affectées est bien ce qu'il devrait être, sinon je lève une exception. Etc.
Les erreurs de valeurs (coût d'un objet) ou d'affichage n'entre pas en ligne de compte. Celles-ci, tout le monde peut effectivement les rapporter.
Sephi-Chan
Sephi-Chan a écrit :Les erreurs de valeurs (coût d'un objet) ou d'affichage n'entre pas en ligne de compte. Celles-ci, tout le monde peut effectivement les rapporter.
C'est de ces erreurs que je parlais
. Ces erreurs peuvent être plus facilement déterminées grâce à l'indication du versionning.
Bon courage avec les exceptions
. J'espère que ça te ralenti pas trop dans ton développement.
Kéké.
keke a écrit :Sephi-Chan a écrit :Les erreurs de valeurs (coût d'un objet) ou d'affichage n'entre pas en ligne de compte. Celles-ci, tout le monde peut effectivement les rapporter.
C'est de ces erreurs que je parlais . Ces erreurs peuvent être plus facilement déterminées grâce à l'indication du versionning.
Moui... Je ne me souviens pas (il faut dire que je ne les note pas non plus) de la moindre modification que je fais. Mais de manière générale je fais attention aux modifications superficielles.
keke a écrit :Bon courage avec les exceptions . J'espère que ça te ralenti pas trop dans ton développement.
Tu plaisantes ? C'est tout simple ! Comme dans tout programme, je teste les cas d'erreur et s'ils arrivent, je lance une exception.
Sephi-Chan
Heureux d'être de nouveau en phase
.
Les erreurs que tu soulignes peuvent apparaitre lorsqu'on développe à plusieurs sur des modules qui normalement ne se chevauchent pas, sauf le petit détail qu'on a oublié... Le versionning permet de jalonner un travail d'équipe. C'est vrai que j'en ai pas parlé avant, mais c'était une telle évidence que je suis passé à côté.
Bref, on ne passe à la prochaine version que lorsque les différents bout de code ont été intégré en test et validé. Le jalonnage permet alors de prétendre à un recettage de son application, indépendament des tests unitaires effectués par chacun des développeurs.
Kéké.
Magdales est en G5R3C13 depuis ce matin ... un bug sur le timeout de session.
GOROCO pas mal je ne connaissais pas....
Personnellement j'utilise ce système : v0.0a-z
Le premier chiffre marque une mise à jour importante, le deuxième une (ou plusieures) mise à jour mineure et les lettres : les corrections des bugs. (exemple : v0.5e)
Ainsi qu'un certain côté, on pourrait considèrer que faire pas mal de "petite" mise à jour, le tout mis ensemble serait en faite une mise à jour majeur du jeu, mais venu progressivement...
Enfin, je n'ais jamais été plus loin que .9 ce qui est peut être la faille de ma méthode
".
Maintenant que je connais GOROCO, je pense que celui-ci est quand même mieux adapté.
T'es limité à 26 MàJ de bugs donc ?
Moi personnellement, j'utilise comme versionnage la date à laquelle je publie.
C'est une manière comme une autre. A priori, il n'y a aucun manière universelle de définir une version d'une application donc c'est plus ou moins propre à soi même
L.
Ren Nelos a écrit :C'est une manière comme une autre. A priori, il n'y a aucun manière universelle de définir une version d'une application donc c'est plus ou moins propre à soi même
je partage ton avis
Pourquoi passer d'une V1.3 à une V2 plutôt qu'à une V1.4
perso le changement de version c'est soit :
- parce que je change radicalement un concept ( y avait des classes de personnage y en a plus)
- parce que j'ajoute une fonctionnalité majeure ( on rajoute la "magie", passage de 2 à 3 dimmensions.... etc..)
- parce qu'on arrête le monde (fin de partie -> nouvelle partie)
- et j'oubliais, parce que je change de technologie
la seule discussion après est le côté "marketing" du versionning
- parce que je fais repayer la nouvelle version alors qu'une version mineure fait partie de l'abonnement / maintenance (vrai autant sur le jeu que sur d'autres produits informatiques)
- parce que je crée une actualité / un buzz sur la nouvelle version
L'idée du GOROCO est de permettre de travailler sur plusieurs versions en parallèle ..
Equipe 1 de dev sur la version G5R4 (Mini et moi)
Equipe 2 de dev sur la version G6R0 (Gurney et peut-être Tigrou)
On bosse en parallèle et on ne se chevauche pas dans nos travaux. Quand on parle d'une modification (Ouais ! j'ai fini le module Tchat !) on regarde la version et on sait où on en est.
Ca permet ainsi Très facilement de définir avec beaucoup de précision le point d'avancement d'un projet.
Ensuite, le côté Marqueting à un impact, c'est pour cela que sur Magdales, on laisse apparaitre les 2 premiers numéros de version V5.3, V5.4, V6.0 ... pour montrer la progression et les étapes que l'on juge importante.
kéké.
Ren Nelos a écrit :T'es limité à 26 MàJ de bugs donc ?
Tu peux repartir a 0 a chaque changement de "sous-version" (ou "version-complète") ainsi tu es moins limité
Oui oui c'est très limité comme technique...
Mais tu peux aussi regrouper plusieurs corrections de bug sous la même lettre... et par exemple tu as aussi ça :
v 1.2e tu passes a la v1.3...
Puis tu corriges un bug : v1.3a
ainsi tu as plus de combinaison avant d'arriver a z.
Tu peux aussi faire ainsi : v1.31 etc
Mais bon je pense que GOROCO est quand même mieux