哪些因素应该影响我如何确定何时与朋友一起放弃一个小项目？[关闭]

最近我发现自己处在困境中。现在已经与一个编程伙伴一起玩了将近8个月的游戏。我们都是从去年8月左右开始学习编程的新手，他是CS的二年级学生，我是一名IT贸易技术支持人员，并且是一位自学成才的程序员，拥有大量的书籍和在线订阅。

我一直看到的问题是，当我们写出一段代码时，它常常会被黑在一起，会有很多失败，如果这对我们中的一个人来说是一个全新的概念，那就是天真的解决方案。很好，我们正在学习，我希望我们的两个代码在第一遍或第二遍都被一起破解。当涉及到实际修复和重构那些被黑在一起的行为时，就会出现问题。

我的伴侣将坚持自己刚凑齐的行为，公然拒绝看到任何错误，因为它开始起作用。即使从结构上声称接近完美，即使它具有注释以及适当命名的方法和字段，我什至都无法尝试使用。无论我多么努力，我都无法让他看到明显的明显缺陷，这些缺陷将阻止行为的任何进一步更改或扩展，而又不会完全破坏行为，而与行为如此紧密耦合的所有事物也可能属于同一类。被黑客入侵的解决方案将永远保持被黑客入侵，深思熟虑的设计会像最初构思和测试时那样保持原样。

我花了很多时间来照顾新代码，就像我自己编写代码一样，我不知道该怎么做。我的伴侣今晚输了它，并明确表示，无论是什么，基准，常规做法，无可辩驳的证明，他的代码都将保持其最初的用法。即使已经写了整本关于您为什么要避免做某事的书，他也会拒绝承认其有效性，声称这只是别人的意见。

我对我们的项目有既得利益，但是我不确定是否可以继续与我的合作伙伴一起工作。我似乎有三个选择。

• 不再关心编译后的代码库功能，而只是尝试维护和解析几乎没有发展的行为。希望一旦事情开始严重破裂，他将看到并尝试做更多的事情，而不是仅仅对根本存在缺陷的设计施加创可贴。
• 继续对十年前其他能力更强的人提出的问题进行无休止的争论。
• 停止对该项目进行编程，放弃我的代码将近10,000行，并花费大量的时间进行设计工作，然后尝试自己寻找一个新项目。

我可以采取哪种方法来确定是否值得与这个人继续进行此项目？还是哪些因素会影响我的决定？我们已经编写了很多代码，除非有必要，否则我不想放弃。

出厂时，不完美的代码要比永远不会出厂的白板上的完美代码要好。

话虽如此...

那些拥有更多经验或处于类似情况的人。你做了什么？你会推荐我做什么？

我会考虑以下内容。

• 这个项目的目的是什么？好玩吗 钱？学习？
  • 您实际上是在实现这个目的吗？
• 这个人是否真的使您能够更好地实现目标？
• 您离实际出货有多近？
• 这些问题会阻止您启动吗？还是他们出于个人自豪感？
• 遇到挫折时自愿与某人合作有好处吗？

停止对该项目进行编程，放弃将近10,000行代码，并花费无数时间来承担设计工作，并尝试自己寻找一个新项目

考虑以上内容，请尝试考虑所需的其他工作。

您需要确定自己的优先级，并确定与该人一起工作相关的问题是否值得。我们无法为您解决这个问题。

我的伴侣今晚输了它，并明确表示，无论是什么，基准，常规做法，无可辩驳的证明，他的代码都将保持其最初的用法。

您知道您不想和这种人一起工作。

您之所以进行这样的项目，大概是因为您想学习编程并在手工艺本身中找到优雅。

这可能是文化上的事情。在某些文化中，承认自己犯了一个错误是闻所未闻的，而要求某人承认犯了一个错误是关于你可以做的最无礼的事情。如果是这种情况，请逃之.。

根据我与非常聪明的人的经验，如果您告诉他们他们所做的事情并不完美，他们会（1）为您提供正确且易于理解的理由，说明他们所做的事情实际上是正确的，（2）告诉您您知道他们知道这是错误的，但是由于优先级他们没有时间来修复它，或者（3）感谢您指出并修复它。

拒绝学习是关于软件开发人员可能拥有的最糟糕的属性。让他去吧。生命太短暂了，很宝贵，无法浪费时间在他身上。

可能最简单的方法是将其他人带入项目-您错了，他的代码库对您来说太聪明了，或者您错了，它对所有人来说都太聪明了。您很快就会发现，并且如果发现它确实是垃圾，令人费解的初级程序员级别的代码，则将获得备份。

另一方面，一个有效的产品值得任何年数的微调，优雅，清晰的代码。制作游戏，运输游戏，然后走开-让他维护游戏，不要在v2上运行。

即使有些想法是互斥的，也有一些想法。

• 单独的源责任。如果您在模块A上工作而他在模块B上工作，则可以与您的不同样式竞争。他经常发布工作功能吗？他是否到达需要从头重写代码的地步？从模块中重构代码，不要碰他的代码，

• 让他来维护他最糟糕的代码。如果他成功做到了，那么您就避免了艰巨的任务。如果他不能，他会感到痛苦。

• 从用户或业务的角度考虑它。在某些情况下，您只需要Google或Microsoft可以购买的可行产品。换句话说，您正在向市场推出产品，并通过错误或被破解的代码来支持数以千计的客户将陷入困境。如果您的代码使用核导弹控制无人机或为青少年制作快乐的视频，则不一样。

• 他上课，你做测试。使用测试重构代码更容易，更安全。这样，您将无需仅在Junit栏内查看代码。假设A）您正在编写测试，B）您的同事代码是可测试的。如果在编码阶段发现难以构建测试，则后者会更糟。

• 一起去参加培训或活动。如果您不知道正确的方法是很自然的，请使用唯一的方法。看到别人的代码可能无法解决所有问题，但是尝试尝试不会受到伤害。

• 找到您的互补优势。重构有时会很有趣。如果他写的东西至少可以正常工作，那么您可以进行重构。他可以花些时间探索不以生产代码结尾的解决方案。

• 他可能不想重写代码，但他可能同意更好地编写新代码。我知道改写是很难的，无聊的并且会破坏事情。增加一些品质的岛屿。这样，他将拥有如何做事的好例子。

• 使用童子军规则。除非您需要对其进行处理，否则请不要打扰。如果某个模块的编写不正确但可以正常工作并且不需要更改，则可以像这样保留它。如果您需要修复错误或完成功能，请对其进行一些改进。一段时间后，您在80％的时间内更改的20％的课程将得到改善。更多质量岛。

在您不认识你们的情况下，我们无法提出最佳解决方案。祝好运。

好的，这是您可能不会喜欢的答案。

除非代码无法实现该功能，否则请不要“更正”该代码。

这是我的理由。您大概是想赚钱。为了赚钱，您必须快速交付完整的功能。没有人会为“编码良好”的计算机游戏付更多钱。

大多数公司都有同样的问题。重构现有代码以使其“更好”，有时在速度或可靠性方面甚至客观上更好，或者编写新功能。

由于简单的成本收益分析的结果，他们有99％的时间选择编写新功能。

我喜欢到目前为止的所有答案。从enderland的答案中得出以下几点之一：

遇到挫折时自愿与某人合作有好处吗？

我想抽出时间来进行代码审查堆栈交换。在这里，您可以让专业人士批评您的代码。老实说，很多代码审查对于所涉及的人员（询问者，应答者以及偶然发现并阅读它们的人）都非常有用。在专业环境中，您很少会收到如此有用的评论（无论出于何种原因，在我工作过的地方都是这样）。

我的建议是发布一些代码以供审核。我不建议使用它作为弹药来证明这个人是错误的-我怀疑他会把它放在心上-但是您可以在所编写的代码和他所编写的代码上获得非常有用的信息。我建议提交你们两个最争执的代码段。很有可能你们俩都在某种程度上错了，您可以使用该评论作为让客观的第三方介入的一种方式。这将完成一些事情：

• 您可以摆脱局势的情绪紧张。

• 您会获得实时的专业建议。极大地促进了您所学的内容。

• 有人会告诉你你错了。这样做很好，因为任何时间进行编程的人都会听到此消息。您可以像正在处理的这个人一样处理不佳，也可以学习处理。

我认为，如果您以正确的方式使用代码审查，与这个极为沮丧的人打交道，您将收获很多。而且它比一本书或网站说“这样做，因为在大多数情况下这是正确的方法”更具互动性。

同样，游戏开发者堆栈交换。并不是发布代码进行审查的地方，而是询问您所苦苦挣扎的概念/想法。同样，这个地方对所有参与者都大有帮助。

您之前可能已经看过这两个网站；我只是想确保它们是您工具集的一部分。

听起来很绝望。如果我能像你一样，我可能会放弃并继续前进。肯定会有一个时间走开，你可能在那里。

如果您还没有准备好走开，则需要找到一种方法来更好地就您的流程达成一致。听起来您有编码标准，但没有商定的标准。下次您进入十字路口时，下次您想带一点代码来胡闹，而您的好友希望不加处理时，请按照以下步骤进行对话：

道格拉斯：我想更改它，因为X在我们的指南中就在这里。

哥们：很好。

道格拉斯：所以您是说我们应该更改准则？

哥们：不，我只是觉得很好。

道格拉斯：那么指导方针是什么呢？

哥们：我不知道-你写的。

道格拉斯：你会写什么准则？

伙伴：我不会写准则。浪费时间。

道格拉斯：所以我们应该扔掉指导方针，写出我们当时正在想的任何废话？

哥们：这不是胡扯。

道格拉斯：完美吗？理想吗？

伙伴：完成工作；让我们继续下一个功能。

道格拉斯：我们是否可以达成共识，X是好的代码，而Y是坏的代码？

哥们：别管我。我只想编码！

好吧，那进展不顺利，对吗？我想我的感觉是您和好友想要不同的东西。如果您可以达成共识，那就太好了；从那里开始，并以此为基础。但是你不能让他同意想要你想要的东西-比让自己想要他想要的东西更重要。如果您能找到共同的愿望并从那里达成共识，也许您可​​以一起工作。

道格拉斯：你想要什么？

伙伴：我只想编码。

douglas：我也想编码，但是我想为我的代码感到自豪。

伙伴：我为自己的代码感到自豪。

道格拉斯：这是我引以为傲的功能-您如何看待它？

好友：好的，可以，但是您不应该在循环内重新计算X。效率低下。

道格拉斯：那您是说我们应该总是在循环外计算常量值吗？

哥们：恩，du！

道格拉斯：您认为这应该在我们的指南中吗？

哥们：当然。

douglas：好的，我将其添加到我们的指南中，然后更新代码...

道格拉斯：现在怎么样？

哥们：很好。

现在，Buddy正在为准则做贡献（但是间接地），因此他有点主人翁感。也许-也许-他将开始更加重视他们。我认为我倾向于抹平榜样，从准则开始，让大多数或所有这些准则最初来自Buddy。继续写狗屎代码，以便他觉得有必要添加到准则中；让他们从他那里来。也许那时他会开始理解造成这种情况的原因。

但是，如果您宁愿放弃并继续前进，那也不是一个糟糕的选择。

假设您决定放弃该项目：

• 分叉代码并对其进行重构，将其用作“之前/之后”组合项目
• 由于目标是（主要或部分地）学习编程，并且学习某件事所需的时间是完成您已经知道的事情的2-4倍，因此，这项工作并没有真正浪费。
• “沉没成本的依恋”（您在冒险之前已经在企业中进行的投资是一个坏主意）是决策中最常见的人为错误之一
• 为了保持友谊，将您的决定定为优先于编码的友谊

tl; dr您可以说应该放弃该项目。

在您不了解此事的情况下，您已经告诉我们，我推测您遇到的摩擦与经验有关。

即使您不是专业的IT程序员，但您可能已经第一次学会了正确地做事的艰辛方法，但对未来自我的提及表明您过去已经把自己搞砸了，并学会了不去。

即使是非常有才华的二年级CS学生，也可能缺少这样做的前景（如果您像我一样，反复:)。

他/她永远不会真正相信随身携带的东西的价值，直到他/她因不这样做而烧伤疤痕或在具有特殊工程纪律的文化中得到辅导，或者两者兼而有之。

这个人可能是您的编程同行，但不是您的项目同行，因此作为同行项目进行此游戏很可能是失败的原因。除非您准备只承担未来的费用。也许这种关系对您来说很有价值。在这种情况下，给下摆/她足够的绳索以使其上吊，并在该人被迫意识到问题时介入以清理混乱。

否则，请保释并与同伴一起做一个项目，或者做一个导师/受训者项目，这从一开始就是动态的。

为所有出色的答案添加其他要点：

• 完成该项目需要花费多少精力？请注意，完成“最后10％”花费的时间比人们期望的长得多。其中包括游戏测试/调整，可用性修复，应对各种目标平台，发布... ...如果是iOS游戏，则需要进行代码签名并获得Apple的审查。老实说，精加工可能只需要第一个“ 90％”。如果代码不如您建议的那么糟糕，将更加困难。（您现在可以开始进行游戏测试吗？）
• 实际上，人们会喜欢您的游戏的可能性有多大？
• 当心“ 沉没成本启发式 ”。根据总体情况，回顾最终产品，并过度乐观地评估这10,000条代码行的投资。
• 如果再过三年，您可以继续吗？你们两个有不同的开发风格（不是很好的团队匹配）。听起来您已经快要忍耐了，如果继续前进，可能很难成为朋友。

您应该继续以自己认为正确的方式编写代码，并添加注释等，并为您复制代码版本（以防他更改您的代码）。

不要打架，不要生气，当看到他糟糕的决定时只是微笑。

仅以用户身份投诉，如果正在运行，请不要抱怨。

也不要放弃，适应与您不同的人很重要，这在实际工作中会发生。