Coder en groupe

[Zamentur]

Bonjour,
Bon pour la construction de la v2 de www.ragol-online.info j'ai recuperé un bon nombre de programmeur de si de là...
Le hic c'est que quand on été 3 à coder sur la v1 il y avais déjà quelques difference sur la façon de coder...

On a donc decider d'installer une norme de formatage de code et d'optimisation, çà peut aller de la façon de noter une variable à celle de mettre ses accolades, en passant par le sql etc...

La creation et la mise en place de cette norme pour coder tous de façon identique as mis un certains temps et au fur et à mesure on rajoute des trucs utiles.
Je me demandais donc si certains d'entre vous avez déjà un tel systeme et si ils pouvaient en faire part?

Note: si vous voulez je peux vous fournir notre "norme" de codage, mais c'est assez long à lire et en plus pas finis.
Note2: pour ceux qui se demande pourquoi je fais çà, ben je leure repond juste que j'ai bien du passer une 100n d'heure à reecrire des script pour qu'ils soient clair et uniforme dans leur construction

[Mysterarts]

Salut !
Désolé, j'ai jamais codé en groupe, alors je pourrai pas t'informer de ma technique ^^
Par contre, moi, ça m'interesse de voir ce que vous avez mis en place comme norme..; Et je comprend parfaitement la necessité d'en mettre en place...
SInon, je sais pas si tu connais, mais il existe des logiciel comme SVN qui sont très pratique pour coder à plusieurs (ça permet de gérer les différents code, d'éviter d'écraser des version codé en meme temps par 2 personne...) Mais Naholyr par exemple t'en parlerai mieux que moi ^^

Mysterarts

[Zamentur]

Oui j'en ai déjà entendue parler... Mais effectivement j'aurrais besoin de conseil sur ce genre de logiciel (je suis attaché à mon PSpadeditor lol)

Pour notre norme, je vais en faire un resumé sur PDF(ou autre), si tu veux je pourrais le mettre ici

[Amrac]

Une norme de nommage est très important lorsqu'on travail en équipe.

A mon stage, en plus de définir une syntaxe type pour les variables/Acseseurs/Fonction/Nom de fichier, on as aussi imposé une entête pour chaque Fonction/Nom de fichier contenant (plus ou moins) la date de création, l'auteur, les dernieres modifs, une description .. .. . .. .

Sinon, l'idéal est de faire relire le code par une autre personne avant de l'intégré officiellement avec le reste. De la sorte, tu obtient un regard neuf sur la lisibilité du code (très important pour l'avenir) et tu bénéficiera des quelques astuces de l'autres développeur (Optimisation des performances, ajout de petites fonctions ....)

[Zamentur]

Dac.
Bon le trucs c'est qu'il faut bien se rendre compte qu'on ne se connait pas tous IRL (une IRL es justement prevue) et que par consequent ils sont pas à coté de moi pour relire un code...
Le plus souvent on ne peut donc pas faire relire directement (à moins de coder en groupe via msn ce qui peut nous arriver)

L'entete des fichier et fonction est prevue, cependant on ne prevois pas non plus un trucs trop long, on concidere qu'il n'y a que la description qui importe. Pour ce qui est de l'auteur et de la date j'espere qu'un logiciel comme Subversion (=SVN je viens de faire une recherche) pourra nous aider de ce point de vue.

Bon dés que je suis en vacances je publie notre norme

[naholyr]

Pour ce qui est de l'auteur et de la date j'espere qu'un logiciel comme Subversion (=SVN je viens de faire une recherche) pourra nous aider de ce point de vue.

Oui il pourra vous aider, car tu interdiras les "commit" publics, et quand on enverra une modification sur le dépôt, il faudra s'être identifié. Ainsi chaque modification du dépôt sera identifiée par :
- son auteur
- la date
- un commentaire de la part de l'auteur
- la liste complète des modifications (diff)

Consulte ce message pour en savoir plus sur la mise en place : http://www.jeuweb.org/board/showthread.php?tid=1801

À ta place je mettrais également en place un wiki, qui aura deux principaux objectifs :
- Permettre la rédaction de la documentation en équipe (de la même façon que le dépôt SVN, chaque page de Wiki est accompagnée de son historique de modifications).
- Disposer d'articles destinés à l'équipe de développement (exemple : conventions de nommage, liens vers les ressources importantes, etc...).

Quand tu auras sais le concept, sa mise en oeuvre se fera grâce à deux principaux outils :
- Le logiciel TortoiseSVN pour le travail au quotidien (update, commit)
- Le site OpenSVN pour l'hébergement de dépôt (chaque projet est également accompagné d'un wiki, et tu peux définir des utilisateurs, des permissions, etc...)

Il y en a bien évidemment plein d'autres, ce sont simplement ceux que j'utilise.

[Zamentur]

tient justement une petite question sur SVN...
SVN permet t'il de tester directement le code?
Je veux dire qu'il gere les donnée mais quand je commit si je veux tester le code sur la version alpha est ce que c'est possible de le faire?
Je sais pas si ma question est trés clair d'ailleurs elle est peut etre nulle, mais je prefere la poser que d'etre ignorant.

[pascal]

si t veux bosser en groupe pour faire évoluer le code, je te conseille les tests unitaires :
Simple Test

ils permettent de garder un code fonctionnel / détecter les modifications foireuses ( les bugs ) très rapidement.

A+

Pascal

[naholyr]

tient justement une petite question sur SVN...
SVN permet t'il de tester directement le code?
Je veux dire qu'il gere les donnée mais quand je commit si je veux tester le code sur la version alpha est ce que c'est possible de le faire?

Ben théoriquement, tu as un serveur web local sur ton poste de développement, l'environnement est validé compatible avec le serveur de production (versions de PHP et MySQL principalement), et donc quand tu update ton code tu dois pouvoir le faire fonctionner sur ton poste.
Dans cette optique, l'application devrait avoir :
- Un unique fichier de config décrivant les chemins et les paramètres d'accès à la bdd. Ce fichier ne doit pas être versionné ! Ainsi chaque développeur a son fichier de config à lui pour que l'appli marche sur son poste.
- Un fichier SQL contenant un DUMP de la base de données correspondant à la révision commitée. Ce fichier lui doit être versionné.

Ainsi tu fais un svn update, tu envoies les données SQL dans ta base locale (si elles ont changé) et tu peux tester l'appli en local.

[Amrac]

Personnellement j'ai travaillé avec Git/Cogito pour la gestion de version, c'est efficace mais ca prend beaucoup de temps, surtout si vous faites ça durant vos loisirs.

Il nous a fallut pas loin de 2 semaines pour utiliser correctement cet outil et re-obtenir une vitesse normal de développement.
Mais peu être qu'avec SVN cela ira mieux.