====== Refactoring du code Nel ====== Pour toute personne plongeant dans le code du MMORPG, une évidence s'impose rapidement : il faut réécrire certaines choses((Certains disent "tout", mais dans ce cas, nous vous invitons à rejoindre [[fr:mmorpg_engine_free|un projet qui a décidé de partir de zéro]]. )). Codeuses, programmeuses, vous qui avez plongé dans les entrailles du monstre et y avez survécu : merci de compléter cet article en notant les difficultés, les points positifs, en étayant les arguments sur "pourquoi il faut nettoyer" et enfin en partageant les bons outils pour le faire, les bonnes pratiques, etc. --- //[[user:zatalyz|zatalyz]] 2018/05/14 12:40// ===== État des lieux ===== ==== Un peu d'histoire ==== Une bonne partie du code a été pensée et écrite entre 2000 et 2002, avec un développement relativement actif de la part de Nevrax (la société originelle) jusqu'en 2006. Une partie du code est placée dès l'origine en licence libre (Nel), avec une communauté constituée autour de cette partie. Cependant, dès 2002, la société a subit une sacré pression financière et on peut sans peine imaginer que cela a mené, en interne, à du code écrit avec un peu moins de relecture. En 2006, Gameforge rachète les actifs, mais se place clairement dans une politique d'exploitation pure. Il n'y a probablement pas eu beaucoup de développement durant cette période, en dehors de quelques hacks vraiment foireux pour que ça tourne. Ça ne tournera d'ailleurs que jusqu'en 2007. En 2008, Ryzom est encore racheté, mais ce qui est livré est une version amputée du logiciel d'origine : la doc n'est pas transmise, le tout est dans un bazar monstrueux. Spiderweb (qui deviendra en gros Winchgate, les exploitants actuels du jeu) décident de libérer le reste du code ainsi que les assets. Ryzom Core est créé pour gérer cette partie libre et aider à faire le tri dans ce que Gameforge a laissé. Ryzom Core a accompli un gros travail afin que le code puisse de nouveau être utilisable. ==== L'héritage ==== D'un côté il y a du code écrit sous la pression, dans lequel il y a beaucoup de crasse ; de l'autre, même sur le "bon" code, ça reste des trucs écrits il y a plus de 10 ans donc avec une certaine dette technique. C'est un aspect dont il faut être conscient, et il y a évidement du travail à faire là-dessus. Cependant, c'est aussi un code qui a été écrit et pensé par de nombreux professionnels qui ont eu les moyens de faire les choses bien l'espace de quelques années. Aujourd'hui encore, le code est passionnant pour ce qu'il permet de faire et pour la façon dont les choses s'assemblent. ===== Ce que Khaganat soutient ===== Nous cherchons à trouver un équilibre entre pragmatisme et désir de bien faire. - Nous n'allons pas tout refaire de zéro. Sauf si vous nous donnez quelques millions d'€uros, afin de payer une quarantaine de professionnels durant 3-4 ans. - Nous pouvons, par moment, remplacer une brique par une autre (exemple : changer les api web par un truc maison). Mais avant de le faire, il importe de bien voir quels sont les conséquences, en terme de ressources humaines autant que dans la façon dont la "brique" interagit avec le reste du mur. Généralement, une seule personne a les compétences et le temps d'agir sur un des aspects ; lorsqu'elle disparaît((Parce que son boulot ou sa famille se rappelle à elle, par exemple ; ou parce que l'ampleur de la tâche a finit par effrayer...)), si son travail n'est pas fini, il est généralement impossible à continuer par d'autres((Parce qu'il n'y a pas les gens qui ont les compétences pour le finir. Pas forcément parce que le code est moche, ou pas pushé, ou pas documenté. Mais ces trois raisons expliquent aussi que du travail finisse à la poubelle.)). - Nous demandons à ce que les langages soient limités. C++, python, XML, LUA : c'est déjà beaucoup. Il est possible que Rust ou Go vous soient plus confortables, mais cela rendra votre code encore plus difficile à maintenir. Cela peut cependant s'envisager si, grâce à un autre langage, vous résolvez réellement rapidement et définitivement un problème. Et que ce langage ne soit pas trop dur à apprendre. Aujourd'hui, nous sommes avant tout intéressées par : * l'inventaire du code : répertorier les classes qui peuvent être manipulés par des librairies externes (voir par exemple PyNel) * la traque des erreurs et warnings (première couche de refactoring pour que ça tourne mieux) * la mise en place de tests unitaires afin d'améliorer la recherche des bugs et leurs corrections. À noter : nous favorisons python car cela permet un développement plus rapide qu'en C++ (pas besoin de recompiler en particulier) ET parce que cela se "traduit" assez bien en C++ lorsqu'il faut passer à un langage compilé et une gestion mémoire plus fine. ===== Ressources utiles ===== ==== Livres ==== * Clean Code / Coder proprement ISBN-13: 978-2744023279 : comment réaliser du beau code maintenable et reprenable, ce livre mérite sa réputation de référence d'après nos contacts. ==== Liens ==== * Golden Master Testing * https://www.softfluent.fr/blog/expertise/2017/12/18/Tout-ce-qu-il-faut-savoir-sur-Golden-Master-Testing * https://www.sois-net.fr/securiser-une-refonte-avec-le-golden-master-testing-printemps-agile-2015/ * http://blog.thecodewhisperer.com/permalink/surviving-legacy-code-with-golden-master-and-sampling * http://infinitest.github.io/ {{tag>Programmation MMORPG Ryzom_Core Projet}}