04-02-2014, 12:25 AM
D'une maniere generale, je "griffonne" les grandes lignes (que ca soit du jeu complet, ou a chaque fois d'une nouvelle fonctionnalite). Une fois que je sais a peu pres ou je veux aller, je stock (ou l'inverse) les donnees dont je vais avoir besoin (petit MPD rapide). Apres je code la (ou le groupe de) fonctionnalite(s), pas trop crado, mais sans chercher l'optim ultime. Je test, je re-test, je re-re-test, je fais tester (ca aide d'avoir quelques potes sur une "alpha"). Quand ca marche, j'optimise tout de suite.
J'ai pas vraiment de doc centralisee, plutot plein de feuilles papier / quelques fichiers texte/markdown qui mis bout a bout seraient probablement incomprehensibles ! Mais qui m'ont bien aide sur le moment. Ah oui, et je commente mon code (meme tout seul dessus ca aide 3 mois plus tard quand un tester tombe sur LE cas qui bug !).
Pour ce qui est de l'ordre back/front, en general je fais le back et une ebauche "moche" du front, quand le back fonctionne correctement je fais le front propre (c'est cette version qui est testee par les joueurs). Ensuite a moins d'un besoin ergonomique profond ou quelques menus changement de virgule je touche plus au front.
(En fait on retrouve le make it work / make it right / make it fast de Sephi)
Sinon, je jongle pas dans une meme heure avec plusieurs langages (enfin pas trop), mais etant seul sur le projet, et utilisant PHP, MySQL (y compris des grosses procedures stockees) & du NodeJS j'ai pas vraiment le choix. Et finir un element sans avancer les autres au fur et a mesure est absolument hors de question, trop ennuyeux a mon gout. J'ai besoin du "renouveau" constant de passer d'un gros bout de php a l'ecriture d'un morceau pur SQL, pour le Node je debute encore... mais ca m'amuse bien !
Le drame c'est quand mes testers viennent me voir avec une phrase du genre : "ton truc la c'est nul" (avec des arguments pertinents pour soutenir la chose!). En general, c'est 2/3 jours de reflexion avec eux, et pour etre sur de pas refaire la meme chose: delete de tout le code associe. C'est d'ailleur une methode que j'emploi assez souvent: si apres avoir cherche pendant un certain temps je trouve pas la solution a un probleme dans le code, j'efface et recommence ... J'ai de la chance, j'ai pas encore trouve un probleme fondamental dans le jeu complet !!
Pour ce qui est de la "pression" ou des deadlines: c'est en general a la pause cafe du matin: bon les gars, semaine prochaine je vous livre tel ou tel truc (souvent un truc nouveau, pas encore commence !). Pas d'engagement contractuel, mais un peu une sorte de promesse quand meme.
Dans l'ensemble je m'eloigne pas trop des idees originales, par contre je ne respecte pas forcement un ordre hierarchique. Il est tres courant que je refactor/re-oriente un morceau qui me turlupine plutot que d'avanceer sur une nouvelle fonction prevue. En general c'est motive par un probleme de gameplay, et parfois, quand je me suis rate, un probleme de perf. Je considere que le web est quelquechose d'instantane, donc attendre le lancement de telle action 1.5 sec est potentiellement inadmissible: quand je clic je veux une reponse tout de suite. Qu'une flotte mette N heures a arriver a destination ok, mais que le lancement de la dire flotte prenne 1.5/2sec PAS ok ! Et comme j'ai un tout petit serveur pour l'hebergement (ovh KS2G 2013 pour ceux qui connaissent) l'optim se voit tres rapidement. C'est d'ailleurs a cause de ca que je switch progressivement certain morceaux vers du NodeJS: optim des traitements.
Donc je n'hesite pas a remettre en question certains choix technique initiaux quand j'en atteints les limites. Mais comme naturellement je decompose chaque "gros" probleme en plusieurs "petits" je code naturellement modulaire (trop meme parfois !) du coup je change un bout sans reel impact profond sur le reste. Au final, je reste dans l'idee initiale: le plus de "temps reel" possible, le moins d'"estimations" possible.
J'ai pas vraiment de doc centralisee, plutot plein de feuilles papier / quelques fichiers texte/markdown qui mis bout a bout seraient probablement incomprehensibles ! Mais qui m'ont bien aide sur le moment. Ah oui, et je commente mon code (meme tout seul dessus ca aide 3 mois plus tard quand un tester tombe sur LE cas qui bug !).
Pour ce qui est de l'ordre back/front, en general je fais le back et une ebauche "moche" du front, quand le back fonctionne correctement je fais le front propre (c'est cette version qui est testee par les joueurs). Ensuite a moins d'un besoin ergonomique profond ou quelques menus changement de virgule je touche plus au front.
(En fait on retrouve le make it work / make it right / make it fast de Sephi)
Sinon, je jongle pas dans une meme heure avec plusieurs langages (enfin pas trop), mais etant seul sur le projet, et utilisant PHP, MySQL (y compris des grosses procedures stockees) & du NodeJS j'ai pas vraiment le choix. Et finir un element sans avancer les autres au fur et a mesure est absolument hors de question, trop ennuyeux a mon gout. J'ai besoin du "renouveau" constant de passer d'un gros bout de php a l'ecriture d'un morceau pur SQL, pour le Node je debute encore... mais ca m'amuse bien !
Le drame c'est quand mes testers viennent me voir avec une phrase du genre : "ton truc la c'est nul" (avec des arguments pertinents pour soutenir la chose!). En general, c'est 2/3 jours de reflexion avec eux, et pour etre sur de pas refaire la meme chose: delete de tout le code associe. C'est d'ailleur une methode que j'emploi assez souvent: si apres avoir cherche pendant un certain temps je trouve pas la solution a un probleme dans le code, j'efface et recommence ... J'ai de la chance, j'ai pas encore trouve un probleme fondamental dans le jeu complet !!
Pour ce qui est de la "pression" ou des deadlines: c'est en general a la pause cafe du matin: bon les gars, semaine prochaine je vous livre tel ou tel truc (souvent un truc nouveau, pas encore commence !). Pas d'engagement contractuel, mais un peu une sorte de promesse quand meme.
Dans l'ensemble je m'eloigne pas trop des idees originales, par contre je ne respecte pas forcement un ordre hierarchique. Il est tres courant que je refactor/re-oriente un morceau qui me turlupine plutot que d'avanceer sur une nouvelle fonction prevue. En general c'est motive par un probleme de gameplay, et parfois, quand je me suis rate, un probleme de perf. Je considere que le web est quelquechose d'instantane, donc attendre le lancement de telle action 1.5 sec est potentiellement inadmissible: quand je clic je veux une reponse tout de suite. Qu'une flotte mette N heures a arriver a destination ok, mais que le lancement de la dire flotte prenne 1.5/2sec PAS ok ! Et comme j'ai un tout petit serveur pour l'hebergement (ovh KS2G 2013 pour ceux qui connaissent) l'optim se voit tres rapidement. C'est d'ailleurs a cause de ca que je switch progressivement certain morceaux vers du NodeJS: optim des traitements.
Donc je n'hesite pas a remettre en question certains choix technique initiaux quand j'en atteints les limites. Mais comme naturellement je decompose chaque "gros" probleme en plusieurs "petits" je code naturellement modulaire (trop meme parfois !) du coup je change un bout sans reel impact profond sur le reste. Au final, je reste dans l'idee initiale: le plus de "temps reel" possible, le moins d'"estimations" possible.