Comment gérez-vous mentalement un très long travail [fermé]

8

C'est mon premier travail dans l'industrie du jeu et ma tâche consiste à retirer un composant de jeu majeur et à en installer un plus récent.

Jusqu'à présent, cela fait 5 semaines et je ne fais que regarder les erreurs. Je pense que cela pourrait prendre des mois avant de pouvoir être compilé. Ça me fait vraiment mal. Je change juste les choses, je n'écris vraiment rien moi-même. c'est juste sans fin. Je corrige mille erreurs et neuf mille prennent leur place.

Je suis sûr que cela doit être une chose courante, donc je me demandais simplement, comment gérez-vous cela? Il ne semble pas que je puisse le décomposer en petits morceaux.

SirYakalot
la source
3
Eeek. Qui écrirait un si mauvais code qu'il faudrait des mois pour compiler!? Vous voudrez peut-être repenser la façon dont vous allez faire cela ... Une fois que cela sera compilé, ce sera plein d'erreurs logiques.
MichaelHouse
7
Cette question est probablement mieux adaptée à programmers.stackexchange.com (le cas échéant).
George Duckett
3
@GeorgeDuckett Une réponse spécifique à l'industrie du jeu pourrait être fournie à cette question qui traite des problèmes que vous ne rencontriez que la programmation dans cette industrie. Cité textuellement, la partie de la FAQ qui décide si les questions de code appartiennent ici ou sur SO offre également la sagesse: un développeur de jeux professionnel me donnerait-il une réponse meilleure / différente / plus spécifique à cette question que les autres programmeurs? Si oui, n'hésitez pas à le demander ici.
doppelgreener
5
Je vote également pour cette question de programmation générale. Il refactorise un gros désordre de code, qui se trouve être un jeu. Il a besoin de conseils généraux de programmation / refactoring, pas de conseils de développement de jeux.
Tim Holt
1
Ce message et ses réponses ne peuvent-ils pas être migrés plutôt que simplement fermés?
SirYakalot

Réponses:

21

Bienvenue dans l'industrie du jeu :)

Vous faites donc une refactorisation massive. Le refactoring massif est mal, mais ce n'est pas le sujet. On vous a probablement confié cette tâche pour tester vos nerfs de toute façon, alors n'abandonnez pas.

Ma réponse est: vous devez le décomposer en petits morceaux. Ce sera votre routine quotidienne dans quelques mois, vous devez donc apprendre à diviser pour vaincre. C'est essentiellement votre travail. Quelques suggestions:

  • Assurez-vous de bien comprendre ce qu'est ce composant censé faire . Jouez avec ce que vous devez retirer et voyez ce que cela fait, demandez à vos collègues si vos hypothèses sont bonnes.

  • Vous réécrivez ce module pour une raison. Ce n'est peut-être pas évident pour vous, mais si on vous a confié cette tâche, c'est probablement parce que quelque chose était tellement nul que les gens pensent qu'il vaut mieux recommencer. Demandez autour de vous: quelles sont ces défauts ?

  • Essayez de trouver le fonctionnalité principale du composant que vous réécrivez, sa substance même, la raison pour laquelle il existe, et commencez par faire fonctionner celui-ci. Il doit être vraiment minuscule, aussi petit que possible. Demandez à vos collègues ce qu'ils pensent que cette fonctionnalité serait. S'il s'agit d'un système GFX, faites-le simplement afficher un polygone. S'il s'agit d'un système d'animation, placez juste un os correctement. S'il s'agit d'un système d'IA, faites-le simplement jouer une animation. Etc. etc. Jetez simplement tout ce qui vous gêne et vous donne toutes ces erreurs redoutables. Ne soyez pas dérangé par les détails, faites simplement fonctionner cette fonctionnalité de base aussi rapidement que possible. Votre implémentation sera laide, pleine de bugs et de hacks et de nombres magiques et vous ne laisserez personne regarder votre code, mais ce n'est pas un problème.

  • Une fois que vous avez cette fonctionnalité de base, vous commencez déjà à vous sentir mieux. Il est essentiel de voir le résultat de votre travail le plus tôt possible 1) pour votre moral 2) pour pouvoir le tester. Alors, testez-le, testez-le, torturez-le . S'il se bloque ou montre un bug vraiment mauvais, corrigez ce problème. C'est le cœur de votre module, alors retravaillez- le un peu et nettoyez-le jusqu'à ce que vous vous sentiez à l'aise avec.

  • Montrez-le ensuite à vos collègues et demandez-leur si c'est ce dont le jeu a besoin. Demandez une révision du code : vos collègues vous parleront probablement de beaucoup de choses auxquelles vous n'avez pas pensé. Vous devrez refactoriser à nouveau pour vous assurer que votre mise en œuvre correspond à ce que veut le reste de l'équipe.

  • Ensuite, lorsque vous vous sentez prêt, choisissez l'une des autres fonctionnalités que vous avez supprimées plus tôt, rincez, répétez. Faites-le fonctionner aussi vite que possible, retravaillez, demandez une révision, retravaillez.

Je dois mettre l'accent une dernière fois sur ceci: communiquer . Demandez à vos collègues, non seulement votre chef de file, pas seulement les programmeurs, tous ceux qui utiliseront, testeront ou évalueront ce système. N'ayez pas peur de poser des questions stupides: en cas de doute, il est toujours préférable d'obtenir les informations dès maintenant que d'attendre des semaines pour une réunion ou un examen.

La réalité de la programmation de jeux est que vous n'allez pas créer de nouveaux systèmes brillants tous les jours, c'est un travail de rester concentré et de faire les choses rapidement et efficacement. Ressaisissez-vous, mettez-vous au travail et bonne chance!

ÉDITER

Il y a des informations supplémentaires que je trouve utiles dans le commentaire de Leo et la réponse de Dhasenan, je les répète sans vergogne pour compléter cette réponse.

Je n'ai pas écrit sur la façon de gérer les interdépendances . Le module que vous réécrivez est probablement profondément couplé avec le reste du jeu, c'est pourquoi vous obtenez autant d'erreurs lorsque vous changez quelque chose. Il y a donc deux solutions:

  • S'il n'y a que quelques dépendances, alors vous avez de la chance. L'ancien et le nouveau module peuvent être conservés en parallèle pendant un certain temps, vous pouvez même avoir un commutateur pour vos utilisateurs afin qu'ils puissent décider de basculer entre l'ancien et le nouveau module chaque fois qu'ils en ont besoin. Placez simplement un commutateur quelque part, dans un fichier de configuration ou dans un menu de débogage, et utilisez-le partout où votre module est connecté au reste du jeu. Lorsque votre nouveau module est prêt pour la production, activez le commutateur par défaut. Plus tard, lorsque l'ancien module n'est plus utilisé ou lorsque la production doit continuer, retirez l'ancien module et le commutateur.

  • S'il y en a beaucoupdépendances, vous devez les débrancher et les rebrancher un par un. Essayez de garder les deux modules en arrière-plan, et chaque fois que vous obtenez une nouvelle fonctionnalité, passez au nouveau module pour cette fonctionnalité. C'est à dire débrancher et rebrancher ce qui est lié à cette fonctionnalité. Cela vous prendra un certain temps car c'est probablement plus de travail que de changer un seul appel de fonction: certaines structures de données peuvent changer, le flux du programme peut changer, etc. Mais c'est toujours mieux que de tout réécrire une fois et de prendre des semaines pour tuer la bête de compilation. Si c'est vraiment impossible de garder les anciens et les nouveaux modules en parallèle parce que votre module est si vital pour le jeu, vous pourriez envisager de réécrire en place. Mais attention, cela pourrait signifier que si les défauts se trouvent dans l'interface de l'ancien module, vous vous retrouverez avec les mêmes défauts. Quoi qu'il en soit, si cela se produit,

S'il y a quelque chose de spécifique au développement de jeux vidéo, c'est celui-ci: nous ne faisons pas de science fusée, ou un travail de recherche compliqué, nous faisons partie d'un processus créatif. Lorsque vous faites quelque chose, vous devez créer une première version le plus rapidement possible afin qu'elle puisse être testée, jouée, désapprouvée et modifiée. Vous ne pouvez pas passer des semaines à faire "un très long travail" sans en livrer un peu.

Laurent Couvidou
la source
Bonne réponse, clairement applicable non seulement aux jeux mais à tout projet.
Tim Holt
1
+1, à retenir pour moi: ne faites pas que tester , mais torturez le code :) Pour moi, c'est un excellent conseil.
Stefan Hanke
5
+1, vous DEVEZ diviser une grosse refactorisation en petits morceaux. Je suis tout à fait d'accord pour dire que c'est le seul moyen de mener à bien une refactorisation massive. Idéalement, changez le morceau de code par morceau, en vous assurant que chaque changement laisse le système fonctionner (cela réduira considérablement le nombre de bogues). Si cela est impossible pour la fonctionnalité complète, faites-le au moins pour certaines fonctionnalités de base. Tout changer à la fois est un moyen sûr de créer des tonnes de bugs difficiles à trouver.
Leo
1

Vous devez diviser votre tâche, mais personne ne vous conseille sur la façon de procéder.

  • Les nouveaux et les anciens modules fonctionnent-ils ensemble? Autrement dit, pouvez-vous compiler votre projet avec les deux? Cela vous permettra au moins de compiler et probablement d'exécuter des tests automatisés à certains jalons.
  • Ecrivez-vous le nouveau module? Ou est l'ancien code que vous possédez? Réécriture en place (dans la mesure où l'API externe reste la même). Si vous corrigez une fonction à la fois, vous devriez pouvoir continuer à utiliser l'API du bâtard combiné, dans une certaine mesure.
  • Y a-t-il d'autres projets dans l'entreprise qui feront une transition similaire? Écrivez des enveloppes autour de ces modules pour faciliter le processus la prochaine fois. Il pourrait être utile de le faire dans l'intervalle.
  • Pouvez-vous commenter ou éviter de compiler des morceaux de votre chaîne de dépendance? Si vous avez un demi-million de lignes de code au total, vous pouvez peut-être le diviser en vingt morceaux qui se compilent indépendamment, en faire fonctionner un en quelques semaines, puis passer à la suivante. Peut-être pas des morceaux totalement indépendants tout le temps, mais vous pouvez le faire dans l'ordre des dépendances.

Aussi: demandez conseil à votre manager. Je commencerais probablement par décrire le problème: il faut tellement de temps pour que les choses se compilent correctement qu'il est difficile de suivre les changements, ce qui rendra le débogage plus difficile une fois que vous aurez quelque chose à tester. Ensuite, je mentionnerais une solution potentielle et je demanderais: "Comment recommandez-vous que j'implémente cette solution, ou existe-t-il une meilleure façon de procéder entièrement?"

dhasenan
la source