进化型vs一次性原型

Question

在“低保真vs高保真原型”的辩论中，谁是赢家？prototype-zero (P0)应该是最终产品的第一个版本吗？或者应该是P-0永远是一次性的？业界青睐哪种方法？

来自维基百科的优秀文章：Software prototyping

Answer 1

原型应该始终是一次性的-原型用于快速证明概念并影响实际产品的设计。因此，对于一个真正的产品来说，许多重要的东西(一个深思熟虑的架构和设计，可靠性，安全性，可维护性，等等)半途而废。如果你在构建原型时考虑到了这些因素，那么你就不再是在构建原型了。

我使用原型的经验表明，代码直接演变成实际的产品，最终结果会因此而受到影响-缺乏真正的体系结构导致了许多拼凑在一起的代码，这些代码必须不断地修改以添加新功能。我甚至见过一个案例，用于快速开发原型的原始技术对于实际产品来说并不是最好的选择，对于V2来说，需要完全重写。

Answer 2

我认为我们这些学究已经输掉了这场特殊的战斗--所谓的“原型”(根据定义，应该从头开始重写！-)实际上正在“进化”成(通常是半生不熟的"betas")，等等。

即使到了今天，我仍然对我的一位同事重新理解这个概念的聪明尝试表示赞赏，即使这个术语是一场失败的战斗:他正在为开发concept小型项目的证明建立一种方法(如果这个概念确实得到了验证，就会转移给软件工程师进行真正的原型设计，然后进行开发)。

我们的想法是，在我们的部门中，有许多人不是(实际上也不应该是)软件开发人员，但他们非常聪明，精通计算机，每天都在与现实“在战沟中”接触-- they是最有可能嗅到一些潜在创新机会的人，这些创新一旦作为“生产就绪”软件项目实施，可能会产生实际影响。销售人员、客户经理、业务分析师、技术经理--在我们公司，他们通常都符合这种描述。

但它们不会用C++编程，根本不会用Java语言编程，也许用Python语言编程，但离“产品化”还有很远的路要走--事实上，它们更有可能用php、javascript、perl、bash、Excel+VBA和其他各种我们甚至不想永远梦想着产品化和支持的“快速而肮脏”的技术来进行智能的概念验证！

因此，通过将他们的原型称为“概念的证明”，我们希望鼓励他们以具体的形式来体现他们大胆的概念(模糊的自然语言的胡言乱语和大量的挥手是最没有用处的，而且无论如何都与公司的文化格格不入；-)并且强烈地指出，这样的项目，如果被提升到软件工程师的目标和优先事项中，确实必须从头开始编程--概念证明充其量只能作为工程师目标的良好草稿/草图规范，绝对不是逐步丰富的，而是从头开始！-)。

现在就说这个想法的效果如何还为时过早--三个月后，当我们评估本季度的努力时，请问我(目前，我们只是提供了一个蓝图，紧跟着评估上个季度的部门和公司业务！)。

Answer 3

编写原型，然后不断重构它，直到它成为产品。关键是在必要时毫不犹豫地重构。

最初只有很少的人在做这件事是有帮助的。由于有太多的人在做某件事，重构变得更加困难。