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

#1 楼

如果我不满意，我可能会这样尝试：


首先，尽快完成当前项目，至少要部分完成，但要处于工作状态。可能您需要减少最初的目标，请考虑一下您真正需要在“ 1.0版”中看到的最低功能。
然后，然后再考虑从头进行重写（我们将其称为“ 2.0版”）。也许您可以重用V1.0中的某些代码。也许在再次陷入困境之后，您决定可以重构V1.0并保存其中的大部分内容。但是，在手头没有“概念证明V1.0”之前，请不要做出此决定。是不好的（除了你自己，其他人都不会打扰）。如果在创建V2.0的过程中您意识到自己的时间已经用完了，那么您仍然可以将V1.0取得部分成功，这对于您的士气会更好。但是，如果您不先完成V1.0，那么您很有可能永远也不会完成V2.0，因为当您完成一半时，您可能会再次对设计不满意，然后呢？您会再次放弃V2.0并使用V3.0吗？陷入这个永无止境，永无止境的风险很高。

更好地以此为契机，学习如何实现中间目标，而不是学习如何使项目处于未完成状态的机会。

#2 楼

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

未完成的课程也可以教给您很多，但不及完成的课程要多。甚至是错误的代码。当您开始进行更多项目时，您会惊奇地发现，“原本应该重构的”部分多年来一直未受影响，而其他部分则得到了扩展。

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

#3 楼

我很乐意从头开始这个项目。

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


您对代码没有专业的责任；如果您现在要删除整个项目然后走开，您将不会受到任何影响。对于开发人员来说，这是一个巨大的优势。在您所链接的问题中，那些开发人员试图维护人们花钱购买的软件，即使是很小的错误也可能给客户带来大麻烦，这使得从头开始编写非常危险。您没有问题。
作为个人项目，这是尝试新事物并从错误中学习的绝佳机会。认识到您的旧代码有问题真是太好了，因为这意味着您已经了解了如何做得更好。对于新手程序员来说，反复试验的经验可能是无价的。
您的项目相对较小，基本上没有测试。从头开始写3000行可能要花上几个晚上，尤其是因为您已经知道下一次要做什么的想法。将。

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

#4 楼

您可能仍处于开发的“快速学习”部分。从现在开始的几个月中，很有可能您会发现新的，令人敬畏的设计以一种甚至在您开始时都不知道的方式被严重破坏了。

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

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

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

#5 楼

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



使之工作：编写核心功能，以便该项目可用。即使使丑陋的代码都无法正常工作，也必须做这些。

使其快速：优化程序，以在速度，资源使用和可维护性之间取得良好的平衡。

目前，您尚未完成步骤1。它首先工作，然后您可以担心代码的丑陋程度。实际上，对于新开发人员而言，创建有效的产品是最难的事情之一，因为他们全神贯注于试图使自己的代码完美无缺，因此他们陷入了“优化地狱”，而从未真正完成开发工作实现所有功能。您必须学习如何消除对重构和优化的所有担忧，以便您可以专注于使软件正常工作。一旦获得更多经验，您自然就会在第一时间就做更多的事情，因此重构就更少了。 .SE问题进行了很好的讨论）。如果您花太多时间思考如何使代码更好，则会陷入分析瘫痪。这杀死了项目。最好在开始进行优化之前先完成项目。

引用一位出色的励志演讲者：只要做就做。

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

#6 楼

重写它。非工作代码的价值很小，三千行不是很多代码。它所花的时间不会比编写您当前拥有的代码花费的时间长，而且会更好。我经常扔掉五百或一千行不良代码，而且重写的时间通常是原来的五分之一。重要的事情，并不断变化以满足不断发展的要求。重写使用中的复杂系统很少会成功。

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

#7 楼

从头开始重新启动通常对现实生活项目来说是一个不好的举动，主要是因为现实生活项目会累积一些新来的开发人员不知道的错误修复程序（例如，请参阅Software Blog上Joel的《您不应该做的事情》）。
学校的项目永远不会继承这样的历史，通常会先进行编码和设计，同时还要具备一定的计算知识和经验。我会将您的第一个版本视为原型，用作失败的概念证明，并且我会很乐意将其丢弃（请参阅“一次性”原型与“进化”原型之间有何区别？有关“一次性”与“进化”原型的讨论。）

正确的设计已经在您的脑海中成熟，不需要花费很多时间将其编写为代码。

#8 楼

我会完全不同意改写是个坏主意的建议。

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

我还鼓励考虑使用以下方法进行测试驱动开发模型结构化单元测试。它们很痛苦，最初看起来像是在浪费时间，但是它们发现错误的能力，尤其是在与他人的代码集成时发现错误的能力。

#9 楼

您对这句话失去了我：


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


我相信原理（在Systemantics中规定）



人们总是发现作品是从一个简单的有效系统演变而来的。
从头开始设计的复杂系统永远都行不通，也无法修补以使其正常工作。您必须重新开始，首先要使用一个简单的系统。



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


编写一个简单的系统
确保它能正常工作

...即执行以下步骤：


编写一些代码
对其进行测试确保它可以工作
再编写一些代码
再次测试
等。

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


再编写一些代码


重构现有代码，为添加新代码做准备
测试重构以确保其仍然有效
添加新功能
/>


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

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


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

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

#10 楼

遇到这样的问题时，您面临的问题之一是，您会以某种方式深深地沉迷于到目前为止编写的代码。

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

他很生气，但是3天后他用更干净的代码，更少的错误和更少的代码行完成了程序。 br />
尝试诚实地估计在项目可用的时间中哪种选择是最佳的。

这3个选择是删除它（完全不要回头）
继续使用旧的设计
边走边重构代码。

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

#11 楼

听起来您的技能在那个时期已经大大提高了。也许那个项目的工作对此有所贡献。再次将其设计为有目的的学习体验将是富有成果的。它是专门为练习而编写的。因此，除非您想练习运输问题和交货有问题，否则我认为您目前正处于开发阶段，证明您的“设计力量”将富有成果。设计过程和规划，并仔细考虑现有内容，并反思您对自己的理解有所了解。

#12 楼

重构。重构。重构！ REFACTOR !!!!

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

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

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

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

总是会有一些重构的东西。

#13 楼

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

另一方面，如果真的只是一堆丑陋的，打成一片的文本文件，它们以某种方式通过了编译器，没有可辨别的结构等。（换句话说，证明是-concept在职学习原型），那么我宁愿删除它并重新开始。

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

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

#14 楼

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

对于大多数招聘人员而言，如果您采用这种方式，那您将是最有价值的：
-添加针对旧（设计不良）代码的测试。
-对其进行重构以实现您想要的设计。

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

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

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

#15 楼

只是为了增加我过去的经验。每当我有空余的时间时，我已经在一个副项目上工作了一年多。这个项目从一个简单的测试平台到一个静态类，再到现在的面向对象的超薄衬里设计。性能收益（需要尽快）。尽管重构了相同的代码库，但保持不变，因此我进行了大量改进，而不必从头开始并浪费时间来重写代码。以比我以前更快的速度这也意味着在我要去的时候，很容易说出需要删除的内容（即不必要的类），并且比起脑海中仍然想着旧想法的东西，更容易进行重写。重构您的代码，并从那里继续进行必要的改进。尽管一定要记住，如果您决定从头开始重写，则应采用旧项目的好主意，并仔细查看它们，以了解存在缺陷的地方。即不要只是将旧代码复制到新项目中。

#16 楼

答案取决于我喜欢称之为“复杂性上限”的事物。随着您向代码库中添加的内容越来越多，存在一种趋势，即它变得越来越复杂，组织越来越少。在某些时候，您将达到“复杂性上限”，在这一点上，取得进展非常困难。最好不要备份，重新组织/重写，然后继续前进，而不是继续蛮横地前进。如果您认为是这样，请花一些时间进行清理和简化，然后再继续。如果清理的最简单方法是重写某些部分，那很好。

#17 楼

都不行两者都继续吗？

继续吧，花一些时间修改现有设计并花些时间添加新功能。

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

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

我发现，总的来说，我更致力于解决有用的代码问题，而不是将其扔掉并从头开始。在某些情况下，焦土（类似于绿地和棕地……）的开发更令人满意，但这通常适用于现有方法已脱离应有的方式而不再是错误的情况。 br />

#18 楼

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

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

#19 楼

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

您究竟在做什么错？尝试解决此问题的时间，暴露敏感数据（密码/信用卡）或造成严重漏洞的时间，那么也许您应该对其进行编辑，但是大多数时候您可以利用已有的内容，对其进行完善和修复以后会出现这个问题。如果您尽快发布应用程序（即使不是100％），也将存在所有错误，那么您将从其他人那里获得反馈，同时有时间修复1.1版的错误和其他内容。其他人将能够帮助您使应用程序变得更好，并且您可能会浪费时间去做别人可能不喜欢的事情。 ，然后您就可以通过所有更改来构建2.0版，并修复存在的缺陷。有一种说法是，如果您可以看一年前的代码，发现它很糟糕，那意味着您仍在改进，这是一件好事。

#20 楼

这取决于代码的混乱程度。


如果您犯了真正的n00b错误，使您的代码过于复杂或冗长，那么我建议重写那些部分。
如果您认为自己存在严重的错误，无论如何，都必须先进行修复，然后编写一些单元测试来检查您是否已修复了该错误（...因为您尚未启动程序）。最好尽早修复错误，并且在您还记得代码做什么的同时修复bug绝对更好。那，然后只使用IDE。 （请记住，这是C＃，而不是某些javascript，python，perl，php等。）当您使用使用受影响的组件的代码时，脑海中清楚地知道该组件应该做什么，然后，如果您的IDE使它变得轻松，则对其进行重构。

#21 楼

正如其他人所建议的那样，由于这是一个私人项目，而不是一个专业项目，因此我会认真考虑重写。首先，设想一个假设。我的想法是，“可能是时候重写了。”为了节省时间，减少故障成本并在某种程度上限制先验偏差，在进行更多编程之前，请确定时间长度（“时间框”）。我建议大概4点钟。还要确定评估假设的方法。由于风险很低，因此我建议作为一种方法，简单地问自己：“我很高兴自己做到了吗？”现在开始实验。在选择了时间框之后，对假设的评估是什么？例如以我的示例为例，您已经花费了4个小时来开始重写，您是否感到高兴？那么它可能是正确的选择。

您可以要求世界上所有的建议，但没有什么像凭经验检验假设的方法了。选择一个重写作为实验：


以我的经验，通常更有趣。在专业情况下通常不选择重写的一个重要原因是乐趣远非唯一标准。但是您对编码仍然相对陌生，因此乐趣可能是一个非常重要的标准，并且它还指示了其他可能在您早期无形的因素（有趣的是，您会学到更多，等等）。
您的经验以及可能令人a的良心意识似乎在告诉您，重写是值得考虑的。听那个声音，如果有的话。即使您不听从它的建议，至少也要听。将来会有更多的外部声音，您需要练习听自己的声音。
我怀疑通过重写，您更有可能将代码模块化。创建模块时，可以使用更多可重用和可靠的组件来用于其他项目。您甚至可能会发现，最后，看起来像您的主项目中的一个模块，原来是您编写的最有趣，最有价值的代码。不在真空中。如果您开始重写，那么您可以选择通过完成特定的子模块来完成某些工作。在上述实验之后，您可以将其设置为首要目标。完成不一定意味着要完成最初的主要项目。完成一个模块后，再完成另一个，依此类推，直到完成重写整个范围（如果需要）的原始项目。