调和矛盾的编程建议：在编码之前先进行工作并进行迭代与真正考虑

我是具有几年专业经验的中级程序员，并且已攻读硕士学位。在学习程序设计时，我经常听到两条看似矛盾的建议。

第一步建议是使某些东西快速工作，看看它是如何工作的（通过原型设计或非正式测试），改进版本，看看它如何工作，再加以改进……然后重复循环直到完成。 。这有时被称为“螺旋式发展”，或被表述为“早期释放，经常释放”。

第二条建议是：在编写任何代码之前，请认真考虑一下项目。

我在这两种方法上都取得了成功，我会说我同意每种哲学。

但是现在我开始处理我不知道如何完成的更复杂的项目（例如分布式应用程序和性能驱动的图形编程）。

我如何进行这些项目？

我是否只是开始编写一些东西并在进行过程中学习（平台/方法/语言/体系结构）-还是在我打开IDE之前不进行编码并进行大量研究/阅读？

如何协调这些相互矛盾的编程建议？

我不确定提前考虑问题与迭代方法是否相互矛盾。就像许多其他事情一样，我认为您应该努力实现两者之间的平衡。您如何找到余额？那是您从经验中学到的东西，通常是时间最佳的课程（例如，可以给您带来经验的东西），当您没有完全正确的时候（或者甚至更好的课程：平淡无奇地弄错了）。正如您已经指出的，有一句话“快速发布，经常发布”。还有另一个类似的说法，“过早失败，快速失败，经常失败”

提前思考是伟大的，您绝对应该这样做。但是，借助经验，即使没有全部数据，也应该学习何时停止思考并仅仅构建一些东西。通过构建它，您将能够对问题领域有更多的了解，并有可能提出更好的解决方案。因此，我建议您不要将任何一个都排除在外，而应将“思考的头脑”作为迭代的一部分，随着时间的流逝，我认为您会自己找到该问题的正确答案。

只是一个例子。前几天，我在为软件设计决策而苦苦挣扎。事后看来，这相对来说是微不足道的，但是我有两种选择，而且似乎两者都可以使用。我不断回头讨论每一个的优缺点，然后回头再重新考虑我的决定。回首过去，我花了多少时间思考有点尴尬。然后我对自己说，f＃@ k！而且我没有使用任何一种设计，而是继续并一起破解了一些代码，完全忽略了您从优秀设计中学到的所有好知识。我在大约45分钟内即可使用该功能。然后我回头查看代码，将其重构为可靠的东西，而对于检查源代码控制我也不会感到ham愧。有趣的部分是，在我完成黑客工作后，想出了“

我特别建议针对您现在面临的问题（即即将出现的大型，复杂任务）提出的另一件事。与其并行处理，不如并行处理。将您的一天分成很多部分，在其中进行研究，然后停止，切换齿轮和编码一段时间，至少在项目的某些部分（不是完全未知的部分）上。这种与代码保持紧密联系的方式将为您提供更好的视角，并且您不会因尝试太快地吸收太多信息而感到疲倦。至少对我来说，经过几个小时的研究，让大脑消化一些东西，切换任务并做一些其他事情是好事。然后回到更多的研究。

必须提前做出某些决定。

您在制作Web应用程序吗？然后，您需要了解整体架构。像MVC这样的架构已经定义了您的大型功能部件（例如路由，控制器，模型，服务层，通信协议等）；从头开始发明所有东西将是一个漫长的过程，是不必要的，而且可能不如已经发明的那样。

您是否正在编写涉及对象或数据集合的任何类型的应用程序？然后，您将需要了解哪种数据结构最适合您的特定方案，以及它们的性能特征是什么。您需要快速查找时间吗？有序数据集怎么样？内存中的集合会做吗，还是您需要更具工业强度的东西，例如数据库？您不能不考虑这些决定就开始编码，因为如果选择错误，就必须重新开始。

就是说，一旦做出技术决定，您就可以在已建立的框架内享有自由。然后的目标是保持足够的灵活性，反复性和（敢于说）敏捷性，以使当客户改变想法时，您可以以最小的麻烦来适应他们。

你是怎样做的？经验多半。就像有人曾经说过的那样，经验就是您需要后立即获得的东西。但是，如果您遵循他人的成功设计决策（体现在平台，库和其他贸易工具中），则可以从中汲取教训并降低风险。

我不认为两者是互斥的。

像任何类型的项目管理一样，您既需要长期愿景，也需要短期目标。

如果没有前者，您最终将浪费时间，例如可能根本无法使用的功能；没有后者，您将花费一整天的时间考虑如何在不完成项目的情况下创建完美的应用程序。

您多久发布一次/等等。取决于您使用的特定方法。

您需要研究的内容取决于您所了解的知识和不熟悉的知识。

“迭代”和“透彻思考”不是矛盾的，而是互补的。

即使在极端情况下，它们也反映了到达同一地点的两条路径。

• 迭代的极端是千只猴子用一千个键盘敲打。有了足够的时间，您也许会得到符合要求的东西。
• “彻底考虑”的极端方法是瀑布方法。如果您很幸运，从项目开始到交付代码时，需求没有发生太大变化。否则您将最终陷入分析瘫痪状态，却一无所获。

在开始编码之前，您必须对域和问题有所了解。这是“仔细考虑”部分。理想情况下，您将从头到尾看到解决问题的高级途径。

但是您可能只会看到该路径的主要部分，当然也不会一路停下来。那就是迭代起作用的地方。您可以开始遍历应用程序的版本并寻求反馈，以便：

• 确定较低细节层次上的障碍
• 请参阅利益相关者的反馈，以阐明高层路径中那些模糊的区域。

决定的拉丁语含义是“切断”。迭代使您可以决定在实践中可行的方法，而不仅仅是理论，而迭代使您可以排除其他不可行的方法。

因此，您必须仔细考虑问题，才能理解要做什么。但是，然后您需要遍历应用程序的版本，以将想法实际转换为实际代码。

我的经验法则：如果您不完全理解问题的任何部分，则需要退后一步，并仔细考虑一下（我将原型和一次性代码理解为API等，作为“深入研究”的一部分） 。如果这基本上是您之前已解决的问题的集合，而您只需要找出在此特定实例中将所有内容组合在一起的最佳方法，则进行迭代。

坦白说，这不是一个硬性规定。我真的认为您需要针对任何给定项目同时进行这两项工作。您所做的每件事多少可能主要取决于该项目与您过去已经完成的项目有多接近。