Quels facteurs devraient influencer la façon dont je détermine quand abandonner un petit projet avec un ami? [fermé]


30

Je me suis retrouvé dans une situation difficile ces derniers temps. Je travaille sur un jeu avec un copain de programmation depuis près de 8 mois maintenant. Nous avons tous deux commencé en tant que nouveaux arrivants à la programmation vers août de l'année dernière, il est un étudiant CS de 2e année, je suis un technicien de support informatique par métier et je suis un programmeur autodidacte avec une multitude de livres et d'abonnements en ligne.

Le problème que j'ai constamment vu est que lorsque nous écrivons un morceau de code, il sera souvent un peu piraté ensemble, aura de nombreux défauts, et s'il s'agit d'un tout nouveau concept pour l'un d'entre nous, plein de solutions naïves. C'est bien, nous apprenons, je m'attends à ce que nos deux codes soient un peu piratés ensemble au premier ou au deuxième passage. Le problème se pose lorsqu'il s'agit de corriger et de refactoriser réellement ces comportements piratés.

Mon partenaire conservera son comportement fraîchement pavé, refusant ouvertement de voir toute erreur au moment où elle commencera à fonctionner. Prétendant la perfection à partir d'un morceau de structure, je ne peux même pas essayer d'utiliser même s'il y avait des commentaires et des méthodes et des champs correctement nommés. Peu importe mes efforts, je ne peux pas lui faire voir les défauts manifestement évidents qui empêcheront d'autres changements ou une expansion du comportement sans le casser complètement et tout ce qui y est si étroitement lié pourrait aussi bien être dans la même classe. Les solutions piratées restent perpétuellement piratées, les conceptions mal pensées restent telles qu'elles étaient lorsqu'elles ont été conçues et testées pour la première fois.

Je passe autant de temps à garder du nouveau code que je l'écris moi-même, je ne sais plus quoi faire. Mon partenaire l'a perdu ce soir et a clairement indiqué que peu importe quoi, peu importe la référence, quelle que soit la pratique courante, quelle que soit la preuve irréfutable, son code restera comme il l'avait fait pour la première fois. Même si des livres entiers ont été écrits sur les raisons pour lesquelles vous voulez éviter de faire quelque chose, il refusera de reconnaître leur validité en prétendant que ce n'est que l'opinion de quelqu'un.

J'ai un intérêt direct dans notre projet, mais je ne suis pas sûr de pouvoir continuer à travailler avec mon partenaire. Il me semble que trois options s'offrent à moi.

  • Arrêtez de vous soucier du fonctionnement de la base de code au-delà du point de compilation, et essayez simplement de maintenir et d'analyser un comportement à peine boiteux. En espérant qu'une fois que les choses commenceront à se casser sérieusement, il le verra et essaiera de faire plus que simplement mettre un panda sur le design fondamentalement défectueux.
  • Gardez les arguments sans fin sur les problèmes qui ont été résolus il y a une décennie par d'autres personnes beaucoup plus capables.
  • Arrêtez de programmer sur ce projet, abandonnant près de 10 000 lignes de mon code et d'innombrables heures asservies à la conception et essayez de trouver un nouveau projet par moi-même.

Quelle approche puis-je adopter pour déterminer s'il vaut la peine de poursuivre ce projet avec cette personne? Ou quels facteurs devraient influencer ma décision? Nous avons écrit beaucoup de code et je ne veux pas y renoncer à moins que cela ne soit nécessaire.


3
Qu'en est-il de l'élaboration de directives de style de codage convenues et d'un processus de révision du code? Évitez les problèmes litigieux, insérez simplement suffisamment dans la norme pour que vous puissiez tous les deux l'accepter.
Brandin

25
Quatrième option (si c'est sous une licence permissive): forkez le code et continuez à travailler par vous-même.
Robert Harvey

4
Comment le code est-il autorisé? Pouvez-vous le bifurquer et continuer avec quelqu'un d'autre?
Jaydee

14
Comme @enderland le mentionne dans sa réponse, il y a un drapeau rouge absolument énorme dans ce que vous avez écrit: "Mon partenaire l'a perdu ce soir, et a précisé que peu importe quoi, peu importe la référence, peu importe la pratique courante, peu importe la preuve irréfutable, son code restera tel qu'il l'a fait. " Si vous pouvez vous en sortir, faites-le. Quiconque mérite vraiment de travailler avec aura l'humilité d'accepter que parfois ils se tromperont.
Richard J Foster

3
Peu importe ce que vous décidez, les 10 000 lignes de code ne sont pas perdues: pensez à ce que vous avez appris en les écrivant; pensez au plaisir que vous avez eu pendant le codage horaire; et, appliquer ce que vous avez appris dans une troisième / quatrième / n + 1ème (forcée) itération pourrait même faire mieux que la version actuelle. De plus, si vous savez quoi écrire 10 000 lignes de code, vous pouvez écrire 10 000 lignes en un temps relativement court; c'est souvent le fait de savoir quoi écrire pour faire fonctionner les choses qui prend le plus de temps.
Kasper van den Berg

Réponses:


26

Un code imparfait expédié est meilleur qu'un code parfait sur le tableau blanc qui n'est jamais expédié.

Cela étant dit...

Ceux d'entre vous qui ont plus d'expérience ou qui ont vécu des situations similaires. Qu'est-ce que tu as fait? Que recommanderiez-vous que je fasse?

Je considérerais ce qui suit.

  • Quel est le but de ce projet? Amusement? Argent? Apprendre?
    • Réalisez-vous réellement cet objectif?
  • Cette personne vous permet-elle réellement de mieux atteindre vos objectifs?
  • Dans quelle mesure êtes-vous réellement prêt à expédier?
  • Ces problèmes vous empêchent -ils de lancer? Ou s'agit-il d'une fierté personnelle?
  • Y a-t-il des avantages à travailler avec quelqu'un sur une base volontaire quand c'est frustrant?

Arrêtez de programmer sur ce projet, abandonnant près de 10 000 lignes de mon code et d'innombrables heures asservies à la conception et essayez de trouver un nouveau projet par moi-même

Tenez compte de ce qui précède, essayez de réfléchir au travail supplémentaire requis.

Vous devez déterminer vos priorités et déterminer si les problèmes liés au travail avec cette personne en valent la peine. Nous ne pouvons pas comprendre cela pour vous.

Mon partenaire l'a perdu ce soir et a clairement indiqué que peu importe quoi, peu importe la référence, quelle que soit la pratique courante, quelle que soit la preuve irréfutable, son code restera comme il l'avait fait pour la première fois.

Vous savez que vous ne voulez pas travailler avec ce type de personne.

Vous faites un projet comme celui-ci probablement parce que vous voulez apprendre la programmation et trouver l'élégance dans le métier lui-même.


1
Merci pour votre réponse. J'accomplis le but de m'amuser (en dehors des luttes intestines) et d'apprendre. Le temps qu'il y a à gagner de l'argent est une histoire complètement différente. Il aide à atteindre mes objectifs, mais je crois que je pourrais encore les atteindre par moi-même, il aide à la motivation. Le jeu est un excellent exemple de fluage de fonctionnalités, je n'ai honnêtement aucune idée du moment où il peut être expédié. Mon partenaire essaie depuis des mois de pousser le passage de la 2D à la 3D, je refuse car nous avons déjà longtemps dépassé notre périmètre.
Douglas Gaskell

1
Je serais prêt à abandonner le projet, s'il n'était que le mien, il aurait été abandonné il y a des mois. Mon facteur de motivation pour continuer est d'avoir quelqu'un avec qui travailler, même si les luttes intestines me font remettre cela en question certains jours. La seule chose qui me retient de l'abandonner est une amitié comme une connexion avec lui en dehors du codage, je préfère éviter de jeter ça avec le projet. Bien sûr, ce n'est pas une explication très logique, puisque leurs sentiments personnels sont impliqués, cela embrouille vraiment mes capacités de prise de décision.
Douglas Gaskell

1
le moyen le plus rapide de perdre un ami est de travailler avec lui sur un pied d'égalité!

58

Cela peut être une chose culturelle. Dans certaines cultures, admettre que vous avez fait une erreur est inouï, et demander à quelqu'un d'admettre qu'il a fait une erreur est la chose la plus grossière que vous puissiez faire. Si c'est cette situation, fuyez.

D'après mon expérience avec des gens très intelligents, si vous leur dites que quelque chose qu'ils font est loin d'être parfait, ils vous donneront soit (1) une raison correcte et facile à comprendre pourquoi ce qu'ils font est vraiment bien, (2) dites vous qu'ils savent que c'est mal, mais ils n'ont pas le temps de le réparer à cause des priorités, ou (3) merci de le signaler et de le réparer.

Refuser d'apprendre est le pire attribut qu'un développeur de logiciels puisse avoir. Laissez-le. La vie est trop courte et précieuse pour perdre votre temps avec lui.


Merci Gnasher, je vois le numéro 2 périodiquement, bien que nous n'ayons pas de calendrier réel, donc je ne suis pas sûr de la validité d'une réponse. Je vais dormir là-dessus et voir ce que je pense dans le matin, cela nécessite beaucoup de délibérations avant de prendre une décision.
Douglas Gaskell

1
"Si c'est cette situation, fuyez." - et de manière générale, si vous ne pouvez pas atteindre un consensus proche de vos objectifs, vous ne pouvez pas coopérer avec quelqu'un. On dirait qu'il ne consentira pas à ce que vous changiez "son" code, peu importe la raison.
Steve Jessop

Eh bien, il semble que la pression du temps ne soit pas la raison pour refuser les changements.
gnasher729

1
C'est une excellente réponse. Vous ne pouvez pas forcer quelqu'un à changer ses habitudes! Cependant, il semble qu'il y ait beaucoup de temps et d'efforts consacrés au projet de son côté ainsi que le vôtre. Je pense peut-être qu'il peut ne pas vouloir changer son code parce qu'il ne comprend pas la façon dont vous pensez que cela devrait être fait. C'est soit ça, soit il est têtu, mais s'il EST qu'il ne le comprend pas, essayez de garder à l'esprit qu'il peut être frustré et pensez que vous lui "parlez", même si vous pensez très bien. Mon conseil est d'essayer d'en discuter avec lui quand vous en aurez envie.
zfrisch

^ + Il est facile d'être offensé par quelqu'un lorsque vous commencez au même niveau et qu'il vous surpasse en compétences. Je ne dis pas que c'est certainement le cas, mais il semble certainement que cela puisse avoir quelque chose à voir avec cela.
zfrisch

12

La façon la plus simple est peut-être d'amener quelqu'un d'autre dans le projet - soit vous vous trompez et sa base de code est tout simplement trop intelligente pour vous, soit vous avez raison et c'est trop intelligent pour tout le monde. Vous le découvrirez bientôt et vous obtiendrez une sauvegarde s'il s'avère être un code de niveau détritique et compliqué pour les programmeurs juniors.

D'un autre côté, un produit qui fonctionne vaut un nombre illimité d'années de code finement réglé, élégant et clair. Faites le jeu, expédiez-le, partez ensuite - laissez-le le maintenir et ne travaillez pas sur la v2.


2
Merci pour la réponse. C'est drôle que tu mentionnes ton premier point. Il essaie de trouver et d'amener un programmeur novice à qui il peut enseigner pour l'aider dans le projet. Je ne pouvais m'attendre à ce que cela se produise horriblement que là où deux personnes suivant le même style de pirater et d'oublier. J'aime la deuxième option, fais-la, expédie-la, puis laisse-la. Le problème que je pourrais rencontrer est que nous sommes en train de créer une LLC afin d'avoir un nom pour expédier notre jeu. Les deux utilisations auront bien sûr une part de 50%. Cependant, je pourrais simplement le terminer et continuer. Le projet est grand, cela pourrait prendre un certain temps.
Douglas Gaskell

20
Vous ne pas en aucun cas souhaitez entrer dans une relation d'affaires juridique liant personne comme ça.
gnasher729

3
@ douglasg14b amener un junior pour enseigner .. pauvre enfant. Je vous suggère de faire venir un gars expérimenté "car il se mettrait beaucoup plus vite et aiderait à terminer le produit". Fixez votre objectif sur une ligne d'arrivée - ou avez-vous tous les deux l'intention de travailler sur ce passe-temps pour toujours et à jamais? (vu que cela se produit, jusqu'à ce qu'il soit annulé)
gbjbaanb

J'ai l'intention de le finir, définitivement. Bien que je pense que c'était un projet beaucoup trop important pour être le premier. Il a commencé comme une conception simple, il n'était pas censé être à la hauteur de l'échelle actuelle. La limite de notre portée est constamment repoussée par le fluage des fonctionnalités par mon partenaire, je suis en partie responsable de cela parce que je le permets et même d'accord avec certaines fonctionnalités. La portée est telle que si on les laisse seuls, nous envisageons probablement de les terminer d'ici un an. Heureusement avec la façon dont je l'ai programmé, des pièces peuvent facilement être retirées et placées dans d'autres projets plus tard.
Douglas Gaskell

4
Considérez le code comme appartenant au projet, pas à vous. Si vous êtes copropriétaire du produit, vous pouvez réutiliser tout le code pour votre prochain projet. Si vous ne savez pas à qui appartient quoi, discutez maintenant. Bonne chance.
gbjbaanb

9

Voici quelques idées même si certaines s'excluent mutuellement.

  • Responsabilités de source distinctes. Si vous travaillez sur le module A et lui sur le module B, vous pouvez rivaliser avec vos différents styles. Libère-t-il souvent des fonctionnalités de travail? At-il atteint un point où il a besoin de réécrire son code à partir de zéro? Refactorisez le code de vos modules et ne le touchez pas,

  • Laissez-le faire l'entretien de son pire code. S'il le fait avec succès, vous avez évité une tâche terrible. S'il n'est pas capable, il ressentira la douleur.

  • Considérez-le d'un point de vue utilisateur ou professionnel. Dans certains cas, vous n'avez besoin que d'un produit viable que Google ou Microsoft pourraient acheter. Dans d'autres, vous lancez un produit sur le marché et soutenez des milliers de clients avec du code bogué ou piraté sera un enfer. Ce n'est pas pareil si votre code contrôle les drones avec des missiles nucléaires ou fait des vidéos heureuses pour les adolescents.

  • Il fait les cours, vous faites les tests. La refactorisation de code avec des tests est plus simple et plus sûre. De cette façon, vous n'aurez pas besoin de regarder à l'intérieur du code uniquement la barre Junit. Cela suppose que A) vous programmez des tests, B) que votre code de collègue soit testable. Si vous trouvez difficile de construire les tests pendant la phase de codage, cette dernière sera pire.

  • Allez ensemble à la formation ou aux événements. Lorsque vous ne connaissez pas la bonne façon, c'est tout à fait naturel, utilisez la seule façon que vous connaissez. Voir le code des autres ne résoudra peut-être pas tout mais ne fera pas de mal à essayer.

  • Trouvez vos forces complémentaires. Le refactoring peut parfois être amusant. S'il écrit des choses qui fonctionnent au moins, vous pourriez alors refactoriser. Il peut faire des pointes pour explorer des solutions qui ne se terminent pas en code de production.

  • Il pourrait ne pas vouloir réécrire le code mais il pourrait accepter d'écrire mieux le nouveau code. Je comprends que la réécriture est difficile, ennuyeuse et peut casser des choses. Cultivez des îles de qualité. De cette façon, il aura de bons exemples de la façon de faire les choses.

  • Utilisez la règle du boy-scout . Ne laissez pas les choses intactes, sauf si vous devez y travailler. Si un module est mal écrit mais fonctionne et n'a pas besoin de le changer, laissez-le comme ça. Si vous devez corriger un bogue ou compléter une fonctionnalité, améliorez-le un peu. Après un certain temps, les 20% de classes que vous modifiez 80% du temps s'amélioreront. Plus d'îles de qualité.

Nous ne pouvons pas suggérer quelle est la meilleure solution sans vous connaître tous les deux. Bonne chance.


4

Ok, voici une réponse que vous n'aimerez probablement pas.

Ne «corrigez» pas le code à moins qu'il n'implémente pas la fonctionnalité.

Voici mon raisonnement. Vous essayez probablement de gagner de l'argent. Pour gagner de l'argent, vous devez expédier rapidement les fonctionnalités terminées. Personne ne vous paiera plus cher pour un jeu informatique «bien codé».

La plupart des entreprises ont le même problème. Refonte du code existant pour le rendre «meilleur», parfois même objectivement meilleur en termes de vitesse ou de fiabilité OU écrire de nouvelles fonctionnalités.

99% du temps, ils choisissent d'écrire les nouvelles fonctionnalités parce que le résultat d'une simple analyse coûts-avantages.


15
Cela relève cependant de l'argument de la "dette technique", n'est-ce pas? Lorsque vous écrivez cette nouvelle fonctionnalité (ou modifiez une fonctionnalité existante), cela prend-il trois fois plus de temps et produit-il dix fois plus de bugs que si vous aviez suivi votre refactoring? Si oui, alors peut-être que le refactoring était une fausse économie.
Ben Aaronson

1
On pourrait le penser, mais j'ai travaillé dans de nombreuses entreprises prospères et je ne vois (presque) jamais de refactoring à haute priorité. Ma conclusion est que cela ne rapporte tout simplement pas.
Ewan

C'est assez juste et je suis sûr qu'il y a une gamme d'opinions à ce sujet, il semble que ne pas aborder cette question d'une manière ou d'une autre soit une omission importante de la réponse. Je peux aussi me tromper, mais en lisant entre les lignes de la question, je pense que le mauvais code dont l'OP s'inquiète peut être bien pire que le type de code auquel vous pensez.
Ben Aaronson

heh, ouais! mais il semble également que le coût des modifications soit très élevé. Dans ma réponse, j'essaie de donner l'objectif «êtes-vous là pour l'argent? réponse, plus ma vision subjective de l'endroit où se situe la balance des probabilités
Ewan

1
Cela est raisonnable dans certains cas, mais si le «code de travail» d'une personne oblige une autre personne à consacrer 2x plus de temps à son code ou à l'intégration de systèmes ensemble ou à des travaux futurs, il ne s'agit plus d'une simple décision «navire contre non navire». Beaucoup de projets à grande échelle meurent parce qu'ils ne prennent pas les décisions pour le faire correctement plutôt que rapidement.
enderland

3

J'aime toutes les réponses jusqu'à présent. Reprenant l'un des points de la réponse d'Enderland :

Y a-t-il des avantages à travailler avec quelqu'un sur une base volontaire quand c'est frustrant?

Je voudrais prendre ce temps pour me connecter à l' échange de pile de révision de code . C'est un endroit merveilleux où vous pouvez faire critiquer votre code par des professionnels. Et honnêtement, beaucoup de revues de code y sont extrêmement utiles pour les personnes impliquées - les demandeurs, les répondeurs et ceux qui trébuchent et les lisent. Vous obtenez rarement des critiques aussi utiles dans un cadre professionnel (ce qui peut être le cas dans les endroits où j'ai travaillé pour une raison quelconque).

Mon conseil est de publier une partie de votre code pour révision. Je ne suggérerais pas de l'utiliser comme munitions pour prouver que ce type a tort - je doute qu'il le prenne à cœur - mais vous pouvez obtenir des informations très utiles à la fois sur le code que vous avez écrit et sur le code qu'il a écrit. Je recommanderais de soumettre les morceaux de code que vous combattez le plus. Selon toute vraisemblance, vous vous trompez tous les deux dans une certaine mesure et vous pouvez utiliser l'examen comme moyen de faire intervenir un tiers objectif. Cela permettra d'accomplir plusieurs choses:

  • Vous pouvez vous déconnecter de la tension émotionnelle de la situation.

  • Vous obtenez des conseils professionnels en temps réel. Un gros coup de pouce à ce que vous apprenez.

  • Quelqu'un vous dira que vous vous trompez. Ce qui est bien, car toute personne qui fait de la programmation pour n'importe quelle durée va entendre cela. Vous pouvez le gérer mal comme ce gars avec qui vous travaillez, ou vous pouvez apprendre à y faire face.

Je pense que si vous utilisez les revues de code dans le bon sens, vous avez beaucoup à gagner en traitant avec cette personne extrêmement frustrante. Et il est beaucoup plus interactif qu'un livre ou un site Web qui dit "faites cela, car c'est la bonne façon la plupart du temps".

De même, il y a l' échange de piles de développeurs de jeux . Pas tellement un endroit pour publier du code pour examen, mais pour poser des questions sur les concepts / idées avec lesquels vous avez du mal. Encore une fois, cet endroit est extrêmement utile pour toutes les personnes impliquées.

Vous avez peut-être déjà vu ces deux sites; Je voulais juste m'assurer qu'ils faisaient partie de votre ensemble d'outils.


2

Cela semble assez désespéré. J'abandonnerais probablement et continuerais si j'y pensais comme vous; il y a certainement un temps pour s'éloigner et vous pouvez être là.

Si vous n'êtes pas encore prêt à vous éloigner, vous devez trouver un moyen de parvenir à un meilleur accord sur votre processus. Il semble que vous ayez des normes de codage, mais pas des normes convenues. La prochaine fois que vous arriverez à un carrefour, la prochaine fois que vous voudrez jouer avec un peu de code et que votre copain voudra le laisser tranquille, tirez pour une conversation selon les lignes suivantes:

douglas: Je veux le changer parce que X, qui est juste ici dans nos directives.

mon pote: C'est bien comme ça.

douglas: Vous dites donc que nous devrions changer les directives?

mon pote: Non, je pense juste que ça va comme ça.

douglas: Alors, quelles sont les lignes directrices?

buddy: Je ne sais pas - tu les as écrites.

douglas: Quelles directives écririez-vous?

copain: Je n'écrirais pas de lignes directrices. C'est une perte de temps.

douglas: Donc, nous devrions simplement jeter les lignes directrices et écrire les conneries que nous pensons à l'époque?

mon pote: Ce n'est pas de la merde.

douglas: C'est parfait? Est-ce que c'est idéal?

copain: Il fait le travail; Passons à la fonctionnalité suivante.

douglas: Y a-t-il quelque chose sur quoi nous pouvons nous mettre d'accord, que X est un bon code et Y est un mauvais code?

mon pote: Laisse-moi tranquille; Je veux juste coder!

Eh bien, cela ne s'est pas bien passé, n'est-ce pas? Je suppose que le sentiment que j'ai est que toi et Buddy voulez des choses différentes. Si vous êtes d'accord sur quelque chose, tant mieux; partir de là et construire dessus. Mais vous ne pouvez pas lui faire accepter de vouloir ce que vous voulez - pas plus que vous ne pourriez vous faire vouloir ce qu'il semble vouloir. Si vous pouvez trouver ce désir commun et en arriver à un accord commun à partir de là, vous pouvez peut-être travailler ensemble.

douglas: Qu'est-ce que tu veux?

copain: Je veux juste coder.

douglas: Je veux aussi coder, mais je veux être fier de mon code.

copain: Je suis fier de mon code.

douglas: Voici une fonction dont je suis fier - qu'en pensez-vous?

copain: Eh bien, ça va, mais vous ne devriez pas recalculer X à l'intérieur de la boucle; c'est inefficace.

douglas: Êtes-vous en train de dire que nous devrions toujours calculer des valeurs constantes en dehors des boucles?

copain: Eh bien, duh!

douglas: Pensez-vous que cela devrait figurer dans nos directives?

mon pote: Bien sûr.

douglas: OK, je vais l'ajouter à nos directives, et je mettrai à jour mon code ...

douglas: Comment ça va maintenant?

mon pote: Très bien.

Maintenant, Buddy contribue aux directives (même indirectement), et il a donc un peu de sentiment d'appartenance. Peut-être - juste peut-être - qu'il commencera à les prendre plus au sérieux. Je pense que je serais enclin à essuyer l'ardoise et à recommencer avec les directives, en laissant la plupart ou la totalité d'entre elles venir de Buddy au début. Allez-y et écrivez du code de merde pour qu'il ressente le besoin d'ajouter aux directives; qu'ils viennent de lui. Peut-être qu'alors il commencera à comprendre la raison de cela.

Mais si vous préférez abandonner et passer à autre chose - ce n'est peut-être pas une si mauvaise option non plus.


2

En supposant que vous décidiez d'abandonner le projet:

  • Forkez le code et refactorisez-le, en l'utilisant comme un élément de portefeuille «avant / après»
  • Étant donné que l'objectif était (principalement ou partiellement) d'apprendre la programmation et qu'apprendre quelque chose prend 2 à 4 fois aussi longtemps que faire quelque chose que vous savez déjà, ce travail n'est pas vraiment gaspillé.
  • L'attachement aux coûts irrécupérables (l'investissement que vous avez déjà fait dans une entreprise avant d'apprendre que c'était une mauvaise idée) est l'une des erreurs humaines les plus courantes dans la prise de décision
  • Pour garder l'amitié, définissez votre décision comme priorisant l'amitié sur le codage

1

tl; dr vous devriez sans doute abandonner le projet.

Sans en savoir plus sur ce que vous nous avez dit, je suppose que la friction que vous rencontrez est liée à l'expérience.

Même si vous n'êtes pas un programmeur de profession en tant que pro de l'informatique, vous avez probablement appris la manière difficile de bien faire les choses la première fois, votre référence à votre futur soi indique que vous l'avez foutu dans le passé et appris pas.

Votre étudiant CS de 2e année, même s'il est assez doué, n'a probablement pas la perspective de l'avoir fait (si vous êtes comme moi, à plusieurs reprises :).

Il / elle ne croira jamais vraiment à la valeur de réparer les choses au fur et à mesure jusqu'à ce qu'il / elle ait brûlé les cicatrices de ne pas le faire ou qu'il soit encadré dans une culture avec une discipline d'ingénierie exceptionnelle, ou les deux.

Cette personne peut être votre homologue de programmation, mais n'est pas votre homologue de projet, donc faire ce jeu en tant que projet d'homologue est probablement une cause perdue. À moins que vous ne soyez prêt à manger le coût futur. Peut-être que la relation est suffisamment précieuse pour vous. Dans ce cas, donnez-lui suffisamment de corde pour se pendre et intervenir pour aider à nettoyer le gâchis lorsque cette personne est forcée de reconnaître le problème.

Sinon, faites une mise en liberté sous caution et faites un projet avec un pair, ou faites un projet de mentor / mentoré où c'est la dynamique dès le départ.


1

Pour ajouter des points supplémentaires à toutes les bonnes réponses:

  • Combien d'efforts faudra-t-il pour terminer le projet? Notez que terminer les "10% derniers" prend beaucoup plus de temps que prévu. Cela comprend les tests / réglages de jeu, la correction de l'utilisabilité, l'adaptation à une variété de plates-formes cibles, la publication, ... S'il s'agit d'un jeu iOS, il y a la signature de code et l'examen de Apple. Honnêtement, la finition peut prendre aussi longtemps que les premiers "90%". Et ce sera très difficile si le code est aussi mauvais que vous le suggérez. (Pouvez-vous commencer à le tester maintenant?)
  • De façon réaliste, quelle est la probabilité que les gens apprécient votre jeu?
  • Méfiez-vous de «l' heuristique des coûts irrécupérables ». Évaluez cet investissement de 10 000 lignes de code à la lumière de la vue d'ensemble, en regardant en arrière sur un produit fini et sans optimisme indu.
  • Pouvez-vous continuer si cela prend encore 3 ans? Vous deux avez des styles de développement différents (pas un bon match d'équipe). On dirait que vous êtes près de la fin de votre patience et si vous continuez, il pourrait être difficile de rester amis.

3
Le "dernier 10%" prend beaucoup plus de temps si 90% du code est des ordures :-(
gnasher729

0

Vous devez simplement continuer à faire votre code comme vous le pensez, avec des commentaires et autres et faire une copie de votre version du code (au cas où il changerait votre code).

Ne vous battez pas, ne vous fâchez pas, souriez juste quand vous voyez ses mauvaises décisions.

Ne vous plaignez qu'en tant qu'utilisateur, si cela fonctionne, ne vous plaignez pas.

N'abandonnez pas non plus, il est important de s'habituer à des personnes différentes de vous, cela se passera dans un vrai travail.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.