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


30

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

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

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

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

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

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

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


3
提出一致同意的编码风格准则和代码审查流程怎么样?避免出现任何有争议的问题,只要在标准中放入足以让您俩都同意的标准即可。
布兰丁

25
第四种选择(如果它具有许可许可):编写代码并继续自己进行工作。
罗伯特·哈维

4
代码如何获得许可?您可以分叉并继续与其他人继续吗?
杰德2015年

14
正如@enderland在回答中提到的那样,您在写的内容中绝对有一个巨大的危险信号:“我的伴侣今晚输了它,并明确表示无论是什么基准,无论是常规做法,还是无可辩驳的证明,他的代码将保持他最初创建代码的方式。” 如果你可以从这个脱身,这样做。任何真正值得合作的人都会谦卑地接受,有时他们会把事情弄错。
理查德·福斯特

3
无论您做出什么决定,万行代码都不会丢失:想想您从编写代码中学到的知识;想想您在时间编码过程中所拥有的乐趣;并且,将您在(强制)第三/第四/ n + 1迭代中学到的知识应用到甚至比当前版本更好。此外,如果您知道编写1万行代码的内容,则可以在相对较短的时间内编写10k行。通常,要花多少时间才知道要使事情正常工作要写什么。
卡斯珀范登伯格

Answers:


26

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

话虽如此...

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

我会考虑以下内容。

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

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

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

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

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

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

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


1
谢谢您的回复。我实现了娱乐(不打架)和学习的目的。天气要赚钱是完全不同的故事。他确实有助于实现我的目标,但是我相信我仍然可以独自完成这些目标,他会激励自己。该游戏是功能蠕变的一个很好的例子,老实说,我不知道什么时候可以发布。我的合作伙伴几个月来一直在努力争取将2D转换为3D,但由于我们已经超出了我们的范围,我拒绝了。
Douglas Gaskell

1
我愿意放弃该项目,如果它只是我自己的项目,那几个月前就已经放弃了。我继续前进的动力是与其他人一起工作,即使内斗使我有些疑问。唯一让我无法放弃的是友谊,例如在编码之外与他的联系,我宁愿避免在项目中投入精力。当然,这不是基于逻辑的解释,因为涉及他们的个人感觉,这确实使我的决策能力模糊了。
道格拉斯·加斯凯尔

1
失去朋友最快的方法就是平等地与他们合作!

58

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

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

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


谢谢Gnasher,我确实会定期看到#2,尽管我们没有实际的时间表,所以我不确定响应的有效性。我将为此睡觉,看看我在AM中的想法,在做出决定之前,这需要大量的考虑。
道格拉斯·加斯凯尔

1
“如果是那样的话,那就逃走。” -而且,总的来说,如果您无法达成共识,那么您将无法与某人合作。听起来,无论出于何种原因,他都不会同意您更改“他的”代码。
史蒂夫·杰索普

好吧,似乎时间压力不是拒绝改变的原因。
gnasher729

1
这是一个很好的答案。您不能强迫某人改变方式!但是,听起来他和您的项目都投入了大量时间和精力。我的想法可能是他可能不想更改代码,因为他不了解您认为应该执行的方式。要么是那件事,要么是他很顽固,但如果是他不理解,那就要记住,他可能会感到沮丧,并认为您正在“跟他说话”,即使您的意思很好。我的建议是尝试在双方都同意的情况下与他讨论。
zfrisch

^ +当您以相同的水平开始时,很容易被某人冒犯,而他们的技能超过了您。我并不是说肯定是这样,但是听起来确实可能与它有关。
zfrisch

12

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

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


2
感谢您的答复。有趣的是您提到了第一点。他正在尝试寻找并引入一个新手程序员,他可以教他们帮助该项目。我只能期望,如果两个人遵循相同的hack风格而忘记了,那将导致可怕的结果。我喜欢第二种选择,将其制成,发货,然后离开。我可能会遇到的问题是,尽管我们正在制作LLC,但仍处于中间阶段,因此我们有一个名称来发布游戏。当然,这两种使用都将占50%的份额。但是,我可以先完成它,然后继续。该项目很大,可能需要一段时间。
道格拉斯·加斯凯尔

20
不会在任何情况下要进入一个人一样,具有法律约束力的业务关系。
gnasher729

3
@ douglasg14b带了一个初中教..可怜的孩子。建议您请一个有经验的人“因为他会加快速度并帮助完成产品”。将您的目光投向终点-还是你们俩打算永远,永远地致力于这一爱好?(看到发生这种情况,直到被取消)
gbjbaanb 2015年

我肯定会计划完成它。尽管我确实认为这是一个太大的项目,但我们无法解决。它起初只是一个简单的设计,它不应该出现在现在的规模附近。我的合作伙伴不断扩大功能范围,不断扩展我们的范围,对此我要部分负责,因为我允许它发生甚至同意某些功能。范围是这样的:如果不考虑这个问题,我们可能希望在一年内完成。值得庆幸的是,通过我的编程方式,以后可以轻松取出零件并将其放入其他项目中。
道格拉斯·加斯凯尔

4
认为代码属于项目,而不属于您。如果您对产品拥有共同所有权,则可以将所有代码重用于下一个项目。如果您不知道谁拥有什么,那么现在进行讨论。祝好运。
gbjbaanb 2015年

9

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

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

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

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

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

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

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

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

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

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


4

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

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

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

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

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


15
但是,这属于整个“技术债务”论点,对吗?当您编写新功能(或修改现有功能)时,是否要花费三倍的时间,并产生十倍的错误(如果您不进行重构的话)?如果是这样,那么跳过重构就是错误的经济。
Ben Aaronson

1
您可能会这么认为,但是我在许多成功的公司工作过,而且我(几乎)从来没有看到将重构放在优先位置。我的结论是,它根本没有回报。
伊万2015年

这足够公平,我敢肯定对此有各种各样的意见,好像没有解决一种或另一种方法是答案中的一个重大遗漏。此外,我可能是错的,但问题的字里行间,我觉得不好的代码的OP担心可能的方式比样的代码你即将思维差。
Ben Aaronson

嘿,是的!但是听起来也很昂贵。在我的回答中,我尝试给出一个目标:“您是否为了钱?答案,加上我对概率平衡所在的主观看法
Ewan,2015年

1
在某些情况下,这是合理的,但是如果某人的“工作代码”导致另一个人在代码上花费了两倍的时间,或者将系统集成在一起或将来的工作花费了那么多时间,那么这不再是一个简单的“决定是否成立”的决定。许多大型项目之所以死亡,是因为他们没有做出正确而快速的决定。
enderland

3

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

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

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

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

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

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

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

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

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

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


2

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

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

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

哥们:很好。

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

哥们:不,我只是觉得很好。

道格拉斯:那么指导方针是什么呢?

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

道格拉斯:你会写什么准则?

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

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

哥们:这不是胡扯。

道格拉斯:完美吗?理想吗?

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

道格拉斯:我们是否可以达成共识,X是好的代码,而Y是坏的代码?

哥们:别管我。我只想编码!

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

道格拉斯:你想要什么?

伙伴:我只想编码。

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

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

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

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

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

哥们:恩,du!

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

哥们:当然。

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

道格拉斯:现在怎么样?

哥们:很好。

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

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


2

假设您决定放弃该项目:

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

1

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

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

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

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

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

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

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


1

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

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

3
如果90%的代码是垃圾,则“最后10%”的时间要长得多:-(
gnasher729 2015年

0

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

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

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

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

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.