在没有编写代码的情况下思考几天的设计问题是否正常？[关闭]

有时我茫然地凝视着空间或勾勒出想法，然后在纸上写下一些伪代码。然后我将其擦除并重新开始，然后，当我认为自己有解决问题的正确方法时，我便开始编写代码。

想几天不写任何代码是正常的吗？这是否表明我正在完全解决问题？没有在我的IDE中编写任何有形的代码使我感到紧张。

根据您要解决的问题，设计阶段可能需要数周甚至数月（如果不是数年），而不仅仅是几天。

需要经验才能避免立即开始执行代码。关于架构和高级设计的思考可能需要几天甚至更长的时间-绝对是开始编写代码之前发生的事情。

这通常称为“分析瘫痪”

这很常见，但是是错误的。在某个时候，您需要测试各种想法，以找出最适合您的方法，然后逐步加以改进。

建议阅读实用的程序员，特别是第2章“跟踪器项目符号”部分

这是完全常见的。但是，如果您采用“首先测试”或TDD方法，则这种方法不太常见，可能有助于您更好地提出自己的想法。

习惯通常是对事物的反复试验方法的结果，不断产生能够为我们带来预期结果的事物，而避免产生无法取得的结果。做我们喜欢的事情并避免我们讨厌的事情也起作用。这在一定程度上是可行的，因为最终我们会做一些自己不喜欢的事情来获得租金。

这取决于导致您这样做的原因和原因。这里有一些：

• 很多时候，由于设计更改，您不得不更改代码
• 您无需更改较差的设计，因为较小的解决方案已经编码
• 您宁愿进行绘图和设计，也不愿编写代码声明
• 不必担心编码的语法和细节，这会分散您对更好设计的思考。

希望您发现，如果设计时间更长，则代码会更好。如果您可以回头看看，花多少时间在设计上都没关系，则可能需要进行更改。另一个要考虑的是与编写设计相比，编写代码后发现问题的频率是多少。如果直到编写完一些代码后才发现问题，则应考虑一个平衡点，并尽快开始进行编码。也许这种方法可以应用于更新的技术或非常复杂的功能。

我不知道我是否有遵守一种方法或另一种方法的纪律，即使我发现一种方法比另一种方法更好。有时我觉得有必要去白板；其他键盘。

这很常见，我觉得这是处理和理解事物的更好方法。在进行项目时，我经常陷入困境，花一两天的时间才能了解如何更好地处理它。即使问题解决了，我也要等一天。这使我更加精神焕发并开始前进。

这是很自然的现象，对于开发人员来说，截取自己的思维时间和中间时间是一件好事。

当我选修项目管理课程时，与我们有关的计划制定师与我息息相关的一件事是，他们在军队中教给我的经验法则是计划制定时间的1/3 。因此，如果您的操作需要从现在开始三个月才能完成，那么请在开始执行之前花一个月的时间进行计划。

我认为，有三种方法，每种方法都适合特定的编码情况

1. 之前我曾遇到过类似的问题，所以我对要应用的模式有一个很好的了解，并且明确了解决方案的行为方式和响应方式。

   =>从所需的解决方案开始使用BDD / TDD，然后使用该代码。（好吧，有时我作弊并编写了一些代码，然后进行了测试-一种嵌套的2--> 1.方法）。

2. 我对要应用的模式有一个很好的了解，但是我不确定该解决方案应该是什么样子。

   =>原型，看看会弹出哪些有趣的东西。当我确定需要哪些有趣的东西时，移至1.。

3. 我不确定要应用哪种模式。

   =>考虑问题，以及解决问题的各种方式如何影响代码。根据练习的结果移至2）或1）。

换句话说，答案是工程师的最爱：这取决于。

花一个月的时间进行思考和设计，比根据不合格的设计快速构建原型要好，然后您必须将其成型。特别是在团队中时；一旦其他人开始依赖您的代码，则使用不同的API来实现更好的设计就变得更加困难。

我同意其他答案，原则上，花时间思考问题/解决方案是一个好主意。但是，如果您觉得自己陷于困境，那么我对如何使计划过程变得更加连贯提出了一些建议：

• 创建设计工件。那么，如果您不编写代码怎么办？也许您只是写下您的想法日记。或一般解决方案的草图。甚至只是对您随时间改进的问题的一个很好的总结。当您考虑并接受/拒绝想法时，请记录下您对该主题的推理记录。这样，在一天结束时，您仍然可以将真实的交付物作为劳动的证据。

• 与人交谈！就像有一个活着，呼吸良好的人与他们讨论想法一样。如果您认为自己陷入困境，请与某人讨论。抓住某人-任何人-并向他们解释问题。勾勒出您对解决问题的想法。即使他们做的只是在胡闹的同时吸气，呼气和眨眼十分钟，但您很有可能会在解释问题的过程中发现新的见识。

正如Satchel Paige所说：“有时候我会坐下来思考，有时我只是坐下来。”

我想他的意思是，有时候清醒主意是件好事，因为这可能使您以不同的方式思考问题。因此，如果您不急于编写代码，那么您可能会想出一种可能使您回避的解决方案或想法。因此，是的，不立即进行编码是一种正常且好的做法。

我自己有两种方法可以完成此过程。我创建一个文件夹，其中有一个文本文件和与该项目有关的所有图形。我在这里记下我的想法，并尽力保存整个思想过程。我还将创建一个便笺本项目，在其中可以快速测试从算法到CSS布局的简单想法。

程序=算法+数据结构

恕我直言，设计（解决问题）过程完全有规律。实施（技术问题）的细节自然而然地得到解决。

这是我的想法。

1. 从头开始首先，您需要一个大概的想法。尝试获取一些要求的列表，或创建它们。在这里弄清楚情况应该花费一些时间。一旦有了至少一个您有信心想要的作品，就知道该作品的大部分界面，然后开始编码。

2. 解决现有代码中的问题首先，跟踪问题。这可能需要一段时间不编写真实代码（可能会编写一些调试代码，但是通常不会保留）。一旦发现问题，根据复杂性，开始编写代码以尝试解决它。已知错误后，几乎无需考虑。如果问题是主要的设计缺陷，请参阅下一节。

3. 设计变更/主要特征这很可能是最需要思考的一个。关于保留结构，向后兼容性等方面的思想必须包括在内。深思熟虑，寻求最佳的改变可以节省大量时间，但对我而言通常不超过几天。

4. 添加简单功能如果不需要进行重大设计更改，则只需使用一些试验/错误即可在功能中进行编码。一般而言，这不需要很多时间。

我不同意对此达成的共识。我什至对我希望我的系统如何工作有了最模糊的书面餐巾一开始就想开始制作原型。除非我以非常精确的方式指定事物，否则我几乎不可能想到所有可能导致问题的小细节。如果我只是在与人讨论设计，那么轻易解决一些更复杂的问题就太容易了。一旦指定了类似的内容，它就可能直接位于源代码中，而不是其他一些精确而又形式化但无法编译和执行的表达方式。

这取决于您对“正常”的含义。说到自己，我认为代码是一个很好的学习工具。因此，面对一个复杂的问题时，我会在纸上画草图，但也会做一些测试驱动的编码。代码告诉我，白板不能说，反之亦然，也许结果就是洞察力或需要向领域专家提出更多问题。

因此，真正的建议是：“使用所需的所有学习工具来更接近问题的定义”，而且“请记住，这些都是学习工具，所以不要爱上它们”，代码和草图均应丢弃。 。

在RAD和敏捷编程的时代，一旦您可以识别系统的主要部分，就应该立即开始开发，细节随之而来。由于软件正在变得越来越大，因此过早地关注每个细节将无济于事。