首先设计或原型？

Question

当第一次接触项目时，最好回头考虑一切，或者只是潜入并开始编码，并在晚些时候进行抛光？从本质上讲，你是首先设计还是尝试快速原型？

我被两种方法烧伤了，有时候我会试着去思考一切，但是当我真正意识到问题时，我遇到了我没有考虑到的问题，有时当我第一次编码时，我以代码需要重做以适应更好的整体设计。我的许多问题都源于经验不足，但任何建议都是值得欢迎的。

Answer 1

首先设计总是比较安全，但这并不意味着原型设计不起作用。原型设计的真正问题在于抵制保留已经写好的代码的冲动，而不是在做设计时抛弃它。

Answer 2

在开始工作之前，您必须对凝聚架构有所了解。大型系统尤其如此。

原型可用于设计的特定方面，例如，表示层。

Answer 3

设计第一，除非你愿意冒着把你放入原型的所有工作都扔掉，否则你发现它不能做你需要的东西。至少，您应该为您的项目制定一些高级设计，以帮助您就如何构建原型做出一些决定，以便尽可能减少浪费。

Answer 4

逐步迭代地进行。

设计一下，实现一下。

从设计开始，您可能会受到隧道效应的影响在实际执行某些操作之前，您无法获得任何真实的反馈。

从无设计开始，您可以做出令您后悔的决定。

理想的情况是能够实现您的系统的一个非常骨架的端到端版本，可以测试并展示给客户。

Answer 5

请参阅Gall's Law。关键在于重复：设计一点，实施一点，测试一下，然后重复，直到您（或您的客户）满意为止。这是新一代“敏捷”方法论的精髓。

Answer 6

我认为这取决于您有什么样的业务需求。如果他们（相对）详细和完整，那么我会根据这些要求进行设计。如果您在开始时几乎没有任何工作要做，然后将原型制作出来并向您的客户展示您获得的内容，以获得更多需求信息。

Answer 7

您应该开发使用敏捷方法。简而言之，你的设计让你走了。团队与产品所有者一起定义要开发的主题列表，按重要性对其进行排序，并在迭代中分割开发。作为要开发的特征和迭代开始的每次迭代是设计每个特征。

查看更多here。

Answer 8

这取决于。

当需求或解决方案不一定清晰时，原型设计最有用。作为一个例子，我正在一个环境（大型商业保险）中进行数据仓库项目，在这个环境中，财务和解是一件大事。这个项目涉及到一个大型的原型设计练习，以获得一个可以与财务调和的系统。由于围绕这一点的业务规则没有很好的记录，原型在揭露所有的角落案例方面起到了重要作用。

在其他情况下，设计优先方法可能更合适。这在需求和明智的解决方案体系结构相当明显的情况下最适用。

Answer 9

没有银子弹。看起来设计首先是首选方法。但是，你无法预测实施设计时可能出现的所有问题。其中一些可能会成为阻止者。此外，如果您正在为客户写信，最好能够展示一些内容以确保您处于同一页面。

在我的工作场所，我们都做了两个 - 我们做一个快速原型，只是为了获得反馈并了解任何潜在的问题。然后我们做一个正式的设计和正式的实施。在大多数情况下，我们能够从原型阶段挽回大量代码。我喜欢这种方法，因为我们通常会得到干净，可维护的代码。

Answer 10

如果我知道我想要建立什么，我只是去设计。

如果我正在为客户构建一些东西，那么我就可以通过原型来缓解用户的更多特定需求。

Answer 11

也许不是答案，而是根据我的经验提出的建议。

在大多数情况下，如果我之前开始编码，我会更好。你可以设计，直到牛回家，但如果你开始编码时奶牛在地平线上，你可能会发现你的精心设计很难及时实施。

Answer 12

当第一次接近一个项目，原型。但是不要对所有东西进行原型。原型是一件重要的事情（如果这意味着任何事情，那么就是一个“用例”），并且“让内心追随它的道路” - 注意你在试图完成一件事时遇到的实际问题。

现在您已经了解了一件重要的事情需要做什么，您可以从不仅仅是第一原则进行设计。

当然，这是假设你正在一个环境中工作，在这样的环境下，你可以以最低的成本将原型转换为正在进行的开发工作。但是如果你在这样的环境中工作，那么就可以用原型来大胆地进行设计讨论。幸运的话，你可能会保留其中的一些。

Answer 13

注意，敏捷方法不是借口逃避设计，他们只是鼓励设计的测试更加频繁，以较小的增量

我喜欢素描设计，打破它的元素，直到有理由相信，有没有明显的未知或风险; “尖峰”项目突出了未知和风险，如果首选方法证明不可行，则需要一个确定可行方案的可行性和注释的时间框。

曾经对整体架构很满意，自下而上（或按照优先顺序）完成设计，编写初始测试，然后执行

编辑：请注意，“设计或原型第一”这个问题做出了一个糟糕的假设，即可以在没有做任何设计的情况下进行原型设计，当然不是这种情况（除非你使用的是百万猴子方法）