如何处理分析瘫痪？

很多时候，我在选择最佳设计决策时陷入困境。即使对于小的细节，例如函数定义，控制流和变量名，我也会花费很长的时间仔细研究我所选择的收益和权衡。

我觉得我花了很多时间在诸如此类的无关紧要的细节上而失去了很多效率。即使我知道，如果当前的设计无法解决，我可以更改这些内容，但我很难确定一个选择。

我应该怎么做才能解决这个问题？

两个简单的规则：

1. 做可能可行的最简单的事情。
2. 不断重构。

当您开始做所有这些事情时，您将获得信心，您现在就可以做出简单的决定，而不会影响您以后对变化做出响应的能力。

请记住，面向未来的证明意味着使代码易于更改，而不是试图预期代码可能需要更改的所有可能方式。

通常，当我有这种感觉时，这意味着我需要尝试：

1. 站起来，四处走走，并确保所有生物学工作正常。
2. 转到白板上绘画，直到我感到自信为止。
3. 找到一个“设计投诉伙伴”，您可以与之讨论问题。

如果问题涉及语法和小片段，则：

1. 让您满意的是，即使它很丑陋，也可以很好地封装在某个地方，并且代表着纯粹的本地杂物。
2. 添加TODO标记或仅注释，这些注释说明了代码使您感到烦恼的原因。
3. 转到下一个任务。

认为自己无所作为非常容易。即使你管理，不知何故，拿出最佳的解决方案，现在，可以轻松改变之前完成该项目，然后呢？

最好选择一个不错的解决方案并与其一起运行，而不是坐视最佳解决方案。最好的解决方案是难以捉摸，更糟糕的是，主观的。如果需求变化甚微，您的解决方案可能会比您放弃的解决方案更糟糕，因为当时它不是最好的。

我也在学习避免分析瘫痪，因此对我们表示敬意=）这种情况经常发生是因为我们要进行“最佳设计”。实际上，“最佳”在情人眼中。我的公式避免分析瘫痪，是应用足够好的设计原则。我该怎么做？我带来了诸如时间约束，日程安排之类的变量，并问自己，在不影响质量的情况下，能完成工作的最简单的设计是什么（这并不意味着最简单），但与此同时，我确保这是可测试的，并且一对扩展开放，对修改关闭（OCP）设计。可测试和OCP是什么意思？好吧，我没有去寻找我认为最好的东西，而是考虑了一种设计，该设计可以告诉我情况何时会变差，并尝试执行足够的代码以使我能够在以后进行重构和改进。另外，请尝试将要更改的代码与保持不变的代码分开。重构变得更加容易，因为不应该更改的代码从您自己或其他人的将来变得更加安全。

让您的直觉决定其中一种选择怎么样？这应该非常快，并且可以与ammoQ也提出的时间框完美结合。如果已建立选项，则可以尝试限制为1分钟；如果必须先定义它们，则可以尝试限制为2分钟。或任何合适的东西（预先定义）。当学习倾听您的直觉时，实践将使您的直觉选择变得越来越快。

如果您担心选择不完全的可能性，请考虑以下几点：

• 如果某个选项在其他选项上有明显优势，则您不会问自己要选择哪个选项。因此，根据这种推理，只要您对不太复杂的事情不确定某个选择，就表明这些选择总的来说是相当平等的。因此，仅选择其中之一就没有太多放松的余地。
• 话虽如此，直觉根本不是随机的，而是对最佳解决方案的很好的，有根据的猜测。通常比无休止的翻箱倒柜要好得多。
• 迎合完美主义，当半自觉地评估一个人的表现时，可以将决策的敏捷性评价为高于选择的最优性。对于不重要的选择，这是完全有道理的，但牢记这一点并非不重要。

祝好运！:)

我认为一点经验就可以解决。我的大部分瘫痪发生是因为我试图想象代码库看起来比我需要的要远得多，因此为了克服它，我只是做了最简单的可行的事情，然后继续前进。一旦项目具有确定的形状，重复的代码单元便开始脱颖而出，并且很容易抽象出重复的模式并简化代码。

为了克服您不愿做出的决定，请应用时间框：将闹钟设置为在几分钟后关闭；直到那时，您的脑筋才会折磨，但是当闹钟响起时，请选择直到那时为止找到的最佳选择。

创建一个原型。记住，原型是要扔掉的，所以无论您使用什么功能，变量名甚至是宏大体系结构都没关系。您只是构建它来证明它有效。

一旦您创建了它，并把它扔了出去，我愿意打赌您会更轻松地做出那些决定。

我也遭受这个问题。我要说的是，您没有足够的完成动机。

例如，当我编写渲染代码时，我就有很大的完成动机，因为我知道，如果继续进行下去，我将能够看到该系统的运行情况，并想出我对四边形进行纹理化的能力如何，或转换一个顶点 但是现在我要进行重构（尝试4，如果您想知道），那么我就受苦了，因为这需要大量的工作，即使我完成了，我也会看到相同的旧四边形。而且我真的不想再进行重构，而且我讨厌一次又一次地看到相同的四边形，这对我来说不再是什么奖励。

您需要将其分解为各个组件，并为完成这些组件而奖励自己，即使只是通过某些控制台I / O即可显示其正常工作。

我正在阅读您的问题，并按照其他海报的思路思考问题：您不适合这份工作；给自己一个时间限制；暂时做点其他事情。经过一番思考，我不确定任何答案是否真的有帮助

诸如此类的精神问题的麻烦在于它们不容易解决，它们是您的一部分，并且显然您（可能对工作）过于在意，也没有信心与自己达成共识缺乏经验的人一直以来都认为您是第一选择，否则就会过分强调完美的选择。你为什么还要担心这些琐事呢？

现在我有类似的问题，但是代码却没有那么多..通常它的晚餐用..披萨或咖喱..嗯...披萨，但是咖喱很好，但是我感觉像咖喱吗，比萨更便宜，但是您会得到更多的咖喱，但是...等等。:)

所以我想-为什么我在编码方面没有类似的问题，我认为这仅仅是因为我有一组经常使用的模式。如果我需要一个函数定义，那么它很简单..它将与我曾经编写的所有其他函数定义保持一致。如果需要控制流，首先要确定是需要for循环还是while循环，然后创建与上次我需要这些东西之一使用的相同的旧代码。一切都一样，我要排队吗？当然-让我们剪切并粘贴我的“标准”队列代码（从我从事的上一个项目中窃取，或者使用这些东西中的任何一个我都记得）。最终结果...我只为新事物而烦恼，说实话，这是一种荣幸。

因此，我的建议是开始建立代码片段库-我曾经通过电子邮件将它们发送给自己，然后将它们放在文件夹中，但是无论您做什么工作都是最好的-然后您将开始每次都知道该怎么做。您将始终使用以前编写的旧代码，将问题排除在外，为下一个问题做好准备。您会发现自己成为一名更快的开发人员（认真地讲，这是提高程序员工作效率的唯一方法），并希望能找到时间来玩一些有趣的事情，而不是已经解决了很多遍的沉闷的日常工作过度。

当然，所有这些的后半部分也很重要-工作量越大，花在思考上的时间就越少。

这是一种结合 Rein Henrichs（从简单开始，重构）和ammoQ（定时装箱）建议的策略：

1. 给自己一个非常严格的时间限制，以便第一个可行的解决方案。例如，30秒表示一个变量名。您可以先想出类似的东西x，然后将其优化为string，然后name直到时间到了。
2. 然后在指定的时间（例如10分钟）内执行其他任务。
3. 然后，再给自己一个时间框来进一步改善您的决定，例如userHandle

这种方法可能带来的好处：

• 稍后再讨论的知识可能会缓解目前的问题
• 在执行其他任务的同时，您可能会想出一个令人满意的解决方案，而无需花费大量时间
• 在步骤1松开之后，进入步骤2的流程，可以很容易地使步骤3真正迅速地进行，因为您想继续执行步骤2，因此很高兴只选择一种合适的解决方案并接受它

当我完成研究并没有明确的最佳选择时，我给自己一个时间限制（通常为5分钟）以选择一个，然后继续前进。 即使您遇到障碍，也无法保证在这一点上做出不同的决定也不会遇到同样的障碍。我想不出我后悔自己的决定的时候了。

通常，您无法确定差异不大的原因，或者您没有足够的信息。

在以下情况下：a）设置时间限制，以考虑合理的选择。尚未决定哪一个。最后，选择一个（如果没有明确的偏好，则随机选择）已确定的选项，并选择另一个时限。如果最后没有做出明确的决定，则为已经选择的决定。开始编码，如果您发现错误，则进行重构。如果老板问为什么，请说“我掷硬币，您有更好的方法吗？”

在b）情况下-您需要更多信息，坐在大胖A上。退出设计模式，进入信息收集模式。原型，提出问题，阅读技术杂志。无论如何，不​​要睡太久。

通常，最好的解决方案是尝试向同事解释您的决定。但是，由于您不想经常这样做，因此，下一个最好的选择是在纸上思考-用纸/笔或空的记事本窗口。

首先要写任何东西-只是为了进入写作的节奏。在记事本窗口中，您可以只键入“我在纸上思考”，然后继续保持意识流。几秒钟后，您将处于写作节奏中，因此请按Enter几次，然后开始解释您的困境。

陈述问题，然后陈述可能的解决方案，每个解决方案的优点等等。

尽管这种方法并不总是有效，但通过将想法浮出头脑（RAM）并转移到外部介质（记事本文档）的过程中，您可以更加自由地建立新的连接并从不同的角度查看决策。

我也遇到同样的问题。对于小问题，我尝试解决的方法是采用我认为并不愚蠢的第一个设计。试图找到最佳设计没有任何意义。如果没有写下来，您很难甚至不可能就您可能想到的任何设计的所有细微差别进行推理。在编写代码时，您会发现您可以进行一些小的改进。做对了，我发现以这种方式收敛到一个相当好的解决方案是很容易的。

对于更大的问题，我认为首先考虑您的选择是有好处的，但要在时间上加以考虑。大问题有很大的解决方案空间，您无法评估所有可能性，也不要尝试。

TLDR；选择一个合理的解决方案，并随时进行改进。

这也相关：

陶艺老师在开幕日宣布，他将课堂分为两组。他说，工作室左侧的所有人员仅根据他们制作的作品的数量进行评分，右侧的所有人员仅根据其作品的质量进行评分。他的程序很简单：在上课的最后一天，他将带上浴室磅秤并称量“数量”组的工作：五十磅的锅被评为“ A”，四十磅的杯子称为“ B”，依此类推。但是，那些按“质量”评分的人只需生产一个锅（尽管是一个完美的锅）即可获得“ A”。

好吧，来了分级时间，一个奇怪的事实浮出水面：最高质量的作品都是由按数量分级的小组制作的。看起来，虽然“数量”小组忙于进行大量工作，并从错误中吸取教训，但“质量”小组却对完美理论进行了理论探讨，最后，他们的努力除了宏大的理论和一堆枯死的粘土。

来自http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html。

我从来不明白这一点。当我是一名讲师时，我会说：

"OK, create an integer variable and assign the return value of strlen() to it."

您可能会想，这不太复杂，其中95％的人写的是：

int x;   // or y, or len, or whatever
x = strlen( s );

但是偶尔会有人像一只兔子一样瘫痪在大灯下。我会同情地问问题出在哪里，他们会说“我不知道该怎么称呼！”。

这些人应该寻找另一个职业。也许你应该。