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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.