Recommencer son projet à zéro ?

Bonjour,

Depuis quelques temps, et de plus en plus, je m’interroge.

J’ai un jeu que je gère et que je fais évoluer depuis 10 ans, c’est un moyennement gros projet perso qui compte quand même 15000 joueurs.

Les plus anciennes parties du code ont 10 ans. A l’époque, j’avais choisi Java pour le serveur de jeu, et PHP pour le site. C’est les deux seuls langages que je maîtrisais à ce moment-là (avec C++ pour le client, mais c’est hors de propos ici) Je ne connaissais pas non plus les frameworks plus que ça, et même si j’en avais vaguement entendu parler, je n’avais pas envie de m’y mettre. L’aspect "boîte noire" de ces géants m’ont toujours un peu rebuté.

La situation actuelle est donc une code base dont certaines parties n’ont pas été touchées depuis 2010:

• Pas de Spring, pas de Symfony, même pas de Maven
• Une implémentation perso, suffisante mais très approximative de websocket selon la RFC pour le serveur de jeu depuis 2012
• Côté Java, des god classes de 2000+ lignes, un certain nombre de méthodes dépassant les 200 lignes, la réimplémentation de certaines choses que j’aurais pu prendre dans la bibliothèque standard si j’avais su
• Côté PHP, une majorité de code uniquement procédural, et un joyeux mix mélangeant allègrement accès DB et affichage dans le même fichier
• ET le tout, sans aucun test

Depuis, j’ai terminé mes études, puis j’ai commencé à bosser dans une boîte d’informatique, Spring et konsor sont devenus beaucoup moins mystérieux, j’ai appris un certain nombre de principes pour faire du meilleur code…. enfin bref, je n’ai plus du tout la même façon de coder qu’il y a 10 ans. Encore heureux, me direz-vous.

Le corrolaire est celui-ci: j’ai de plus en plus de mal, je déteste de plus en plus aller faire des modifications dans mon code, et je suis de moins en moins motivé à le faire. Cela d’autant plus si ce qu’il y a à changer se trouve dans les parties les plus anciennes. De plus, je me suis résigné à la persistance de certains bugs et certaines failles. Certains existent depuis plus de 5 ans et j’ai abandonné tout espoir de les corriger. Certains de ces bugs sont même connus par coeur des joueurs les plus assidûs.

Pour en rajouter une dernière couche, mon projet ne scale pas. La nécéssité ne s’est jamais présentée jusqu’ici et j’ai toujours fait avec un serveur unique en fait, mais au plus fort du confinement, je me suis approché de quelques potentielles limites… plus de 900 joueurs simultanément connectés.

Si ça avait été un projet d’entreprise, on parlerait sans doute de dette technique, accumulée au fil des années.

D’Oû la grande question sur la vie, l’univers, et tout le reste … du projet:

Première grande question: est-ce que je devrais tout recommencer à zéro ?

Cela me permettrait de repartir sur de bonnes bases, peut-être essayer quelque chose de nouveau, et surtout, que ce soit à nouveau fun de travailler dessus comme cela le fût jadis. C’est un projet perso, fait sur mon temps libre, donc il faut que ça reste toujours fun.

Deuxième grande question: est-ce que je peux recommencer à zéro ?

Oui, parce que mine de rien, pendant le temps où je travaillerai sur une refonte en coulisses, il n’y aura pas (ou très peu) de nouveauté visible pour les joueurs. Comment l’expliquer ? J’ai beau dire que c’est gratuit et donc que je n’ai aucune obligation, les attentes n’en seront pas moins présentes. ON m’attend au contour.

JE sais ce que j’ai, ce que j’aimerais changer, et ce que je n’aimerais plus, mais est-ce que j’aurai le courage de tout reprendre et d’aller jusqu’au bout ? la question n’est pas non plus complètement anodine.

Troisième grande question: quitte à vouloir recommencer à zéro, à quel point devrais-je ou non tenter une toute nouvelle expérience ou recommencer avec ce avec quoi je suis à l’aise actuellement ?

J’ai un peu peur de partir sur du totalement nouveau, justement parce que c’est nouveau pour moi, et parce que, comme je l’ai déjà dit, la communauté m’attend au contour. En d’autres termes j’ai pas intérêt à me rater.

Par contre, est-ce que si je repars sur du Java+Spring parce que je mâitrise Java et parce que c’est c’est sur cet écosystème que je travaille professionnellement en ce moment, au final je ne vais pas regretter de n’avoir pas essayé autre chose / ne pas avoir été plus ambitieux ? Les projets persos sont justement là pour faire des choses différentes de ce qu’on fait au boulot non ?

Est-ce que vous avez des expériences à partager sur la vie à long terme d’un projet perso ? Vous avez essayé, et vous avez réussi, ou bien vous avez foiré une refonte totale ? Ou alors vous avez renoncé, et Vous regrettez peut-être d’avoir trop attendu ?

J’ai mis ce sujet dans le bar parce que le but premier n’est pas de parler purement technique, sauf si ça a joué un rôle clé dans votre cas. ON y reviendra sans doute dans un second temps, c’est probablement inévitable, selon comment le sujet va évoluer. Mais pour l’instant, pas la peine de venir dire que PHP c’est pour les bricolos, que Java c’est lourd et has been, ou que Ruby c’est mieux que Python.

Merci de m’avoir lu jusqu’au bout, et merci pour vos réponses.

Je n’y connais rien en librairie Java, je répond juste sur la partie motivation :

Oui, parce que mine de rien, pendant le temps où je travaillerai sur une refonte en coulisses, il n’y aura pas (ou très peu) de nouveauté visible pour les joueurs. Comment l’expliquer ? J’ai beau dire que c’est gratuit et donc que je n’ai aucune obligation, les attentes n’en seront pas moins présentes. ON m’attend au contour.

JE sais ce que j’ai, ce que j’aimerais changer, et ce que je n’aimerais plus, mais est-ce que j’aurai le courage de tout reprendre et d’aller jusqu’au bout ? la question n’est pas non plus complètement anodine.

Dans ce genre de situation tu risques de ne pas avoir l’impression d’avancer et de te démotiver. S’il s’agit d’un projet perso, tu devrais peut-être réfléchir de le faire au fur et à mesure en gardant le code existant. C’est-à-dire pouvoir alterner et faire étape par étape. Le faire 100% a zéro c’est une mauvaise chose, essaye d’avoir une refonte inférieur à un mois quitte à découper ton code par bundle (= paquet/collection de fonctionnalité). Sinon tu risque de t’y perdre et de perdre des joueurs.

Les projets persos sont justement là pour faire des choses différentes de ce qu’on fait au boulot non ?

C’est que tu aimes ton travail que tu le gardes ? Tu connais la moyenne d’âge de tes joueurs ? Il faudrait calculer la moyenne de joueurs qui jouent à ton jeu par mois/semaines, tu pourrais t’en faire un revenu principale (en mettant un bonus de 2–3 € par mois). Pendant mes études, j’avais un jeu web qui générait 300€ par mois pour seulement 20 joueurs co simultanément mais une base de ~12000 inscrits (j’avais mis un avantage qui permettait d’avoir un peu plus de temps de jeu ou des skins). Mon emploi du temps d’étudiant/perso + mes envies qui ont changé et une refonte qui a tardé a tué mon envie de continuer.

Donc mon unique conseil : Fait une refonte accessible qui demande au maximum un mois ou deux mois (ça dépend aussi du temps que tu passes dessus et ton niveau de démotivation?), au dessus arrête ou alterne ce que tu fais pour ton projet et ainsi préserver ta motivation.

NB : Détail important : Assure toi que la refonte à du sens technique ou que tu migres vers un outil que tu connais bien et que tu as envie d’utiliser, ne découvre pas l’outil sur ton projet.

Tu connais la moyenne d’âge de tes joueurs ? Il faudrait calculer la moyenne de joueurs qui jouent à ton jeu par mois/semaines, tu pourrais t’en faire un revenu principale (en mettant un bonus de 2–3 € par mois).

C’est pas si simple. J’ai évidemment déjà réfléchi au payant, plus d’une fois… mais

• Transformer un jeu gratuit en jeu payant, c’est un peu trahir les joueurs. 95% partiraient s’ils devaient tout à coup payer je pense, même si c’était 1€ par mois. J’ai trop mal vécu la « mutation » d’O-Game de « jeu gratuit où tu peux payer pour virer la pub » à « jeu où tu dois payer si tu veux vraiment gagner »alors que j’y jouais moi-même (vers 2007 pour ceux qui s’en rappellent). J’ai pas envie de faire le même genre de bêtise.
• Je m’engagerais sur une pente glissante en ce qui concerne le copyright, et je n’ai pas envie de prendre le moindre risque à ce sujet vu que je n’y connais absolument rien et que personne n’a jamais vraiment été capable de me renseigner (j’ai peur que le simple fait de poser la question me crée des problèmes)
• Je n’ai pas de pub et je compte pas en mettre. Publicité = collecte déraisonnée de données = surveillance de masse. Je ne vais pas refaire le débat ici, mais je suis convaincu que la pub devrait être éradiquée d’Internet.

Dans ce genre de situation tu risques de ne pas avoir l’impression d’avancer et de te démotiver. S’il s’agit d’un projet perso, tu devrais peut-être réfléchir de le faire au fur et à mesure en gardant le code existant. C’est-à-dire pouvoir alterner et faire étape par étape. Le faire 100% a zéro c’est une mauvaise chose, essaye d’avoir une refonte inférieur à un mois quitte à découper ton code par bundle (= paquet/collection de fonctionnalité). Sinon tu risque de t’y perdre et de perdre des joueurs.

Le code actuel n’est pas mort, ça tourne toujours. Donc pas de problème pour le faire par étapes, l’ancienne version peut rester online jusqu’à ce que j’aie fini.

Par contre c’est un gros truc monolithique. Donc un jour il faudra faire le switch d’un seul coup. ET avant le switch, difficile de tester en condition réelle pour voir si la charge tient, par exemple. C’est là tout le problème en fait.

NB : Détail important : Assure toi que la refonte à du sens technique ou que tu migres vers un outil que tu connais bien et que tu as envie d’utiliser, ne découvre pas l’outil sur ton projet.

Pourquoi ? C’est le meilleur moyen de se planter ?

ET le tout, sans aucun test

Commence par écrire des tests.

Écrire des tests n’est pas une fin en soi, mais :

• ça t’aidera à déterminer ce que devrait être tes interfaces (découpage en classes notamment) ;
• ça te permettra de définir le véritable comportement de référence de ton code ;
• ça te donnera une assurance pour faire de la refactorisation lourde en évitant de casser des choses sans t’en rendre compte ;
• et sûrement d’autres choses auxquelles je ne pense pas.

Ça a déjà été dit avant, mais il faut que ce soit praticable. Autrement dit, il ne faut pas rester embourber, ce qui passe par de la modification par petits bouts. Les avantages de ça étant :

• tu en vois le bout et donc tu restes motivé ;
• corriger certains morceaux permettra de voir d’autres problèmes à résoudre ensuite (pas à pas) ;
• ça évite de s’attaquer à des tâches incommensurables et se trouver dépassé (et abandonner).

Avec ce que tu dis, quelques petites tâches pourrait être des choses du genre :

• remplacer un morceau de code par son implémentation dans la bibliothèque standard ;
• couper une classe énorme en deux ou trois morceaux plus petits, sans changer la logique ;
• découper une méthode en deux ou trois fonctions plus petites et bien testées.

Ces quelques conseils ne viennent pas spécialement d’un projet perso, mais d’une expérience de refactorisation sur le code de ZdS. J’y ai trouvé pas mal des choses que tu vois dans ton code : du code legacy, des morceaux redondants, des fonctions trop grosses et pas claires, des fichiers mal découpés. De fil en aiguille, j’ai vu plein de choses bizarres et j’ai voulu tout faire d’un coup et j’ai échoué. Finalement, j’ai fait un morceau plus petit et j’ai réussi, ce qui ouvre la voie pour le reste. Et les tests m’ont été précieux pour me rendre compte des modifs innocentes qui cassaient pourtant le code.

Je ne parlais pas de pub ou d’avantage dans le gameplay, les avantages peuvent se transformer sous forme de skins/customisation/interface qui facilite quelques choses.

Pourquoi ? C’est le meilleur moyen de se planter ?

Tu vas t’engager dans quelques choses et, si ça ne te plait pas, le coût pour changer sera lourd.

Commence par écrire des tests.

A l’époque, je ne connaissais pas JUnit, et encore moins l’approche TDD, et d’autres bonnes pratiques pour faire du code bien isolable. Le code est tellement bien fait qu’il est difficilement testable automatiquement.

En fait, je teste … en jouant. ET bien souvent comme certains joueurs on des tas d’idées saugrenues que je n’ai pas moi-même, c’est eux qui remontent les bugs quand la fonctionnalité est en bêta.

Je suis d’accord avec ceux qui ont conseillé d’écrire des tests. Ça te permettrait de remodeler le code sereinement. Pour travailler avec le code "legacy", il existe certaines méthodes dont une que j’aime bien : le figuier étrangleur. Voici un article qui explique comment ça marche : https://martinfowler.com/bliki/StranglerFigApplication.html

Salut,

J’appuye l’avis de A-312 : une refonte de zéro en un bloc serait à mon sens très risquée et probablement vouée à l’échec. Si tu veux faire table rase du code actuel, je pense également qu’il est préférable de le remplacer progressivement, petit bout par petit bout. Peu importe la méthode, mais tu dois trouver un moyen de remplacer progressivement les tâches qu’effectue ton code (et tester les portions remplacées). Demande-toi comment tu peux construire une période de transition où deux codes différents vont devoir co-exister jusqu’à temps que le plus ancien soit totalement remplacé.

En plus des commentaires ci-dessus, je pense qu’il peut être utile de faire une autre proposition : si tu as une grosse communauté de joueur, que tu ne souhaites pas en tirer d’argent, que tu es seul développeur, et que le projet commence sérieusement à t’ennuyer, pourquoi ne pas te diriger vers un projet libre avec développement communautaire ?

Ça peut échouer totalement, il faut en être conscient, mais ça peut aussi te décharger, t’aider à résoudre de vieux bugs… Mais aussi donner une réponse aux joueurs qui souhaiteraient voir des nouveautés ou des corrections : cela est désormais directement possible.

Si ça marche, tu peux même envisager à termes de lâcher le bébé et de passer le relais, et si ça échoue, ça peut t’enlever des scrupules à le faire (dans le sens : si la communauté voulait vraiment conserver le jeu en vie, c’était faisable).

Pour travailler avec le code "legacy", il existe certaines méthodes dont une que j’aime bien : le figuier étrangleur. Voici un article qui explique comment ça marche : https://martinfowler.com/bliki/StranglerFigApplication.html

.

J’appuye l’avis de A-312 : une refonte de zéro en un bloc serait à mon sens très risquée et probablement vouée à l’échec. Si tu veux faire table rase du code actuel, je pense également qu’il est préférable de le remplacer progressivement, petit bout par petit bout. Peu importe la méthode, mais tu dois trouver un moyen de remplacer progressivement les tâches qu’effectue ton code (et tester les portions remplacées). Demande-toi comment tu peux construire une période de transition où deux codes différents vont devoir co-exister jusqu’à temps que le plus ancien soit totalement remplacé.

Vous avez globalement les deux la même idée. J’avoue que la métaphore avec le figuier étrangleur me plaît bien. Je ne connaissais pas du tout.

Vous avez raison, il faut que je réfléchisse comment je peux mettre en place quelque chose comme ça. Ca me parait être la bonne direction.

Par contre ça m’interdit d’envisager un changement de langage.

En plus des commentaires ci-dessus, je pense qu’il peut être utile de faire une autre proposition : si tu as une grosse communauté de joueur, que tu ne souhaites pas en tirer d’argent, que tu es seul développeur, et que le projet commence sérieusement à t’ennuyer, pourquoi ne pas te diriger vers un projet libre avec développement communautaire ?

J’ai pas dit que le projet en lui-même m’ennuyait. Comme dans tout projet longue durée, il y a des hauts et des bas, mais je ne suis jamais au grand jamais arrivé si bas. J’aurais déjà arrêté il y a longtemps sinon. Bien au contraire, j’ai plutôt envie d’avancer, justement en faisant du neuf avec du vieux.

De toute manière, le jeu ne pourrait jamais devenir libre. Ca signifierait que chacun pourrait créer son serveur. La communauté se fractionnerait et mourrait.

Je ne crois pas qu’un jeu en réseau avec une communauté de joueurs puisse fondamentalement devenir open source.

Par contre ça m’interdit d’envisager un changement de langage.

Si tu rends ton code modulable c’est possible, il faudrait savoir vers quel langage tu voudrais t’orienter.

De toute manière, le jeu ne pourrait jamais devenir libre. Ca signifierait que chacun pourrait créer son serveur. La communauté se fractionnerait et mourrait.

Tout dépend comment tu t’y prends, si c’est bien fait ou si tu gardes le code du méga-serveur/serveur de connexion pour toi, tu peux palier à ce genre de problème. Tu peux faire comme counterstrike (il y a de meilleur exemple, mais je n’ai pas les noms en tête) qui à un mega-serveur qui liste les serveurs.

Si tu rends ton code modulable c’est possible, il faudrait savoir vers quel langage tu voudrais t’orienter.

Actuellement c’est Java et PHP.

Il y a l’option modérée, abandonner PHP et tout mettre sur Java.

Et il y a l’option radicale, Go m’intéresse.

Un script PHP n’est pas forcement lancé par un serveur HTTP applicatif de type apache, nginx. Tu peux très bien lancer un script PHP via ton propre langage le temps de faire une transition.

Sachant que tu veux tout refaire, pourquoi ne pas partir sur un nouveau projet/une suite ? Je ne vois pas trop l’intérêt de te figer sur ce projet si ça ne te rapport rien financièrement, je veux dire tu auras peut-être autant de plaisir à refaire quelques choses de nouveau et à zéro. Si c’est juste pour garder ton nombre de joueurs, c’est un peu idiot car dans ton cas tu ne monétises pas ce potentiel de joueur, donc en avoir 0, 10, 100 ou 900 c’est juste une question de fierté.

Projet libre en développement communautaire, c’est la proposition de Gabbro. En lisant ton message, plus j’avançais dans la lecture, plus je pensais à une autre idée : Passer la main. Pas à un collectif anonyme, mais à un autre développeur.

Je ne dis pas de tout lâcher et refiler le bébé à un autre. Pas du tout, mais travailler en binôme avec un autre développeur. Encadrer le travail d’un développeur.

Mais bien sûr, je rejoins les remarques de A-312 ou Taurre : Il faut que tu réussisses à découper ce gros projet en plusieurs petits projets. Tu ne peux pas te lancer dans une refonte, qui va prendre 1 an ou 2 ou plus, parce que ça se fera sur ton temps libre (et sur le temps libre de ton binôme). Il faut pouvoir passer en production telle ou telle brique de temps en temps.

Sachant que tu veux tout refaire, pourquoi ne pas partir sur un nouveau projet/une suite ?

Je n’ai pas envie de les laisser tomber. Ca ne se fait pas. C’est gratuit mais quand même, le but n’est pas de jeter tout le monde du jour au lendemain.

JE suis le seul qui code, mais pour le reste je ne suis pas tout seul non plus: il y a de la modération, de la traduction…

Projet libre en développement communautaire, c’est la proposition de Gabbro. En lisant ton message, plus j’avançais dans la lecture, plus je pensais à une autre idée : Passer la main. Pas à un collectif anonyme, mais à un autre développeur.

Dans quel but ? C’est quoi l’intérêt ?

Aller plus vite ? Ca c’est vraiment pas garanti. IL faut que j’explique pourquoi j’ai fait ça comme ci et toutes mes logiques parfois un peu à la con… Cet autre, il va se suicider rapidement. ET puis de toute manière je n’ai personne à qui accorder ma confiance à ce point.

Mais bien sûr, je rejoins les remarques de A-312 ou Taurre : Il faut que tu réussisses à découper ce gros projet en plusieurs petits projets. Tu ne peux pas te lancer dans une refonte, … Il faut pouvoir passer en production telle ou telle brique de temps en temps.

On y revient. C’est le noeud du problème, c’est bel et bien à ça que je dois réfléchir. Le faire doucement, pas à pas, mais sûrement. Je vais aller méditer là-dessus pour ma v3.

Je crois qu’on a gentiment fait le tour. Merci beaucoup pour toutes vos réponses.