在压力下如何避免跳到解决方案？[关闭]

在特别严格的编程截止日期（例如一个小时）内，如果我完全感到恐慌，我的趋势是跳入没有真正计划的编码，并希望我能继续研究下去。如果有足够的时间，这是可行的，但是在一次采访中，即使不是彻头彻尾的适得其反，它还是非常不成功的。我不总是舒服地坐在那里想着时钟打tick。

当您足够了解问题并开始编码时，是否存在核对表或是否存在识别技术？什么时候最能想到的是进行设计和设计，而不是进行一些实验，然后再进行总体设计？

这是参加数学考试和参加口语考试的技巧清单。是否有类似的技术清单来处理压力下的编程问题？

答案：我认为这是一个有效的答案：如何解决。我发现该链接是解决步骤或解决方案的答案。在上也有一些非常好的技巧。在面试中大声思考真的是最好的策略吗？。TDD的一个简洁明了的论据是TDD的第一个答案写代码vs找出问题的答案？。

我回想起曾读过一篇关于火警如何在到达火场时形成行动计划的研究；该研究观察（并谴责）他们提出了一个主意，然后立即追求第一个主意。由于时间的压力，几乎是“这可能行得通”，其次是“好吧，让我们这样做”。该研究指出，可以使用更好，更快，更安全的选项，但是并没有仅仅因为马歇尔首先没有想到它们而就没有遵循它们。

如果您想要一种结构化的方法来处理“大火”，则可以从他们的（新）书中抽出一张叶子，其中规定了以下几个阶段：

RRAPID

1. 反应-调动事件资源
2. 侦察-收集有关情况的数据
3. 赞赏-根据最佳和最坏情况选择行动方案
4. 计划-根据行动计划制定计划
5. 发出订单-使用标准简报格式
6. 部署-执行和监视

或更笼统地说：

1. 唤醒所有人，让他们动起来
2. 弄清楚发生了什么事
3. 头脑风暴解决方案
4. 选择一个并计划
5. 告诉所有人他们的工作是什么
6. 执行和监控

我总是从理解需求开始，并在需求中寻找需要解决的空白。

然后我草拟（非常粗略地在纸上或白板上）两个或三个可能的解决方案。然后我问自己：“要实现其中任何一个，我还需要知道什么吗？”

一旦我提出了最初的问题（有100％的问题存在，如果您没有问题，您就没有真正深入了解该要求。），我将回到利益相关者那里获得我的答案。

当我等待他们的回答时，我会考虑我的解决方案，看看是否有比其他解决方案更好的解决方案，或者一旦我获得问题的答案就会更好。例如，如果您很快就需要它，那么我可能会选择开发最快的方法，但为以后的设计改进留有余地。如果他们告诉我性能很关键，那么我会查看解决方案并确定哪种方案更有可能取得更好的性能（这些是目前的猜测，但通常是明智的）。如果涉及GUI，则我可能会组成一个包含多个不同设计的纸质原型，并在我编写任何代码之前让涉众查看它们（通常，他们会发现他们忘了告诉您有关XYZ的知识，这对设计！）

得到答案后，我会选择一个粗略的设计，然后列出实现该设计所需要做的所有工作。然后我开始编码。

...我的倾向是在没有真正计划的情况下跳入编码，并希望我能随着时间的流逝解决它。

我上大学时就这样做了。这成为一个真正的问题，通常会导致重写代码。我开始通过不编写代码来解决这个问题。我把重点放在对这个问题的思考上。通过足够的练习，我会本能地达到自己的想法，而不是键盘。

...在一次采访中，即使不是完全适得其反，它还是非常失败的。我不总是舒服地坐在那里想着时钟打tick。

在采访中，必须有一个合理的，经过深思熟虑的解决方案实施方案，而且这并不总是那么容易。您不想做的就是脱口而出的答案。如果您知道答案，请快速给出答案。如果不这样做，请依靠您的想法来推理解决方案。 始终指出您何时不知道并示范如何找到解决方案。

当您足够了解问题并开始编码时，是否存在核对表或是否存在识别技术？

我不鼓励这样做，因为您可能会严格依赖它。相反，问自己是否对问题足够了解，可以开始编码。你怎么知道的？因为当您推理出自己的方法然后进行检查时，鉴于您目前对语言的了解，这将是有意义的。始终有一个计划和方法。还要记住，代码永远不会完成，并且不会进化的代码会消失，因此希望经常返回您的代码。

什么时候最能想到的是进行设计和设计，而不是进行一些实验，然后再进行总体设计？

您将需要了解整体设计并考虑一下。然后，您开始制作类结构和存根。然后再次检查。是否有意义？编码实验是证明某些方法工作良好的好方法，应该使用它，但不能用来编码或塑造您编写的代码。