我的代码大部分都存在主要的设计缺陷。完成还是现在修复？[关闭]

我是一名高中生，和我的一个朋友一起从事C＃项目，他的技能与我差不多。到目前为止，我们已经在100次提交中编写了大约3,000行代码和250行测试代码。由于学校的原因，我推迟了几个月的项目，最近我又可以将其重新备份。

备份时，我了解到我编写的代码设计不良，例如在渲染器中包含过多线程，在模拟CPU，GPU和游戏卡带之间的交互中无法很好地防止竞争情况，以及仅仅是多余和令人困惑的代码。

问题是我什至没有完成程序的主要功能，所以我无法真正重构，因此我不鼓励继续完全意识到我的代码设计有缺陷。同时，我不想放弃该项目。已经取得了很大的进步，工作绝不能浪费。

我似乎有两种选择：通过解决不良的设计来简单地完成功能，然后在一切正常进行后进行重构，暂停一切并在完成其余功能之前努力解决一切，开始项目到处都是新鲜的东西，或者由于项目过大（基本上是“回到绘图板”）而彻底放弃该项目。

根据他人在此类项目中的经验，如何使自己重回正轨？根据该站点上的答案，普遍的共识是，通常不需要重写，但是如果不能在不付出过多成本的情况下维护代码，则可以使用重写。我确实很想继续这个项目，但是就目前而言，我的代码设计得不够好，无法继续进行下去，而沮丧的情绪使我无法继续进行下去。

如果我穿上你的鞋子，我可能会这样尝试：

• 首先，尽快完成当前项目（至少部分完成），但要处于工作状态。可能您需要减少最初的目标，请考虑一下您真正需要在“ 1.0版”中看到的最低功能。

• 然后，然后再考虑从头进行重写（我们将其称为“ 2.0版”）。也许您可以重用V1.0中的某些代码。也许在再次陷入困境之后，您决定可以重构V1.0并保存其中的大部分内容。但是在手头没有“概念验证V1.0”之前，请不要做出此决定。

即使代码很糟（即使您自己，其他人也不会费心），可以将正在运行的程序“ 1.0”显示给他人。如果在创建V2.0的过程中您意识到自己的时间已经用完了，那么您仍然可以将V1.0取得部分成功，这对于您的士气会更好。但是，如果您不先完成V1.0，则很有可能永远都不会完成V2.0，因为当您完成一半时，可能会再次感到您对设计不满意，然后呢？您会再次放弃V2.0并使用V3.0吗？陷入这个永无止境，永无止境的风险很高。

最好将其作为学习如何实现中间目标的机会，而不是学习如何使项目处于未完成状态的机会。

完成的IT项目，即使是有缺陷的项目，也比未完成的项目要好得多。

未完成的课程也可以教给您很多知识，但不及完成的课程那么多。

您现在可能看不到它，但是即使使用错误的代码，您也可以得到巨大的价值。

我的投票是完成表决，然后根据需要进行重构。当您开始处理更多项目时，您会惊奇地发现，“本来应该重构”的部分多年来一直未受影响，而其他部分则得到了扩展。

从就业的角度来看，在大多数情况下，您将为完成的项目获得更多荣誉。

我会很乐意重新开始该项目。

您是学生，而且仍在学习。这使您所处的位置与所链接的问题完全不同。

• 您对代码没有专业责任；如果您现在要删除整个项目然后走开，您将不会受到任何影响。对于开发人员来说，这是一个巨大的优势。在您所链接的问题中，那些开发人员正在尝试维护人们花钱购买的软件，即使是很小的错误也可能给客户带来大麻烦，这使得从头开始编写非常危险。您没有那个问题。

• 作为个人项目，这是尝试新事物并从错误中学习的绝好机会。认识到旧代码存在问题非常好，因为这意味着您已经学会了如何做得更好。反复试验的经验对于初学者来说是无价的。

• 您的项目相对较小，并且基本上没有测试。从头开始写3000行可能只需要短短的几个晚上，尤其是因为您已经有了下次可以做的更好的想法。

• 与已重写的代码库相比，在残破的代码库中工作将使您的士气大为减少。

顺便说一句，这可能是尝试使用单元测试编写更具模块化的程序的绝佳机会。这样做可以使您在长时间休息后重温代码，更容易理解代码，并有助于防止由于健忘而意外引入的错误。

最后，这是关于有时退后一步以向前迈出更大步伐的智慧的一种观点。

您可能仍处于开发的“快速学习”部分。从现在开始的几个月中，很有可能您会发现，新的，令人敬畏的设计以一种您什至没有意识到的方式被彻底破坏了。

完成工作 -这是您需要学习的最重要的一件事。相信我，我认识许多人（不仅仅是程序员）陷入了“从头开始，因为我在开始这个项目之前学到了很多东西”循环。问题是它永远不会结束 -直到您停止学习新事物，这才不是一个好地方:)

能够真正完成任何事情也很重要。重新开始是令人兴奋，酷炫，有趣的……但是，如果您仅学习到这些，您将永远无法完成任何事情。再说一次，这不是一个非常有用的功能，实际上感觉不如使某些东西有用（或有趣）。人生苦短，时间有限，你不能只是继续练习而没有任何实际的成果-你会为此而发疯。如果您由于无法决定采用哪种方法而无法开始工作，那么您已经处在危险区域。

总会有重新开始的冲动。即使在学习环境中，这些也很可能不是一个好主意。这并不意味着您需要将每个原型都带到可用于生产的应用程序，而不是将它带走。但是您至少需要进入一个可行的原型阶段-这很可能会帮助您提高士气，对于任何类型的开发人员来说，这都是非常有用的特质。把事情做好。而有趣的部分是，您很快就会发现，使用原型可以做的事情比“从头开始重写”还多一百万种乐趣或有用的东西-在许多情况下甚至可以重构它。您所做的一切都需要付出成本-至少，在此期间您可能会做其他事情。

我在软件开发中遵循“使之工作，使其正确，使其快速”的思想。

1. 使它起作用：编写核心功能，以便该项目可用。为了使一切正常工作，您必须做些什么，即使这意味着难看的代码。
2. 正确处理：修复错误并重构代码，以便于阅读，理解和维护。
3. 快速：优化程序，旨在在速度，资源使用和可维护性之间取得良好的平衡。

现在，您尚未完成第1步。首先使其工作，然后您可以担心代码的丑陋程度。实际上，创建有效的产品是新开发人员要做的最困难的事情之一，因为他们全神贯注于试图使自己的代码完美无缺，因此他们陷入了“优化地狱”之中，而从未真正完成开发工作实现所有功能。您必须学习如何消除对重构和优化的所有担心，以便您可以专注于使软件正常工作。获得更多经验后，您自然会在第一时间就做更多的事情，因此重构的工作量减少了。

请记住：过早的优化是万恶之源（有关出色的讨论，请参见这个出色的Programmers.SE问题）。如果您花太多时间思考如何使代码更好，那么您将陷入分析瘫痪。这杀死了项目。最好在开始优化项目之前先完成项目。

引用一位出色的励志演说家：做到这一点。

和往常一样，有一个相关的xkcd：

重写它。非工作代码的价值很小，三千行不是很多代码。它所花费的时间不会比编写您当前拥有的代码花费的时间长，而且会更好。我经常抛出五百或一千行不良代码，并且重写的时间通常是原来的五分之一。

关于“不要重写”的大多数概念都与大型系统有关，这些大型系统在做重要的事情，并且不断进行更改以满足不断变化的需求。正在使用的复杂系统的重写很少成功。

您的情况则完全相反。您有一个没有用户的小型应用程序，唯一的需求就是您选择要实现的需求。因此，继续进行重写。

从头开始重新启动通常是在现实生活中的项目不好动，主要是因为现实生活中的项目积累的错误修复，一个开发后发是不知道的（例如，见事情你应该永远不会做，从对软件乔尔博客。）

不管怎样，学校项目不会继承这样的历史，并且通常是在编码和设计同时开始，同时具有部分计算知识和缺乏经验。我会将您的第一个版本视为原型，用作失败的概念证明，并且我会很乐意将其丢弃（请参阅“一次性”原型与“进化”原型之间有何区别？有关“一次性”与“进化”原型的讨论。）

正确的设计已经成熟，您无需花费太多时间将其编写为代码。

我谨不同意改写是个坏主意的建议。

在软件生命周期领域，通常认为纠正错误所需的时间和精力会增加生命周期中每一层的数量级。也就是说，如果在要求级别纠正错误需要1个小时，则设计将花费10个小时，编码测试需要100个小时，而bug修复则需要1000个小时。这些数字听起来有些离谱，但被业界认为是正确的。显然，在较小的项目中花费较少，但总体思路仍然存在。如果您的项目有一个基本的设计缺陷，那么更适合称之为学习经历并返回，检查您的初始要求并重新设计。

我还鼓励考虑使用结构化单元测试的“测试驱动开发”模型。它们很痛苦，起初似乎是在浪费时间，但是它们发现错误的能力，尤其是在与他人代码集成时，是不能过分强调的。

你在这句话上迷了我：

问题是我什至没有完成程序的主要功能，所以我无法真正重构，因此我不鼓励继续完全意识到我的代码设计有缺陷。

我相信（根据Systemantics所述）的原则

• 总是可以找到一个有效的复杂系统，它是从一个简单的有效系统演变而来的。
• 从头开始设计的复杂系统永远无法运行，也无法进行修补以使其正常运行。您必须重新开始，首先要使用一个简单的系统。

因此，编写一个复杂的系统包括

• 编写一个简单的系统
• 确保它有效

...即以下步骤：

1. 写一点代码
2. 测试它以确保其正常工作
3. 再写一点代码
4. 再次测试
5. 等等。

请注意，步骤3可能涉及：

3. 再写一点代码
   1. 重构现有代码以准备进行新添加
   2. 测试重构以确保其仍然有效
   3. 添加新功能

另外，如果第2步“对其进行测试以确保其正常工作”，则可能需要进行一些重写。

如果我是在烂代码基础上构建的，那么我不希望添加更多功能。因此，我倾向于安排诸如“简化现有的线程实现”之类的事情作为下一个要实现的工作。假设您一直在进行测试，那么您应该能够将此视为重构练习。此工作阶段的成功/退出标准为：

• 源代码更简单
• 而且没有引入新的错误
• （并消除了一些旧错误）

顺便说一句，“对其进行测试以确保其正常工作”并不一定意味着“单元测试”-当团队结构简单时，您可以使用（简单）系统测试（而非单元测试）来测试（简单）系统。

遇到诸如此类的问题时，您面临的问题之一是，您在某种程度上一直沉迷于到目前为止编写的代码。

一位同事告诉我，他在大学期间正在编写程序，当时他正在从著名教授那里上课（我相信那是Dijkstra）。他要求教授看一下他从事一个多月的代码。教授问他是否做了备份，他回答没有。教授然后删除了他所有的代码，并告诉他再次编写。

他很生气，但是三天后他完成了程序，代码更简洁，错误更少，代码行更少。

诚实地估算出在项目可用的时间内哪种选择最佳。

这三个选择是

• 删除它（完全，不回头）
• 继续使用旧设计
• 边走边重构代码。

我从事专业程序员已有10多年了，在我的工作中，我得出的结论是，最后一个选项在大多数情况下都是被选择的，但这并不总是最好的选择。

听起来您的技能在那个时期已经大大提高了。也许那个项目的工作对此有所贡献。再次将其设计为有目的的学习体验将会硕果累累。

请记住，这不是您需要作为客户的工作程序交付的东西。它是专门为练习而编写的。因此，除非您想练习运输问题和交货有缺陷，否则我认为您目前正处于开发阶段，证明您的“设计力量”将卓有成效。

在执行此操作时，请专注于设计过程和规划，并仔细考虑现有内容，并反思您对更好的理解。

重构。重构。重构！推荐人！！！

老实说，无论您经验如何，这都是一个普遍的问题。您编写了代码，学习了一些知识，并且想在旧代码上使用新知识。您想根据新知识来衡量旧代码。

那只是行不通的。如果这样做，您的应用程序/游戏将永远无法完成。相反，请尝试在项目上分配时间，以便您的某些“任务”能够重构不良代码。举例来说，假设您有一种保存游戏的可怕方法。继续研究游戏本身，但是要花一些时间来重构（替换）这种可怕的方法。尝试使重构保持较小，这应该不是问题。

当您到达需要重构的应用程序的主要部分时，您就很认真地做错了。将重构分解为较小的部分。尝试花费七个小时编写代码，并花费一小时进行重构。

当您完成项目并遇到功能冻结时，您便可以花费大量时间进行重构。现在，完成游戏，但仍然尝试重构某些游戏。那是你所能做的最好的。

总会有一些重构的东西。

我要说的是，这取决于您现在拥有哪种代码以及问题出在哪里。就是说，如果您的基础很好（大多数部分中的类设计正确，去耦/内聚性好等，仅是您提到的线程中的一些错误选择），那么一定要拿出一个简单的1.0，然后像没有明天。

另一方面，如果实际上只是一堆丑陋的，打成一片的文本文件以某种方式通过了编译器，而没有可辨别的结构等（换句话说，就是一种概念验证的在职学习原型），然后我宁愿删除它并重新开始。

在您的下一个版本中，请采取一种敏捷的方法：为自己设置固定的重复时间表，例如2周或适合您的日程安排。在每个块的开头（我们称其为冲刺），设定自己的目标，即两周内可实现的目标。快去做，尽你所能使它起作用。设定您的目标，以便每两周就有一个可以向朋友展示的东西，而不仅仅是一些抽象的内部作品。Google的“ scrum”和“ smart目标”。这很容易做到，如果您一个人，只需一张纸，上面有几个快速记下的要点。

如果可以做到，那么重新开始是个好办法。如果您深知这一点，那么从头开始之后，您可能最终会回到现在的位置，然后坚持使用您的代码并使其生效。

你必须把自己放在雇主的鞋子上。

对于大多数招聘人员来说，如果您采用这种方式，那么您将是最有价值的：-在您编写的新代码上进行100％测试，以完成这项工作。-添加旧（错误设计）代码的测试。-重构它以实现您想要的设计。

通过良好的版本控制过程，分支和标签来完成所有这些工作。

重写通常是一个性感的主意，但通常是新手拥有的一个主意，在现实生活中有点危险。表明您更愿意提高已经完成的工作质量，而不是从头开始表明您是一个认真的人。

您显然可以重写它，但是然后将其变为另一个项目。

只是为了增加我过去的经验。每当我有空余的时间时，我已经在一个副项目上工作了一年多。这个项目从一个简单的测试台到一个静态类，再到现在的面向对象的超薄衬里设计。

在所有这些更改中，我保持了代码的相同功能，但不包括错误修复和性能收益（需要尽快）。尽管重构了相同的代码库，但代码保持不变，因此，我进行了大量改进，而不必从头开始并浪费时间来重写代码。

这意味着我能够以比以前更快的速度改进代码。这也意味着，在我前进的过程中，更容易说出需要删除的内容（即不必要的类），并且与仍旧记住旧想法的情况相比，可以轻松地进行重写。

因此，我的建议是重构您的代码，并从那里继续进行必要的改进。尽管一定要记住，如果您决定从头开始重写，则应该采用旧项目的好主意，并仔细查看它们，以查看存在缺陷的地方。即不只是将旧代码复制到新项目中。

答案取决于我喜欢称之为“复杂性上限”的事物。随着您向代码库中添加的内容越来越多，存在一种趋势，即它变得越来越复杂，组织也越来越少。在某些时候，您将达到“复杂性上限”，在这一点上，取得进展非常困难。与其尝试通过蛮力继续前进，不如备份，重组/重写然后继续前进。

那么，您的代码库是否如此糟糕以至于您接近复杂性上限？如果您认为是这样，请花一些时间进行清理和简化，然后再继续。如果清理的最简单方法是重写某些部分，那很好。

都不行 都？

继续进行下去，花一些时间修改现有设计，花一些时间添加新功能。

如果您有互动，那可能是一个不错的起点（“渲染器中的线程过多”听起来像效率低下，而不是会导致正确性问题的东西）。看看您是否可以找到一种摆脱比赛（或陷入僵局）的一般方法，或者至少是多种特定的方法。

我不知道C＃可以使用死锁和竞速检测器之类的东西，但是如果它们存在，它们可能有助于识别存在的问题并验证您的修复程序是否有效。

我发现，总的来说，我更愿意解决有用的代码问题，而不是将其丢弃并从头开始。在某些情况下，焦地（类似于绿地和棕地...）的开发更令人满意，但这通常适用于现有方法过于复杂的情况，甚至不再是错误的方法。

如果您的代码是模块化的，那么您应该能够完成不良编写组件周围的其余代码，然后重新编写不良编写组件，而不会影响其余代码。

在这种情况下，由您来决定是否要重写不良的组件。如果编写得不好的组件写得很烂，以致完成的代码无法按原样使用，那么在完成其余代码之前，您需要重新编写它们。

您应该问自己的第一个问题是“缺陷有多严重？”

您到底在做什么错？

如果问题很严重，您将花费大量时间尝试解决此问题，暴露敏感数据（密码/信用卡）或造成严重漏洞，那么也许您应该对其进行编辑，但是大多数时候您可以处理您所拥有的，完成它，然后再解决此问题。

程序员喜欢改善他们的应用程序，希望他们成为“可能的最好的人”，但这不是正确的方法。

如果您尽快发布应用程序（即使不是100％），也将存在所有错误，那么您将从其他人那里获得反馈，同时有时间修复1.1版的错误和其他内容。其他人将能够帮助您使应用程序变得更好，并且您可能会浪费时间去做别人可能不喜欢的事情。

因此，在您的情况下，将其发布出来，获得一些反馈，然后您可以构建具有所有更改的2.0版，并修复存在的缺陷。

要记住的另一件事是，我们正在不断改进。有一种说法是，如果您可以看一年前的代码，发现它很糟糕，那意味着您还在改进，这是一件好事。

这取决于您的代码有多混乱。

• 如果您犯了真正的n00b错误，使您的代码过于复杂或冗长，那么我建议重写这些部分。

• 如果您认为自己有必须修复的严重错误，请编写一些单元测试以检查是否已修复该错误（...因为您尚未启动该程序）。尽早修复bug更好，并且在您还记得代码做什么的同时修复bug绝对更好。

• 如果您不喜欢这些方法的名称，它们所属的类或诸如此类的小东西，则只需使用IDE。（请记住，这是C＃，而不是某些javascript，python，perl，php等。）当您使用使用受影响的组件的代码时，脑海中清楚地知道该组件应该做什么，如果您的IDE轻松完成，则对其进行重构。

否则，请使其工作并磨练下一个项目的技能。

正如其他人所建议的那样，由于这是一个个人项目，而不是一个专业项目，所以我会认真考虑重写。

但是，您可以通过执行实验来利用此处的科学方法。首先，设想一个假设。我的想法是，“可能是时候重写了。” 为了节省时间，减少故障成本并在某种程度上限制先验偏差，在进行更多编程之前，请确定时间长度（“时间框”）。我建议大概4点钟。还要确定评估假设的方法。由于风险很低，因此我建议作为一种方法，简单地问自己：“我很高兴自己做到了吗？” 现在开始实验。在选择了时间框之后，对假设的评估是什么？例如，以我的例子为例，您已经花了4个小时来开始重写吗？那么这可能是正确的选择。

您可以要求世界上所有的建议，但没有什么能像凭经验来检验假设那样。

考虑选择重写作为实验的一些原因：

• 以我的经验，它通常更有趣。在专业情况下通常不选择重写的一个重要原因是乐趣远非唯一标准。但是您仍然对编码还不太陌生，因此乐趣可能是一个非常重要的标准，并且它还可以指示您在此早期阶段可能无形的其他因素（有趣的是，您会学到更多，等等）。
• 您的经验以及可能令人na的良心意识似乎在告诉您，重写是值得考虑的。听那个声音，如果有的话。即使您不听从它的建议，至少也要听。将来会有更多的外部声音，您需要练习聆听自己的感觉。
• 我怀疑通过重写，您更有可能将代码模块化。创建模块时，您可以使用更多可重用和可靠的组件来用于其他项目。最终，您甚至可能会发现，看来您的主项目中的一个模块仅仅是您编写的最有趣，最有价值的代码。

完成某件事是一个好主意，但不是在真空中。如果您开始重写，则可以选择通过完成特定的子模块来完成某些工作。在上述实验之后，您可以将其设置为首要目标。完成并不一定意味着要完成最初的主要项目。在完成一个模块之后，再完成另一个，依此类推，直到您愿意，完成对原始项目的整个作用域的重写。