Définition des outils

Je pense qu'il faut faire dans le simple et pas trop se compliquer la vie. Evitons les outils de capacity planning et autre gestionnaire d'exigences.

Je vois plusieurs catégories d'outils nécessaires :
- Rapport de bug (bugzilla par exemple)
- Gestion des versions (CVS)
- Outil de développement (chacun prendra son outil préféré, eclipse + un plugin peuvent faire l'affaire, d'autant que eclipse intègre un plugin pour CVS)


Par contre, je m'interroge sur la base de travail. Doit on envisager l'utilisation d'un framework de base type Zend Framework ou doit on partir de zéro et créer le notre… La dernière option étant de s'en passer, mais ça serait plus pratique d'avoir un certain nombre de fonction de base codée et réutilisable.

Comme je l'ai dit ailleurs, moi j'utilise phpcollab, c'est simple et rapide a utiliser. On peut faire la gestion de bug avec.

Pour ce qui est des CVS, je trouve qu'on va se compliquer un peu la vie. Si on se répartie bien les classe a construire on peut s'arranger pour ne pas avoir de probleme et surtout de besoin de CVS.

Pour les outils, moi j'utilise Quanta et c'est bien ;-)

Moi j'aimais bien plus notepad++ (ca ne doit pas gerer le CVS ou alors avec un autre outil à coté) mais à choisir, je préfère Eclipse à Quanta à la limite.

Les bugreports, j'en avait testé plusieurs et je trouve que ce n'est pas facile d'en trouver des tout simple (genre qui a pris en charge la résolution du prb, barre de progression de la résolution du prb, commentaires, résolution et résumé de ce qui a été corrigé). En plus ils sont pas très beaux ces outils et l'utilisateur lambda pourrait s'y perdre. Je suis plus pour coder un outil qu'on intègrerait au site (à moins que vous en ayez des tout simple ?).

CVS, ca me plait bien quand même car ca permet de revenir en arrière sur un codage mais comme j'ai dis ailleurs je ne connais pas trop.


Pour les framework, je suis d'avis d'en prendre. Y a possibilité d'utiliser Smarty pour les templates par exemple, pour javascript, on peut prendre scriptaculous. Pour SQL juste, on peut coder la class (Vladimir en proposait une, sinon j'en ait une aussi).
=> Avec ca je vois pas de quoi on pourrait avoir besoin en plus.

Franchement, je n'y connais pas grand chose sur ces outils.
Là où je bosse, l'environnement est produit par la boîte elle-même.
On bosse sur Notepad++ pour l'édition.
La compilation se fait sur des back-ends en noyau intel puis IBM (calculateurs de je ne sais quel modèle).
La gestion de bugs se fait en interne : je trouve plus sain que chaque développeur assure la sécurité de son code et vérifie (détectable en majorité en préprod) sa stabilité.

L'avantage lorsque l'on utilise un langage type C++, c'est tout ce qui est gestion d'exceptions. Une fois que l'on a correctement identifié les zones dangereuses, on simplifie beaucoup la maintenance.

Faut pas oublier que l'on va développer un code qui tourne en continue, qui évolue en continue et qui est de gros volume (question données). On a tout intérêt à faire du code très propre assez blindé sur les possibles erreurs.

C'était la minute du gars qui n'y connait pas tellement mais qui est confronté tous les jours à une la maintenance d'une base de données vieille de trente ans qui subit plus de 6 millions de requêtes par jours (90% du traffic aérien, hôtelier, de location de voitures d'Europe).

C'est pour ca qu'il faudra faire de la revue de code, par instinct un développeur ne peut pas aller contre ce qu'il a écrit. Il peut y avoir une faille énorme et qu'il ne la voit pas ! c'est la base du développement. en informatique, 40% du temps de développement, c'est souvent du débug.

je dirais 80%

Mais en effet, la revue de code est nécessaire.
Il faudra définir des revues de code croisées surtout entre différentes applications.
Je ne sais pas combien nous serons, mais à partir d'une certaine taille, il faudra faire des groupes, non ?

Je suis aussi pour avoir un gestionnaire de source comme CVS, c'est plus sécuritaire. Pour le débug, a vrai dire je m'ne fiche, phpcollab ou bugzilla ou du spécifique. Je connais plus bugzilla que je trouve simple mais effectivement coté graphique c'est pas la panassé.

Pour publier dans CVS on peut avoir un outil complémentaire type tortoiseCVS (ou SVN plus récent que CVS). A vrai dire je me rangerais à l'vi de la majorité. La sécurité c'est contraignant et ca bouffe du temps mais ca a des avantages.

Oui, plus le projet va grossir, plus cela sera rentable par rapport à la maintenance.
Je vois tous les jours ce que c'est que de maintenir du code qui est écrit en assembleur, c, c++ un peu tout mélangé avec des rustines de partout.

je connais ca aussi, et si le code avait été archivé avec une vrai gestion des évolutions, on passerai pas 2 jours sur une évol mais 2 heures.

Tu m'étonnes...
Lorsque je vois qu'avant de connaître le code il me fallait cinq jours pour corriger un problème que je peux corriger maintenant en une demi journée car je sais comment tout s'assemble, ça fait peur.

euhh, et l'importance d'un bon schéma de BD derrière, l'oubliez pas !

Là, je peux mettre ma petite expérience si vous en voulez

Oui, et Archimbaud est notre expert Bdd.

Perso, j'attends un peu que les experts commencent à entrer dans le détail pour entrer dans de l'analyse pure et dure.

jbaptisteg a écrit:Perso, j'attends un peu que les experts commencent à entrer dans le détail pour entrer dans de l'analyse pure et dure.

Ca va être difficile d'avoir ça de suite. Il faut d'abord mettre en place tous les systèmes fondamentaux du jeu pour pouvoir les équilibrer et ensuite entrer dans les détails. Mais ça avance vite, je trouve.

On peut travailler sur l'interface, sur l'arborescence fichier et BDD. Il y a un certain nombre de script dont on est déjà sûr (ex: pour s'inscrire, se connecter, la base du forum, etc.). Donc on peut commencer à en discuter, ca sera du temps de gagné toujours.

Oui on peut, que l'histoire du questionnaire est pas réglée.

jbaptisteg a écrit:Oui, et Archimbaud est notre expert Bdd.

Euh, c'est à dire ?
Je maîtrise pas mal l'aspect théorique et fonctionnel, mais si c'est avec un langage et des outils dont j'ai pas l'habitude, je risque de ne pas être le plus calé.

Remarque, si ce que l'on attende de moi c'est de définir l'ensemble organique de la base de données, je pense que c'est dans mes cordes.

Pitié, pas en UML...

Ben si en uml.. LOL non, pas en UML, en merise (un petit MCD) ca conviendrait. Bien que je voudrait connaitre les fonctionnalité de la classe d'abstraction de vlademir avant de définir la méthodologie de modélisation.

Pour moi c'est pareil... si je peux y jeter un coup d'oeil...

Visions à la fois "fonctionnelle" et "partique/perf" de la chose