Pourquoi doit-on nettoyer le code ? - ryzom.org forum archive

An archived topic, merged from 21 captures made between 26 October 2007 and 13 March 2008. ryzom.org · Forum index · All captures

Author

Message

< Ryzom.org General - Français ~ Pourquoi doit-on nettoyer le code ?

sdahan

Posted: Wed Oct 10, 2007 10:46 am

Joined: 06 Dec 2006 Posts: 71 Location: Tsukuba, Japon

Normalement, vous êtes tous au courant qu'il n'y aura pas de développement côté programmation tant que le code ne sera pas mis au propre. Mais bon, à moins d'être initié à l'art de la programmation, cela ne vous dit pas grand chose. Vu que l'on essaye de jouer la carte de la transparence et que cette décision influe énormément sur le développement des mois avenir, je vais essayer de vous expliquer pourquoi cette phase est essentielle.

Un programme est constitué de plusieurs composants. Par exemple, le client de Ryzom possède : un système de chat, d'une carte, d'un moteur graphique, d'un système pour le son, d'un lecteur MP3, d'un système de pointage avec la souris, d'un système de macro, d'un système pour se connecter au serveur, d'un système pour envoyer les rapports de cratch, etc, etc.

Chaque composant est lui aussi un système créé à partir d'autre composants. Par exemple, le chat à un composant pour savoir quelles sont les lettres entrées au clavier, un composant pour effacer une lettre, un composant pour le copier/coller, un composant pour avoir différents channels (guilde, alentour, région...), un composant pour le shout, un composant pour les émotes, un composant pour demander au moteur graphique d'afficher le texte...

Le composant pour le shout du chat est un système de... Bon, je pense que vous avez compris. Un programme comme Ryzom est un assemblage de composants qui sont eux même un assemblage de composants qui sont eux même un assemblage de...

Le problème, c'est que ces systèmes sont écrits par des humains. Qui dit humain, dit erreurs (bug dans notre langage). Plus le système est complexe et plus il y a de chance qu'il y ai des erreurs. C'est pour cela, que quand cela est possible, pour résoudre un problème, les programmeurs préfèrent prendre le temps de trouver la solution la moins complexe pour limiter le nombre de bugs. Malheureusement, chercher ces solutions simples demande un gros effort de réflexion ce qui demande beaucoup de temps à court terme. C'est pour cela, lorsque l'on est à la bourre, on utilise la première solution qui nous passe à l'esprit, et tant pis si cette solution est complexe et amène son lot de bugs. Par contre, à long terme, c'est très mauvais, car les bugs sont très long à corriger et il a été montré mainte fois qu'il vaut mieux prendre du temps à faire un code simple plutôt que d'essayer de corriger les bugs après coups. Prenant en compte que la sortie de Ryzom a été précipité, la vitesse de développement du jeu, la qualité du dernier patch et les echo que j'ai reçut, je suis prêt à parier ma collection de carambars que la plupart des solutions sont complexes et peu réfléchit.

Maintenant, essayez de voir le programme comme un maison. Les plus petits composants sont les fondations, et chaque système est construit les uns sur les autres. Si un composant se plante, alors tout les composants qui se trouvent dessus vont aussi planter. De plus à chaque fois que l'on rajoute un nouvel élément, on ajoute un nouveau stresse sur les fondations qui risque de s'écrouler.

Aujourd'hui, les fondations semblent très fragiles. C'est l'une des raisons pourquoi le dernier patch est si merdique malgré le peu de modifications qu'il apporte et malgré les mois de développement qui furent nécessaire pour lui donner naissance. Contrairement à Nevrax et à GF France, on a pas de managers qui nous interdisent de consolider les fondations car leur objectif premier était de sortir un patch le plus vite possible, la qualité étant secondaire pour eux. Nous on a le droit de prendre notre temps de consolider les fondations pour pouvoir développer plus vite des patch plus stable par la suite. De plus, vu l'état actuelle des fondations, on cours de gros risque pour la moindre modification.

C'est pour ça qu'il est nécessaire de consolider les fondations. De simplifier les solutions (rendre le code propre dans notre langage). Comme je l'ai dit, trouver des solutions simples prend du temps. De plus, aucune nouvelle fonctionnalité apparaît car les deux solutions apportent le même résultat. C'est juste que l'une sera plus stable que l'autre, aura moins de bugs et sera plus facile à utiliser.

Tant que je n'aurais pas vue le code, je ne pourrais rien affirmer. Mais je suis sure que cette phase de nettoyage va être nécessaire si l'on veut pouvoir espérer avancer par la suite.

Voila, fin du pavé.

psychee

Posted: Wed Oct 10, 2007 10:52 am

Joined: 26 Nov 2006 Posts: 231 Location: Valais, Suisse

J'aime quand un pro parle de son métier, c'est clair comme de l'eau pure, et ça a le mérite d'expliquer l'étendue du premier travail à effectuer, et sa difficulté.

Merci beaucoup, Sdahan.

_________________
Axelle "Psychée" Bouet
"Le destin est ce que l'on en fait"
www.psychee.org

Eigna

Posted: Wed Oct 10, 2007 10:53 am

Joined: 02 Oct 2007 Posts: 38

Tu as été très clair il faudrait mettre ce post en epinglé, pour bien faire comprendre a la communauté que la priorité sera de nettoyer le code et de le documenter pour que tous les devs puissent bosser dans de bonnes conditions et efficacement et que cela demandera plusieurs mois, mais a juste titre lorsque vous verrez le code vous serez plus apte a donné une échéance a ce premier projet.

Gros +1 pour ton explication, merci.

_________________
Eigna CSR aniro
Mageos beta
Andorianna l'emmerdeuse ^^
Guide event (animation, mes sensei Skowe - Wiedii - Gorias ^^ )

Osquallo

Posted: Wed Oct 10, 2007 10:55 am

Joined: 05 Oct 2007 Posts: 100

Oui avant de faire quoique que ce soit faut des bases potables , perso je suis prêt a attendre quitte a pas avoir de nouveauté avant un moment, surtout que les patchs qui viendrons seront moins cataclysmiques du coup ^^

Faut soigner notre petit ryry ^^

Dailleur bon courage aux devs qui auront a s'occuper de tout çà !

Merci pour tout

_________________
Osquallo, Chef de la ronde des menestrels

luinil

Posted: Wed Oct 10, 2007 10:59 am

Joined: 25 Nov 2006 Posts: 185

Ce n'est pas qu'un droit, c'est un devoir !

Par contre niveau améliorations, je pense que l'on doit nettoyer le code du coeur vers les couches les plus en surface. Mais une fois le cœur nettoyé, rien n'interdit de développer des ajouts qui s'appuieraient sur cette partie clean.

Il faut juste s'interdire de développer ququch qui s'appuie sur une partie non nettoyée.
Et du fait de cette interdiction oui il n'y auras pas de développement pendant un moment. Mais je pense qu'il ne faut pas non plus interdire de développer tant que l'on a pas tout assainît, on doit pouvoir développer sur les parties saines.

Faw

Posted: Wed Oct 10, 2007 11:49 am

Joined: 27 Nov 2006 Posts: 112 Location: Sud RP (Région de Pyr...)

Bah c'est clair qu'il faut faire du nettoyage et si on se lance la-dedans, ça me parait clair également qu'il faudra attendre que le nettoyage soit terminé pour commencer à developper...
En effet, on ne pourra pas développer sur un truc branlant...
Je pense que dès que l'on touchera à améliorer ou corriger les fondations, rien ne marchera plus du tout derrière ! (ce qui se trouve au dessus de la maison)...un peu comme un domino qu'on fait tomber au debut de la chaine et qui fait tomber tous les autres.
Par contre je ne pense pas que l'on puisse s'attaquer d'abord a corriger le toit de la maison tant que la base n'est pas saine...
Ce serait faire des corrections sur de mauvaises bases et là, rien de mieux pour générer de l'instabilité...
donc il faudra remonter au fur et à mesure pour tout corriger et ça, ça va pas être du gateau...
c'est pour ça que je souhaite d'une part que Ryzom puisse être remis en route même en l'etat des bugs actuels, sachant qu'il en sera ainsi entre 6 mois à un an avant de pouvoir commencer à y modifier quoi que ce soit....

_________________
Fawbrhysse, Fyros de la Glorieuse Atys
fafa91 sur le forum officiel Ryzom
Fabrice ou Fafa irl ;)

Capashen

Posted: Wed Oct 10, 2007 12:14 pm

Joined: 28 Nov 2006 Posts: 11

Pour ma part j'apprécie beaucoup l'explication qui a été donné, mais j'aimerais rajouter que le clean du code va aussi permettre aux devs d'appréhender le code. Parcequ'il faut voir que même les programmeurs les plus expérimentés on le cerveau qui chauffe devant autant de lignes de codes que celui de Ryzom.
Néanmoins j'aimerais préciser que même si le nettoyage de code va bloquer la partie dev, ça ne sera pas le cas des autres sections. Donc des ajouts pourront toujours être fait (nouvelles musiques, nouveaux models, zones, monstres,...). Parceque je ne pense pas que la refonte du code va engendrer la modification de la manière d'utiliser ce genre d'élèments, ou du moins un convertisseur sera crée si c'est le cas...

Nepherkaan

Posted: Wed Oct 10, 2007 12:41 pm

Joined: 28 Nov 2006 Posts: 135

luinil wrote:

...
Par contre niveau améliorations, je pense que l'on doit nettoyer le code du coeur vers les couches les plus en surface....

Je te mets au défi d'appréhender un MMO existant dans ce sens.
Il est toujours plus simple de partir de la finalité, de ce que l'on a sous les yeux de tangible, plutot que de s'efforcer a vouloir demarrer de la base.
Avant d'attaquer les racines, tu vérifies déjà pour chaque feuille/branche de l'arbre l'impact que cela aurait. Et encore, decider de nettoyer les racines serait de considérer que ce sont les racines qui sont la cause de tous les problèmes. Et généralement tu ne touches aux racines qu'en maitrisant l'ensemble des impacts.

Je rejoins Capashen sur son analyse. Rien n'empeche l'ajout de contenu (comme une map par ex), si celle ci n'amene rien de nouveau en terme de gameplay (ce qui n'etait pas le cas de la kitiniere de memoire).

Maintenant cette documentation pourrait etre assez rapide, car on ne parle pas de toucher a code, seulement de le documenter et identifier les failles/optimisations. Optimisations qui se feront dans une seconde phase je pense non ? J'ai du mal a croire qu'un nettoyage ne se fasse sans avoir documenter et fait un mapping complet des objets & interactions de base des differentes sphères.

De toute facon, ca ne sert à rien de partir sur de grands principes (comme je viens de le faire) tant que nous n'aurons pas le contenu sous la main.
+
Neph'

_________________
Greg.

Kervala

Posted: Wed Oct 10, 2007 1:47 pm

Joined: 24 Nov 2006 Posts: 223

Merci sdahan :)

La lecture du code va permettre de :
- créer une documentation afin que les autres devs n'aient pas besoin de repartir de zéro et de tout analyser par eux-même
- se familiariser avec le code
- détecter des anomalies
- optimiser/ajouter/supprimer certaines parties

Une fois que ce sera fait, ça va nous faciliter la tâche, car on aura une vue d'ensemble du code :)

Pour ma part, je pense que certaines parties du code de Ryzom n'ont pas voulu être mises volontairement dans le NeL alors que c'est là qu'elles devraient être.

Je pense aussi que dans le code de Ryzom, ils ont dû faire des bidouilles pour contourner des fonctionnalités non présentes dans le NeL et qu'il faudra donc simplifier tout ça.

Enfin bref, y a du boulot :)

_________________
Cédric OCHS / Kervala / Xiombarg

Jezabel

Posted: Wed Oct 10, 2007 2:37 pm

Joined: 24 Nov 2006 Posts: 167

Petite parenthèse personnelle...
J'ai pour ma part une très longue expérience de la programmation : calculatrices scientifiques, assembleur sur C64, AmosBasic sur Amiga, et ensuite... j'ai plongé dans le web (PHP, ASP, Javascript, Perl, ActionScript, SQL, MySQL...)
Je n'ai aucune difficulté à me plonger dans un nouveau language et à en apréhender les concepts et générallement je progresse très vite.

J'adore Ryzom mais je sens bien que mes connaissances actuelles ne seront pas d'une grande aide pour le programme Ryzom en lui même. Je n'ai jamais touché au C, ni mis les pieds dans une CVS mais l'envie de faire évoluer le programme Ryzom est tellement forte que je pourrai consacrer un peu de temps à apprendre ce qu'il faut.

Un débutant pur et dur en C (mais confirmé en programmation) peut-il espérer faire quelque chose d'utile dans un programme tel que Ryzom après 4 ou 5 mois d'apprentissage au rythme de 2 ou 3 heures par semaines (IRL très chargée) ?

Par exemple je lisais sur un fofo anglais un joueur qui se plaignait que les grands chiffres n'avaient pas de séparateur de milliers. Je me suis dit bètement "Ca c'est un truc que je pourrais peut-être modifier moi-même après un ou deux mois d'apprentissage".

Je rêve debout où c'est jouable ? Ais-je une chance de devenir utile après 50 ou 60 heures d'apprentissage du C ?

_________________
Jezabel / Toro / Ulrick IRL

Nihiadhil

Posted: Wed Oct 10, 2007 4:57 pm

Joined: 03 Oct 2007 Posts: 17 Location: Nancy - France

Bah lance toi, le C n'est pas ni plus ni plus facile qu'un autre language. Je pense qu'en en faisant 5 - 6 mois de façon régulière, et en ayant une bonne maitrise des languages objets (c'est du C++, si je ne m'abuse) et tous les réflexes de quelqu'un qui développe de longue date, ça devrait rouler tranquillement.

Bon après 2 / 3h par semaine je trouve ça peu, mais après ça dépend toujours de tes connaissances initiales et de ta vitesse d'apprentissage. Le plus important, reste à mon avis la pratique. Afin d'être familiariser avec le code, et surtout la lecture du code des autres, parce que la ça va être un gros morceau.

Tu peux commencer à t'amuser avec le NEL, une fois que tu le comprends bien et arrive à l'utiliser, c'est que ça ne te posera pas de soucis.

_________________
Nihi

Kervala

Posted: Wed Oct 10, 2007 5:31 pm

Joined: 24 Nov 2006 Posts: 223

Oui, je conseille à tous les futurs devs de s'entrainer déjà avec le NeL, d'installer tous les outils développement, les librairies qu'il a besoin, compiler des exemples, etc...

Vous pourrez déjà vous familiariser avec le NeL comme ça :)

Pour la doc : http://www.opennel.org

Pour le SVN : http://sourceforge.net/projects/nel/

En gros, ce qu'il vous faut :

- Un compilateur

* Visual C++ 6 (celui utilisé par Nevrax)
* Visual C++ 2003
* Visual C++ 2005 (la plupart utilisent celui-là)
* Visual C++ 2005 express (j'utilise celui-là car il est gratuit, il ne faut pas oublier de télécharger le Windows Platform SDK car il n'est pas inclu)

La version Linux n'est pas encore totalement debugguée mais si vous voulez vous y attaquer vous aurez besoin de GCC 3 ou 4.

- Les bibliothèques

* Platform SDK (pour Visual C++ 2005 Express)
* Direct X 9 SDK (pour le driver Direct3D)
* SDK 3dsmax (si vous voulez compilez le plugin)

* stlport 4 ou 5 (utilisé pour la STL)
* Headers OpenGL (pour le driver OpenGL)
* Freetype (pour les fontes)
* Libxml2 (pour le XML)
* Zlib (pour la compression et la LibPNG)
* LibPNG (pour les images PNG)
* LibJPEG (pour les images JPEG)
* fmod (pour le son)
* EAX (pour les effets du son)
* OpenSSL (pour le cryptage)

Heureusement que les admins d'OpenNeL ont pensé à tout et vous ont préparé des packs où la plupart des librairies sont déjà compilées :

- http://sourceforge.net/project/showfiles.php?group_id=193095&package_id=242440&release_id=540166
- http://sourceforge.net/project/showfiles.php?group_id=193095&package_id=242440&release_id=532358

Téléchargement

- Visual C++ 2005 Express : http://download.microsoft.com/download/7/6/0/760bd72d-bef3-4e0f-bdfb-1024ad5b005b/vc.iso
- SP1 de Visual C++ 2005 Express : http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=7b0b0339-613a-46e6-ab4d-080d4d4a8c4e
- Windows Platform SDK : http://www.microsoft.com/downloads/details.aspx?FamilyID=74dd6e2d-89c6-4e1e-af00-fc7d70f15439&DisplayLang=en
- Direct X 9 SDK : http://www.microsoft.com/downloads/details.aspx?FamilyID=529f03be-1339-48c4-bd5a-8506e5acf571&DisplayLang=en

Bon ,faudrait que je fasse un vrai tutoriel avec des images et tout, parce que l'installation peut durer plusieurs jours :p

Mais le temps de tout télécharger, tout installer, tout configurer et tout compiler :s

_________________
Cédric OCHS / Kervala / Xiombarg

Nihiadhil

Posted: Wed Oct 10, 2007 5:46 pm

Joined: 03 Oct 2007 Posts: 17 Location: Nancy - France

Arrrg voir autant de Microsoft dans le même post, ça fait mal aux yeux^^

En tout cas, c'est vrai que je n'avais absolument pas pensé à faire une petite liste comme ça.

Bien vu Kervala, ça va être utile ^^

_________________
Nihi

PepeFei

Posted: Wed Oct 10, 2007 6:54 pm

Joined: 03 Dec 2006 Posts: 18

Il y a un truc qui m'inquiète moi... c'est surtout la question de travail en équipe...
Nettoyer le code c'est repasser derrière quelqu'un d'autre et en quoi les bénévoles ici présents seront-ils meilleurs que les développeurs originaux sous la pression ?

J'entends par la qu'il y a toujours plusieurs facteurs qui mènent à un code non optimal :
- les délais
- la compétence intrinsèque du développeur
- la complexité du problème
- les outils
- je code en me souciant de l'évolutivité et de la maintenance ou uniquement la performance ? (design pattern power ?)

Donc qu'est-ce qui nous assure que moi (par exemple) en prenant mon temps, je serai en mesure de "nettoyer" le code d'un développeur talentueux qui était sous une contrainte de délai forte ?

En somme, chacun d'entre nous peut rajouter son lot de bêtises. Je considère déjà que tant qu'on ne se sera pas doté d'outils de travail en équipe complets on sera inefficaces.

CVS ou SVN c'est chouette mais ca fait avant tout du versioning et de la gestion de modifications concurrentes. Connaissez-vous les outils tels que JIRA ou Teamcity ?
Jira c'est plus qu'un bugtracker c'est également un outil de gestion de projet en équipe. Ca permet justement de définir :
- les produits
- les composants
- les sous composants des composants
- les versions de chacun de ces composants avec les dates de publications
- les tâches à effectuer (plus général que la notion de bug)
- les dépendances entre les tâches ("dépend de", "est un duplicata de", enfin les classiques quoi)

http://www.atlassian.com/software/jira/
http://www.jetbrains.com/teamcity/index.html

Teamcity c'est plus qu'un outil de build ça intègre Ant ou Maven et ça permet de gérer efficacement les commit plein de boulettes. On devient un peu plus "responsable" du code qu'on commit en spécifiant si le serveur Teamcity effectue une build avant ou après le commit pour vérifier si ca passe.
On définit des dépendances entre différents composants. Un commit de l'un entraine la build du composant et par conséquent la build d'un autre dépendant de lui pour vérifier que le tout fonctionne toujours.
Teamcity est capable de lancer automatiquement des tests unitaires en plus de la build. Car une build ne valide que la compilation et pas l'exécution au runtime.

Je parle de Jira ou Teamcity car les organisations qui font dans l'opensource peuvent obtenir des licences gratuites. Et comme notre principal ennemi sera l'organisation...

Avant même le nettoyage, une phase de spécification sera nécessaire. Déterminer les "contrats" de chacun des composants et ensuite affecter l'étude de chacun de ces composants à quelqu'un est à mon avis vital. Et pour cela la seule étude des points d'entrées et sorties devrait permettre de dégager ces composants et leur contrats.

Ce serait une vrai perte de temps que de lâcher chacun sur le SVN en disant : "hop vas-y ingurgite jusqu'à ce que tu vomisses ensuite on en parle ensemble autour d'une brioche" ^^ Et ces spécifications, composants etc. il nous faut bien un moyen de les exposer et d'en débattre. Et avoir un cadre de développement confortable et organisé attirera certainement plus les coups de paluches bénévoles qu'une solution "roots".

Ensuite pour la question du C/C++ si c'est dur ou pas... Je citerais l'un de mes professeurs il y a quelques années de cela : "le C c'est de la m****, le C++ c'est m*****++".
Il ne faut évidemment pas le prendre au pied de la lettre. Ce qu'il entendait pas là, c'est qu'il est facile de faire du code ... comment dire... "pourri" en C ou en C++. Peu de langages informatiques demandent autant de pratique avant d'être réellement maîtrisés. On peut dire d'un développeur en java qu'il est senior après 3-4 ans de métier, mais en C++ on dit qu'il faut presque une dizaine d'années.

Développer de manière professionnelle ce n'est pas que faire un code qui marche, c'est également faire en sorte qu'il soit reexploitable par un développeur lambda (si tant est que la maintenance est une contrainte lors du développement). C'est l'une des raisons d'être des design pattern. Quand je vois un truc qui s'appelle Visitor ou Proxy il y a de grandes chances que j'en comprenne le fonctionnement sans aucune difficulté. Simplement parce qu'on a les mêmes références ce développeur et moi.

On part du principe pessimiste que les équipes ayant travaillé sur Ryzom ont fait du mauvais travail parce qu'il y a des bugs. Pour moi ca ne veut pas forcément dire que c'est codé avec les pieds. Un Visitor qui bugge j'en appréhenderai la substance rapidement. Un code totalement original avec des identificateurs contenant 2 lettres maximum et aucun espace me fait nettement plus peur :)

-_- Flûte... pavé :/

Kervala

Posted: Wed Oct 10, 2007 7:05 pm

Joined: 24 Nov 2006 Posts: 223

Et ça c'est quoi ? http://www.opennel.org/jira/secure/Dashboard.jspa

C'est pas JIRA ? :p

Il suffisait de faire un tour sur http://www.opennel.org plutôt que de parler dans le vide :(

Et puis, on fait de la correction de bugs du NeL, quand quelque chose ne va pas, on fait un ticket, on essaie de corriger le bug, on programme un patch, le patch est testé et on applique le patch.

C'est facile de critiquer quand on ne sait même pas comment est structuré le NeL...

_________________
Cédric OCHS / Kervala / Xiombarg

psychee

Posted: Wed Oct 10, 2007 7:35 pm

Joined: 26 Nov 2006 Posts: 222 Location: Valais, Suisse

Kervala wrote:

On ne mord pas, Kervala ^^

_________________
Axelle "Psychée" Bouet
"Le destin est ce que l'on en fait"
www.psychee.org

PepeFei

Posted: Wed Oct 10, 2007 8:13 pm

Joined: 03 Dec 2006 Posts: 16

Kervala wrote:

Tu m'en vois plutôt heureux ^^ La dernière fois que je suis allé voir du côté du NeL ca remonte à Pfiuuuuu. je dois bien l'avouer. Mais tu ne peux donc que convenir que mon post ne pouvait ainsi être une critique ;)

J'avais parlé de Jira ici-même sur le forum de Ryzom.org l'an dernier et personne n'avait tiqué. Tant mieux si open NeL est déjà utilisé sur un Jira. Mais tu m'arrêteras si je me trompe, la même chose pourra/devra être faite pour la partie liée à Ryzom en lui même. Et ça ce n'est pas de la documentation à proprement parlé, ni du nettoyage de code. Cependant quelqu'un devra bien le faire.

La plupart des bénévoles apporteront leur concours sur leur temps libre. Et pour ma part, si je n'ai pas des conditions adéquates pour cela, je trainerais certainement la patte pour aller au turbin. Je mettais avant tout le doigt là dessus. Le développement ce n'est pas qu'une histoire de langage surtout en équipe. Et tout le monde n'a pas forcément l'expérience de Jira. Moi je n'ai bien l'expérience que de Jira dans le genre... Une entreprise avec un cadre de travail agréable reste plus attirante. Si c'est déjà le cas et qu'en parler n'est pas nécessaire alors il faut en faire la pub pour motiver les âmes charitables ^^ Je ne demande que ça.

Et je tenais aussi à relativiser la notion de "code propre". Aucun développeur ne pense jamais qu'il code mal (sauf quand il est en rush...), moi y compris, et pourtant.. C'est comme quand on dit qu'on est toujours l'imbécile d'un autre ^^

Kervala

Posted: Wed Oct 10, 2007 9:09 pm

Joined: 24 Nov 2006 Posts: 205

A l'époque, JIRA était déjà utilisé par Sfb (Matt Raykowski) pour la gestion de son MMORPG (Werewolf) et pour la gestion d'un miroir du NeL côté communauté :)

Pour ma part, je suis plus habitué à Trac, m'enfin l'utilisation est quasi identique d'après ce que j'ai pu constater.

_________________
Cédric OCHS / Kervala / Xiombarg

cev

Posted: Wed Oct 10, 2007 10:34 pm

Joined: 08 Oct 2007 Posts: 2

Allons, allons, les enfants, nous vous lisons chaque jour et sommes admiratifs de vos connaissances et de votre capacité, ensemble, à sauver Ryzom.

Mysthral

Posted: Thu Oct 11, 2007 12:53 am

Joined: 08 Oct 2007 Posts: 4

**** Mise en garde : Concept de nettoyage de code va suivre ! ****

J'ai déjà soumis une suggestion à d'autres et je vais vous en faire part ici. Voici quelques apprentissages que j'ai eu suite à des expériences de reprise de code dans ma profession. Il est possible que plusieurs les connaissent déjà mais je résume.

Premièrement, il faut définir un guide de nomenclature des éléments qui compose le code pour avoir le même langage tout le monde. Exemple : une variable de type entier long définie locallement débuterais par llng. En gros [portée de l'élément : l, g, c, etc...][Type d'élément : lng - Entier long, int - Entier, str - Chaîne de caractère, etc...][Nom de l'élément avec le premier caractère en majuscule]

Avec ce guide, tous les devs pourront se retrouver dans le code et parler de la même chose.

Deuxièmement, il faut déterminer la complexité de chaque brique de la fondation. Des outils existent pour du code Java et il sont gratuits. Il doit sûrement en exister pour du C++. Quand je dit "complexité", un première mesure de la complexité est la "complexité cyclomatique". Je vous invite à consulter le lien suivant pour savoir un peu plus c'est quoi.

http://trempet.uqam.ca/Enseignement/Cours/MGL7560/MGL7560Aut05/P%C3%A9dalogues/A16%20Std%20982.htm

Troisièmement, le gestionnaire de projet principal distribue les briques à vérifier (car trop complexes) à des équipes de devs. Je suggère toujours de débuter la distribution des éléments en commençant par ceux qui ne semble pas trop complexe pour permettre aux équipes de mieux appréhender le code et la philosophie derrière celui-ci. Une équipe peut être 1 ou plusieurs devs réunis ensemble avec un responsable désigné. Lorsqu'une brique est attribué à une équipe, aucune autre équipe touche à cette brique. Si une autre équipe veut y toucher, elle doit contacter le gestionnaire principal qui évaluera la demande et mettra en contact les responsables d'équipe s'il y a lieu.

Quatrièmement, il faut effectuer un suivi du travail accompli auprès de toutes les équipes et s'informer de la progression du développement à intervale régulier. Il faut aussi informer les clients (à savoir nous les joueurs) de la progression du travail.

Voilà mon petit résumé de chose à faire pour nettoyer du code. :D

Je désire aussi rappeller que ce n'est qu'une suggestion et qu'elle peut être modifié ou mise de côté à votre convenance.

J'espère que je n'ai pas été trop compliqué :P

zorglor

Posted: Thu Oct 11, 2007 6:56 am

Joined: 03 Oct 2007 Posts: 21

Une chose qui peut être interessante à faire, c'est de chercher dans les archives du projet Blender comment ils ont géré la réception du code. C'est en effet probablement le vécu qui se rapproche le plus de notre situation (reprise d'un code "entreprise" complet par une communauté).

_________________
Clément - Zorglor sur Aniro

Faro

Posted: Thu Oct 11, 2007 6:58 am

Joined: 26 Nov 2006 Posts: 63 Location: Colmar

*note de haut de page : Faro est un casse couille a devs, ca a été mon boulot pendant 1 an*

Je suis super content de l'explication en tête de ce thread, clair et précis. Il est clair (et cela était aussi clair dans ma tête même si je n'en est pas donné l'impression dans un autre thread) que le ménage devait être fait, et que cela prendrait bien une bonne année/année et demi.

Maintenant, une fois qu'on est dans le cœur du projet, la base, les primes racines du code (Yes, je l'ai placé :P), on peut, une fois l'effort de nettoyage commencé, l'orienter.

Cela se fera pas dessuite, car je pense que les couches réseaux et affichages n'influe pas sur le gameplay et seront peut être les premières touchés, mais une fois que l'on attaquera les primes racines du gameplay, il faudra a ce moment la avoir une vision de ce que l'on veut faire.

Je ne connais pas comment marche précisément le code (comme tous ici ou presque) et on ne peut faire que des suppositions, ce qui ne facilité pas la discussion, mais ce que je veut dire ... C'est que si on doit "foutre la paix au devs" ... faut pas non plus que les devs oublie au bon moment ... de redevenir vers les joueurs :)

Voilà, histoire de précisé que je n'ai pas mal compris comment cela doit fonctionner, et que je suis loin d'être un idéaliste qui pense que Ryzom sera changé en 3 jours ;)

_________________
Faro/Lurtz/skowe
Chef des légions Fyros
CSR Ryzom
Animateur Ryzom
Méchant et tétu

Kervala

Posted: Thu Oct 11, 2007 11:06 am

Joined: 24 Nov 2006 Posts: 205

Tout d'abord, il y a déjà un chef de projet et il sait ce qu'il doit faire. Vous aimeriez être à sa place ? Et bien proposez votre candidature au lieu de vouloir vous prendre pour lui et proposer une manière de gérer le projet :(

Pour les conventions utilisées dans le code :
http://www.opennel.org/confluence/display/NEL/CodingConventions

Ceux qui ont proposé leurs services en tant que développeurs C++, vous avez déjà de quoi vous documenter :
http://www.opennel.org/confluence/display/NEL/NeLDocumentation

Et pour l'API :
http://dev.ironicentertainment.org/~mattr/nel_dox/html/index.html

Quand on recevra le code (si jamais ça marche ^^), il y aura ceux qui connaîtront déjà le NeL et ceux qui ne le connaîtront pas, et les seconds seront désavantagés par rapport aux premiers.

Bref, au lieu de parler, il y a moyen de s'y mettre dès maintenant :)

_________________
Cédric OCHS / Kervala / Xiombarg

luinil

Posted: Thu Oct 11, 2007 11:35 am

Joined: 25 Nov 2006 Posts: 154

y'a pas des espèces de tutorial de NEL qui seraient plus accéssibles que la doc pour une première approche?

Oscar*

Posted: Thu Oct 11, 2007 11:51 am

Joined: 04 Oct 2007 Posts: 82 Location: Paris

Un "Nel pour les Nulls" quoi :P

_________________
Venez me rendre une petite visite (virtuelle ou IRL) à l'atelier :)
http://oscar.over-blog.fr/

Kervala

Posted: Thu Oct 11, 2007 12:37 pm

Joined: 24 Nov 2006 Posts: 205

J'ai commencé un tutoriel pour installer correctement tout les outils :)

http://www.virtualcitizenship.org/forums/viewtopic.php?t=463

Sinon dans la part "Getting Started" de la documentation, y a tout qui est expliqué :)

Avec ça, vous avez un environement de programmation fonctionnel.

Ryzom utilise encore d'autres librairies mais comme on ne les connait pas toutes, on doit se contenter de ça.

Il faudra que je rajoute au tutoriel comment faire un "hello world" avec le NeL :)

_________________
Cédric OCHS / Kervala / Xiombarg

Xavier Antoviaque

Posted: Thu Oct 11, 2007 12:56 pm

Joined: 15 Nov 2006 Posts: 388

Kervala wrote:

Attention à ne pas commencer à se prendre les pieds dans des guerres de religion dès le début... OpenNel et Ryzom sont deux projets complémentaires mais différents: Nel représente environ 10-20% de la masse du code de Ryzom. Il y a une dynamique complémentaire à trouver, car ce qui bénéficie à l'un bénéficie à l'autre, et il est tout à fait probable que les deux projets seront finement liés au final. Mais l'un concerne un jeu en tant que tel, l'autre un noyau de MMO.

Et les règles de fonctionnement entre les deux peuvent être différentes, il ne faut pas que ça nous empêche de collaborer; par exemple, Ryzom.org repose a priori d'avantage sur une approche démocratique. Notamment, il n'y a pas de raison de reprocher à quelqu'un de faire des suggestions sur la manière de gérer le projet, puisque c'est comme ça que Ryzom.org considère que c'est la manière la plus saine de procéder.

_________________
Xavier.

sdahan

Posted: Thu Oct 11, 2007 12:56 pm

Joined: 06 Dec 2006 Posts: 67 Location: Tsukuba, Japon

Jezabel wrote:

Un débutant pur et dur en C (mais confirmé en programmation) peut-il espérer faire quelque chose d'utile dans un programme tel que Ryzom après 4 ou 5 mois d'apprentissage au rythme de 2 ou 3 heures par semaines (IRL très chargée) ?

Personnellement, j'ai appris le C en un week-end avec Programmer en langage C de Claude Delannoy edition eyrolles. Et je pense l'avoir maitriser (a l'exception de certaine subtilite niveau macro) une une semaine. Ensuite, tu seras bon pour le Le Langage C: Norme ANSI, de Brian W. Kernighan et Dennis M. Ritchie edition Dunod. Je pense qu'avec ces deux bouquains et deux semaines d'apprentissage, le C n'aura plus que peut de secret pour toi.

Ton gros soucis ca va etre le C++. Enfin, je dis ton gros soucis, mais en veriter, c'est NOTRE gros soucis, c'est le C++. Comme beaucoup, je pense que c'est de la merde. Mais on n'a pas le trop de choix. Pour commencer, je te conseil apprendre le C++ de claude delannoy edition eyrolles. Ensuite, tu sera obliger d'acheter 'le langage C++' de Bjarne Stroustrup. Evite de le lire ou ton cerveau va fondre. Ce bouquain a etait fait pour servir de reference pas pour l'apprantissage. Ensuite, tu n'as plus qu'a faire comme tout le monde, foncer dans le code et te tirer les cheveux. Et pour avoir regarder la NEL, je peux te dire, que ca va etre costaux.

Ensuite tout dependra sur quoi tu bosses, car certaine partie necessite des connaissance particuliaire. Je pense au moteur graphique, au son, au reseau...

luinil wrote:

y'a pas des espèces de tutorial de NEL qui seraient plus accéssibles que la doc pour une première approche?

Il y a quelque examples qui trainent. Sinon, il y a le code de la NEL.

Kervala wrote:

Tout d'abord, il y a déjà un chef de projet et il sait ce qu'il doit faire.

Enfin, je crois que ceux qui donnent de bon conseil sont simplement embeter, car ils ne savent pas comment fonctionne les projets open source et se dommande comment cela peut fonctionner.

Je leur conseil d'etudier le hackdom et de commencer la cathedrale et le bazaar d'ESR. Personnelement, je suis en dessacord sur pas mal de details avec ESR, mais cela donne tout de meme une bonne vue d'ensemble sur le comment ca se passe.
http://www.linux-france.org/article/these/cathedrale-bazar/cathedrale-bazar_monoblock.html

Xavier Antoviaque wrote:

Attention à ne pas commencer à se prendre les pieds dans des guerres de religion dès le début.

Personnellement, pour l'instant, c'est Xavier que je reconnais en tant que chef prog, meme si ces talents de programmation sont limites. Je ne reconnais pas Ace en tant que leader pour l'instant car il ne c'est pas presente en tant que tel. Par contre, s'il souhaite prendre cette place il est presque certain que je le respecterais en tant que tel. Maintenant le presque dependra surtout s'il y a un dev prog dans l'entreprise, car il serait aussi possible de le considerer comme chef de projet.

_________________
Sylvain Dahan

Xavier Antoviaque

Posted: Thu Oct 11, 2007 3:11 pm

Joined: 15 Nov 2006 Posts: 388

sdahan wrote:

Xavier Antoviaque wrote:

Attention à ne pas commencer à se prendre les pieds dans des guerres de religion dès le début.

Perso, je ne me considère pas comme développeur, donc d'un point de vue code je ne serai pas le responsable. Il faudra faire le point le moment venu avec les différentes personnes intéressées pour voir qui l'occupera; on a de la chance, on a beaucoup de développeurs de qualité, avoir du mal à choisir est l'infortune des riches. ;p

Ceci dit, un point qu'il est particulièrement important de rappeller est qu'un tel responsable n'est pas un "dictateur bénévole", puisque comme tous les responsables du projet, il doit faire les choses en accord avec la communauté et valider les décisions importantes ou controversées par des votes.

_________________
Xavier.

Faro

Posted: Thu Oct 11, 2007 3:55 pm

Joined: 26 Nov 2006 Posts: 63 Location: Colmar

Je vais réagir sur deux ou trois points la vite fait, sans afressivité aucune (tu me connais Xiom :P).

1. Ceux qui parle ne savent pas comment on gère un projet libre : Dommage, je connais, je suis en train de le faire. Alors effectivement, on est pas 100 mais 5, mais quand même :P

2. je vais quote Kervala : "il y a déjà un chef de projet et il sait ce qu'il doit faire. Vous aimeriez être à sa place ? Et bien proposez votre candidature au lieu de vouloir vous prendre pour lui et proposer une manière de gérer le projet Sad "
Alors la ATTENTION :P Je n'ai pas la prétention d'être chef de projet, cependant je ne pense pas, comme le dit Xavier, que seul le chef de projet décide.
Personnelement je ne veut pas PRENDRE la place du chef de projet, et je ne pense pas dans mes posts avoir écrit comment il fallait s'y prendre, quel outil ou quel planning on va mettre en place.

Moi je veut parler de l'idée, du bout de la route, ce l'objectif que l'on va tous se donner. Je pense que la, autant un devs qu'un non dev (ce que je suis) à voix au chapitre.

Maintenant, je trouve dommage que l'impression donner a la lecture de certains post soit "t'es pas dev ? tu ferme ta gueule tu sais pas".
Je ne suis pas dev, je ne connais pas le C++ (enfin des rudiments uniquement), cependant je pense que comme tout a chacun je peut avoir un mot à dire. Surtout que je ne suis pas du genre kevin 12 an qui annonce "OUAIS LOL + 2 PvP ca rox !".
Je n'ai pas l'impression non plus de découvrir Ryzom et son gameplay.

Maintenant, si le projet n'est ouvert qu'au codeur C++, disont le clairement, je ferme la porte derrière moi et vous dérange plus :)

Faro

_________________
Faro/Lurtz/skowe
Chef des légions Fyros
CSR Ryzom
Animateur Ryzom
Méchant et tétu

Eigna

Posted: Thu Oct 11, 2007 4:24 pm

Joined: 02 Oct 2007 Posts: 38

Oula a la lecture des récents topic je sens que la seve monte :p
Alors un peu de calme svp sinon je modère tout cas a coup de pelle a crepe de CSR :d

Pour le moment on en es tous a se demander comment tout ca va s'organiser, chacun a ses idées et chacun le fait par bonne volonté et envie de progresser que ce soit pour ryzom ou dans des domaines spécifiques.

Donc ne faisons pas de scission entre les pro NEL et le spro Ryzom, ou n'entamons aps de croisade a savoir qui es responsable de quoi vu que rien n'es définit, des gens seront la pour décider au final même si le vote sera démocratique, et si vous avez peur de ne pas jouer un role dans cette aventure détrompez vous il y aura assez de travail pour tout le monde ^^

Mais effectivement on aura un chef de projet
un chef de devellopement plus son equipe
un chef marketing et son equipe
un chef support et son equipe
un chef webdesign et son equipe
etc...
Vous avez remarqué le mot redondant ^^, que vous soyez chef ou juste membre d'une equipe tout le monde contribuera, donc pas besoin de faire une guerre des clan ou de pouvoir et quand quelqu'un donne son avis c'est généralement pour apporter un savoir ou des solutions ou peut être qu'il attend un retour d'informations complémentaire pour agrandir son savoir donc pas besoin de montrer les dents ;p

_________________
Eigna CSR aniro
Mageos beta
Andorianna l'emmerdeuse ^^
Guide event (animation, mes sensei Skowe - Wiedii - Gorias ^^ )

Kervala

Posted: Thu Oct 11, 2007 5:06 pm

Joined: 24 Nov 2006 Posts: 223

Je parlais à ceux qui disaient qu'il fallait fixer des conventions, etc... mais quand on récupèrera le code, il suffira d'utiliser les conventions de Nevrax et on n'aura pas trop le choix. En principe, il s'agit des même que celles utilisées par le NeL :)

Je pense qu'on peut déjà se renseigner sur ce qui a été fait, puis proposer des solutions après avoir pris connaissance de ça. C'est surtout ce genre de remarques qui ne m'a pas plu :(

_________________
Cédric OCHS / Kervala / Xiombarg

Erebe

Posted: Thu Oct 11, 2007 6:50 pm

Joined: 27 Nov 2006 Posts: 24 Location: Lyon-Villeurbanne

Moi je pense qu'une truc ne fonctionne que si une seule personne décide. Et ça ne fonctionne bien que si cette seule personne sait entendre ceux qui travaillent avec lui.. pas facile hein :p

Rien ne fait plus mal à un projet qu'un débat d'idée qui s'enlise ; une personne permet de suivre une ligne claire, puisqu'on place délibérément la délibération d'une décision sur une seule personne qui, a priori, sera d'accord avec elle même. Donc je me proposerais pas :p

Eigna

Posted: Thu Oct 11, 2007 8:12 pm

Joined: 02 Oct 2007 Posts: 38

Entierement d'accord avec Erebe, donc maintenant que ca été dit on peut recommencer a bosser :)
Maintenant a vous de trouver votre organisation entre dev mais par pitié communiquer et oui etablissez certains standards :)

_________________
Eigna CSR aniro
Mageos beta
Andorianna l'emmerdeuse ^^
Guide event (animation, mes sensei Skowe - Wiedii - Gorias ^^ )

PepeFei

Posted: Sun Oct 14, 2007 6:55 pm

Joined: 03 Dec 2006 Posts: 18

Erebe wrote:

Moi je pense qu'une truc ne fonctionne que si une seule personne décide. Et ça ne fonctionne bien que si cette seule personne sait entendre ceux qui travaillent avec lui.. pas facile hein :p

Oui, de cette manière ça fonctionne bien. Moi je n'ai jamais dirigé d'équipe et ce n'est pas du tout ce qui m'attire. Par contre j'ai l'habitude de faire partie de telles équipes. Ca signifie cotoyer des personnes de tout niveau, les intégrer et les accepter sans leur dire RTFM à chaque remarque. C'est d'autant plus vrai quand on n'a aucune idée du profil de ses coéquipiers.

Cependant ce topic parle de nettoyage de code à l'origine. Comme je me suis fait moucher parce que je ne connaissais pas le NeL j'ai été jeter un oeil sur SVN. J'ai pris quelques noms de développeurs déclarés dans les entêtes des fichiers et j'ai cherché leur CV en ligne pour me faire une idée des compétences qui ont été mises en oeuvre pour la réalisation du NeL. J'ai également jeté un oeil sur le code du NeL pour voir les concepts utilisés et les conventions.

Ma conclusion est : si le code de Ryzom est de la même teneur, je ne vois pas en quoi il y aurait un sérieux nettoyage à faire et comment moi je serai compétent pour le faire (en tout cas pas plus que les gars qui l'ont créé).

Moi j'essaie juste de faire comprendre aux néophytes qui nous lisent que le développement ce n'est pas juste savoir faire une incrémentation ou apparaitre un rectangle gris à l'écran. Comprendre le NeL pour moi ça va jusqu'à comprendre les différents modèles utilisés (gestion de collision, recherche de chemin...) sinon une correction dans le fichier X peut engendrer une regression située bien ailleurs. Mais ce genre de problème peut se contrecarrer dans une certaine mesure par la méthode (les tests unitaires en sont un exemple mais je ne peux pas savoir si c'est utilisé dans le code de Ryzom).
L'une des reviews du NeL fait état de 500K lignes de codes en 11 espaces de nommage. Ca donne une petite idée de ce que Ryzom contient.
Quelles solutions allons-nous utiliser pour nous prémunir contre ces éventuelles régressions ? Car après avoir pris connaissance de ces quelques CV, ce n'est pas de compétences en développement dont les équipes de Nevrax et GF manquaient pour pondre un jeu non buggé... Les patchs que les joueurs de Ryzom ont vu passer ont bien eu leur lot de régressions pourtant.

zorglor

Posted: Sun Oct 14, 2007 7:04 pm

Joined: 03 Oct 2007 Posts: 45

Le code du NeL a l'air en effet bien pensé et structuré, mais il est à craindre que les mêmes méthodes n'aient pas été appliquées à un ensemble de composants destinés à servir de librairies de base et à être mises en GPL (et donc à servir de vitrine pour Nevrax), et au reste du code de Ryzom.

De plus, le développement sur NeL a été poursuivi par la communauté qui a probablement fait pas mal de travail de peaufinage, alors qu'au contraire, côté code de Ryzom, il est fort probable que le code n'a pas été en s'améliorant avec les difficultés successives des deux entreprises et les pressions sur les délais et sur le fait de sortir des patches.

_________________
Clément - Zorglor sur Aniro

Hekla

Posted: Mon Oct 15, 2007 11:38 am

Joined: 03 Oct 2007 Posts: 59

PepeFei wrote:

Teamcity est capable de lancer automatiquement des tests unitaires en plus de la build. Car une build ne valide que la compilation et pas l'exécution au runtime.

Je l'ai déjà dit ailleurs : si ce n'est pas encore le cas, il serait bon de maintenir, en parallèle du nettoyage de code, des librairies de tests unitaires qui permettraient à l'ensemble du code d'être plus solide lors de modifications et de poses de rustines...

Personnellement, je n'ai jamais écrit de tests unitaires en C/C++, mais si les spécifications, pré- et post-conditions sont documentées, écrire ce type de batteries de tests pendant que le code est nettoyé serait, je crois, très utile. De plus, ça devrait être à la portée de tout programmeur assez rapidement, dès que la structure de tests est mise en place.

acemtp

Posted: Tue Oct 16, 2007 9:15 am

Joined: 24 Nov 2006 Posts: 33

Non la communauté n'a jamais peaufiner NeL, au contraire, les peu de dev de la free software qui ont proposés des patchs étaient très petits et rarement intégré par Nevrax.

NeL est a 99.999% l'oeuvre de nevrax, tout comme ryzom (qui lui est 100%).

Par contre, les contraintes de temps et de pression sur les dev n'ont jamais été les memes sur NeL et ryzom, je vous laisse imaginer le resultat.

sdahan

Posted: Tue Oct 16, 2007 2:10 pm

Joined: 06 Dec 2006 Posts: 71 Location: Tsukuba, Japon

Hekla wrote:

Ca me fait plaisir de te voir insister la dessus. Moi aussi j'ai l'habitude de bosser avec des tests de regression automatique. Mais je n'ai aucune idee de ce que Ryzom propose a se sujet. Donc pour moi, wait and see.

_________________
Sylvain Dahan

Hekla

Posted: Tue Oct 16, 2007 9:34 pm

Joined: 03 Oct 2007 Posts: 59

sdahan wrote:

Bonne question. Ryzom dispose-t-il déjà de tests unitaires ? Si ce n'est pas le cas, cela vaudrait le coup d'en créer pour régression, au moins pour les méthodes des modules essentiels.

Kervala

Posted: Tue Oct 16, 2007 11:24 pm

Joined: 24 Nov 2006 Posts: 223

On peut faire ce genre de tests sur de la 3d ?

J'ai juste vu ça dans les librairies qui faisaient des traitements de textes ou mathématiques, mais comment savoir que le rendu est correct ?

_________________
Cédric OCHS / Kervala / Xiombarg

Hekla

Posted: Wed Oct 17, 2007 12:07 am

Joined: 03 Oct 2007 Posts: 59

Principalement pour les tests de logique. Pour les graphismes, les tests unitaires ne sont pas nécessairement plus ardus. Tout dépend de ce que l'on teste (voir ici).

Kervala

Posted: Wed Oct 17, 2007 11:42 am

Joined: 24 Nov 2006 Posts: 223

Merci pour les infos :)

_________________
Cédric OCHS / Kervala / Xiombarg