prototyping - 先设计还是先原型？

Question

当第一次接近一个项目时，最好退后一步，仔细考虑所有事情，或者只是潜入并在以后开始编码和润色？本质上，您是先设计还是尝试快速原型？

我已经被这两种方法所困扰，有时我会尝试仔细考虑所有事情，但是当我真正深入到细节时，我会遇到我没有考虑到的问题，有时当我第一次编码时，我会以需要的代码结束重做以适应更好的整体设计。我的很多问题都源于缺乏经验，但欢迎任何建议。

Answer 1

逐步和迭代地进行。

设计一点，实施一点。

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

从没有设计的情况下开始，您可能会做出您会后悔的决定。

理想的情况是能够实现您的系统的非常简单的端到端版本，该版本可以进行测试并向客户展示。

Answer 2

首先设计总是更安全，但这并不意味着原型设计不起作用。原型设计的真正问题是抵制保留已经编写的代码而不是在设计时将其丢弃的冲动。

Answer 3

没有银弹。似乎设计优先是首选方法。但是您将无法预测在实施您的设计时可能出现的所有复杂情况。他们中的一些人可能会成为表演的终结者。另外，如果您正在为客户写作，最好能够展示一些内容以确保您在同一页面上。

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

Answer 4

参见盖尔定律。关键是迭代：设计一点，实施一点，测试一点，然后重复直到您（或您的客户）满意。这是新型“敏捷”方法的本质。

Answer 5

这取决于。

当需求或解决方案不一定清楚时，原型设计最有用。举个例子，我正在一个环境（大型商业保险）中做一个数据仓库项目，其中财务对账很重要。该项目涉及大型原型设计工作，以获得一个与财务状况相协调的系统。由于围绕此的业务规则没有得到很好的记录，因此原型有助于暴露所有极端情况。

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

Answer 6

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

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

Answer 7

我认为这取决于您预先有什么样的业务需求。如果它们（相对）详细和完整，那么我会根据这些要求进行设计。如果您一开始几乎没有任何东西可以使用，那么制作原型并向您的客户展示您得到了什么，以接收进一步的需求信息。

Answer 8

您应该使用敏捷方法进行开发。简而言之，您设计就行了。团队与产品负责人一起定义要开发的主题列表，按重要性排序，并在迭代中拆分开发。每次迭代作为要开发的特征，在迭代开始时设计每个特征。

在这里查看更多。

Answer 9

当第一次接近一个项目时，原型。但不要对所有东西都进行原型设计。原型化一件重要的事情（一个“用例”，如果这意味着什么）和“转动内在的眼睛跟随它的路径” - 留意你在尝试完成这件事时遇到的实际问题。

既然您已经了解了做一件重要的事情需要什么，那么您可以从不仅仅是基本原则进行设计。

当然，这假设您在一个环境中工作，您可以以最小的成本为正在进行的开发工作制作原型。但是，如果您在这样的环境中工作，请在您的设计讨论中大量使用原型。运气好的话，你可能会保留其中一些。

Answer 10

请注意，敏捷方法不是避免设计的借口，它们只是鼓励更频繁地测试设计，并且增量更小

我喜欢绘制设计草图并将其元素分解，直到有理由确定没有明显的未知数或风险；“尖峰”项目突出了未知数和风险，如果首选方法证明不可行，则有确定可行性的时间框和可能替代方案的说明

一旦对整体架构感到满意，就自下而上（或按优先顺序）跳入功能以完成设计，编写初始测试，然后实施

编辑：请注意，“首先设计或原型”的问题是一个错误的假设，即可以在不进行任何设计的情况下进行原型设计，当然情况并非如此（除非您使用的是百万猴子方法）

Answer 11

设计优先，除非你愿意冒险在你发现它不能做你需要它做的事情时，把所有投入到你的原型中的工作扔掉。至少，您应该为您的项目进行一些高级设计，这些设计可以帮助您就如何构建原型做出一些决定，从而将浪费的精力降到最低。

Answer 12

如果我知道我想建造什么，我就直接去设计。

如果我正在为客户构建一些东西，那么我会制作原型以缓解用户的更具体要求。

Answer 13

也许不是答案，而是我的经验的建议。

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