It is always safer to design first, but this does not mean prototyping does not work. The real problem with prototyping is resisting the urge to keep the code you already wrote instead of throwing it away when the time comes to do the design.
There is no silver bullet. It seems like design first is the preferred approach. But you will not be able to predict all complications that can arise while implementing your design. Some of them could potentially be show stoppers. Plus, if you're writing for a client, it's good to be able to show something just to make sure that you're on the same page.
At my workplace we do both - we do a rapid prototype, just to get feedback and get an idea of any potential problems. Then we do a formal design and formal implementation. In most cases we are able to salvage a lot of code from the prototyping stage. I like this approach, since we usually end up with clean, maintainable code.
See Gall's Law. The key is to iterate: design a little, implement a little, test a little, then repeat until you (or your customers) are satisfied. This is the essence of the new breed of "agile" methodologies.
Prototyping is most useful when the requirements or a solution aren't necessarily clear. As an example, I am doing a data warehousing project in an environment (large commercial insurance) where financial reconciliation is a big deal. This project has involved a large prototyping exercise to get a system that will reconcile to the financials. As the business rules surrounding this were not well documented, the prototype was instrumental in exposing all of the corner cases.
In other cases, a design-first approach might be more appropriate. This is most applicable where requirements and a sensible solution architecture are reasonably obvious.
I think it depends on what kind of business requirements you have up-front. If they are (relatively) detailed and complete, then I'd design based on those requirements. If you have barely anything to work with in the beginning, then prototype out and show your customer what you got, to receive further requirement info.
You should develop using Agile Methodologies. Simply put, you design has you go. The team together with the product owner define a list of topics to develop, order them by importance, and split the development in iterations. Each iteration as features to be developed and on the start of the iteration is design each feature.
When first approaching a project, prototype. But don't prototype everything. Prototype one important thing (one "use case" if that means anything) and "turn the inner eye to follow its path" - keep an eye out for the practical problems you encounter in trying to get that one thing done.
Now that you have some idea what it takes to do an important thing, you can design from more than just first principles.
Of course, this assumes you're working in an environment where you can turn out prototypes at minimal cost to ongoing development efforts. But if you're working in such an environment, pepper your design discussions liberally with prototypes. With any luck you may get to keep some of them.
note that agile methods are not an excuse to avoid designing, they just encourage testing of the design more frequently, and in smaller increments
i like to sketch the design and break its elements down until reasonably sure that there are no obvious unknowns or risks; unknowns and risks are highlighted for 'spike' projects, with a time-box for determining feasibility and notes on possible alternatives if the preferred methods prove unworkable
once comfortable with the overall architecture, jump into the features bottom-up (or in priority order) to complete the design, write the initial tests, then implement
EDIT: note that the question "design or prototype first" is making a bad assumption, i.e. that it is possible to prototype without doing any design, which of course is not the case (unless you are using the million-monkeys methodology)
Design first, unless you're willing to take the risk of throwing out all the work put into your prototype when you find it can't do what you need it to do. At a minimum, you should make some high level designs for your project that can help you make some decisions about how you're going to build your prototype so that you will have a minimum of wasted effort.
Maybe not an answer but a suggestion from my experience.
In most cases I'd be better off if I had started coding earlier. You can design until the cow comes home, but if the cows are on the horizon when you start coding, you might find your careful design hard to implement in time.
发布评论
评论（13）
首先进行设计总是比较安全，但这并不意味着原型设计不起作用。 原型设计的真正问题是在设计时抵制保留已经编写的代码而不是扔掉它的冲动。
It is always safer to design first, but this does not mean prototyping does not work. The real problem with prototyping is resisting the urge to keep the code you already wrote instead of throwing it away when the time comes to do the design.
没有灵丹妙药。 看起来设计第一是首选方法。 但您将无法预测实现设计时可能出现的所有复杂情况。 其中一些可能会成为表演障碍。 另外，如果您正在为客户写作，最好能够展示一些内容以确保你们达成一致。
在我的工作场所，我们两者都做——我们做一个快速原型，只是为了获得反馈并了解任何潜在的问题。 然后我们进行正式的设计和正式的实现。 在大多数情况下，我们能够从原型设计阶段挽救大量代码。 我喜欢这种方法，因为我们通常会得到干净、可维护的代码。
There is no silver bullet. It seems like design first is the preferred approach. But you will not be able to predict all complications that can arise while implementing your design. Some of them could potentially be show stoppers. Plus, if you're writing for a client, it's good to be able to show something just to make sure that you're on the same page.
At my workplace we do both - we do a rapid prototype, just to get feedback and get an idea of any potential problems. Then we do a formal design and formal implementation. In most cases we are able to salvage a lot of code from the prototyping stage. I like this approach, since we usually end up with clean, maintainable code.
请参阅高尔定律。 关键是迭代：设计一点，实施一点，测试一点，然后重复，直到您（或您的客户）满意为止。 这是新型“敏捷”方法的本质。
See Gall's Law. The key is to iterate: design a little, implement a little, test a little, then repeat until you (or your customers) are satisfied. This is the essence of the new breed of "agile" methodologies.
这取决于。
当需求或解决方案不一定明确时，原型设计最有用。 举个例子，我正在一个财务对账很重要的环境（大型商业保险）中做一个数据仓库项目。 该项目涉及大型原型设计工作，以获得与财务状况相符的系统。 由于围绕此的业务规则没有得到很好的记录，因此原型在暴露所有极端情况方面发挥了重要作用。
在其他情况下，设计优先的方法可能更合适。 这最适用于需求和合理的解决方案架构相当明显的情况。
It depends.
Prototyping is most useful when the requirements or a solution aren't necessarily clear. As an example, I am doing a data warehousing project in an environment (large commercial insurance) where financial reconciliation is a big deal. This project has involved a large prototyping exercise to get a system that will reconcile to the financials. As the business rules surrounding this were not well documented, the prototype was instrumental in exposing all of the corner cases.
In other cases, a design-first approach might be more appropriate. This is most applicable where requirements and a sensible solution architecture are reasonably obvious.
在开始工作之前，您必须对内聚架构有一定的了解。 对于大型系统尤其如此。
原型设计可用于设计的特定方面，例如表示层。
You must have some idea of a cohesive architecture before you start working. This is especially true of large scale systems.
Prototyping could be used for particular aspects of the design, e.g. presentation layer.
我认为这取决于您预先有什么样的业务需求。 如果它们（相对）详细且完整，那么我会根据这些要求进行设计。 如果一开始你几乎没有任何东西可以使用，那么就制作原型并向客户展示你得到的东西，以接收进一步的需求信息。
I think it depends on what kind of business requirements you have up-front. If they are (relatively) detailed and complete, then I'd design based on those requirements. If you have barely anything to work with in the beginning, then prototype out and show your customer what you got, to receive further requirement info.
您应该使用敏捷方法进行开发。 简而言之，你的设计就是你的。 团队与产品负责人一起定义要开发的主题列表，按重要性对它们进行排序，并在迭代中分割开发。 每次迭代都是要开发的功能，并且在迭代开始时设计每个功能。
请参阅此处了解更多信息。
You should develop using Agile Methodologies. Simply put, you design has you go. The team together with the product owner define a list of topics to develop, order them by importance, and split the development in iterations. Each iteration as features to be developed and on the start of the iteration is design each feature.
See more here.
当第一次接触一个项目时，原型。 但不要将所有东西都原型化。 为一件重要的事情制作原型（一个“用例”，如果这意味着什么的话）并“转动内心的眼睛去追随它的路径”——留意你在尝试完成那一件事时遇到的实际问题。
现在您已经了解如何完成一件重要的事情，您可以不仅仅根据第一原则进行设计。
当然，这假设您正在一个可以以最低成本为持续开发工作提供原型的环境中工作。 但如果您在这样的环境中工作，请在设计讨论中充分加入原型。 运气好的话，您可能会保留其中一些。
When first approaching a project, prototype. But don't prototype everything. Prototype one important thing (one "use case" if that means anything) and "turn the inner eye to follow its path" - keep an eye out for the practical problems you encounter in trying to get that one thing done.
Now that you have some idea what it takes to do an important thing, you can design from more than just first principles.
Of course, this assumes you're working in an environment where you can turn out prototypes at minimal cost to ongoing development efforts. But if you're working in such an environment, pepper your design discussions liberally with prototypes. With any luck you may get to keep some of them.
请注意，敏捷方法并不是避免设计的借口，它们只是鼓励更频繁地测试设计，并且
我喜欢以较小的增量绘制设计草图并分解其元素，直到合理确定不存在明显的未知数或风险； 突出显示“尖峰”项目的未知数和风险，并提供确定可行性的时间框，并说明可能的替代方案（如果首选方法证明不可行）
一旦对整体架构感到满意，则自下而上（或按优先顺序）跳入功能完成设计，编写初始测试，然后实现
编辑：请注意，“设计或原型优先”这个问题做出了一个错误的假设，即可以在不进行任何设计的情况下进行原型设计，当然情况并非如此（除非您使用百万猴子方法）
note that agile methods are not an excuse to avoid designing, they just encourage testing of the design more frequently, and in smaller increments
i like to sketch the design and break its elements down until reasonably sure that there are no obvious unknowns or risks; unknowns and risks are highlighted for 'spike' projects, with a time-box for determining feasibility and notes on possible alternatives if the preferred methods prove unworkable
once comfortable with the overall architecture, jump into the features bottom-up (or in priority order) to complete the design, write the initial tests, then implement
EDIT: note that the question "design or prototype first" is making a bad assumption, i.e. that it is possible to prototype without doing any design, which of course is not the case (unless you are using the million-monkeys methodology)
首先进行设计，除非当您发现原型无法完成您需要做的事情时，您愿意冒着放弃原型中所有工作的风险。 至少，您应该为您的项目进行一些高级设计，这可以帮助您做出一些有关如何构建原型的决定，从而将浪费的精力降到最低。
Design first, unless you're willing to take the risk of throwing out all the work put into your prototype when you find it can't do what you need it to do. At a minimum, you should make some high level designs for your project that can help you make some decisions about how you're going to build your prototype so that you will have a minimum of wasted effort.
如果我知道自己想要构建什么，我就会直接进行设计。
如果我正在为客户构建一些东西，那么我会制作原型来缓解用户更具体的需求。
If I know what I want to build, I just go right to design.
If I'm building something for a client, then I prototype to ease out more specific requirements from the users.
也许不是答案，而是我的经验中的建议。
在大多数情况下，如果我早点开始编码，我会过得更好。 你可以设计直到牛回家，但如果当你开始编码时牛就在地平线上，你可能会发现你精心的设计很难及时实施。
Maybe not an answer but a suggestion from my experience.
In most cases I'd be better off if I had started coding earlier. You can design until the cow comes home, but if the cows are on the horizon when you start coding, you might find your careful design hard to implement in time.
逐步迭代。
设计一点，实现一点。
从设计开始，您可能会遇到隧道效应，在实际实施之前您无法获得任何真实的反馈。
如果一开始就没有设计，你可能会做出让自己后悔的决定。
理想的情况是能够实现系统的非常骨架的端到端版本，可以对其进行测试并向客户演示。
Go incrementally and iteratively.
Design a bit, implement a bit.
Starting with a design you can suffer from a tunnel effect where you cannot have any real feedback before you actually implement something.
Starting without design, you can take decisions you'll regret.
The ideal situation is to be able to implement a very skeletal end-to-end version of your system that can be tested, and demonstrated to the customer.