起因
软件开发过程中，很关键的一步就是要确定需求，然而需求并不是一成不变的。由于用户需求不明确，产品设计不合理，技术上无法实现等等原因导致需求的改动是很常见的，那么如何在开发过程中帮助确立真正的需求并减少需求改动导致的返工就是今天要讨论的主题。
开发模式介绍
原型模式
原型模式是一种用于探索性编程的模式，它的目的是为了在开发过程中尽早的发现问题，而不是为了最终的产品。原型模式的代码通常是临时的，不会被用于最终的产品中，但是它们可以帮助我们更好的理解问题，从而更好的解决问题。
在很多时候，可以使用原型来尝试特定的想法：原型制作比完整的产品制作要便宜的多，非常适合在实际工作开始之前对可行性以及其他相关问题进行验证。原型只对整体流程进行把控，并不关心具体的细节，如果当前的场景并不允许忽略细节，那么此时可能更适合使用曳光弹模式。
对于任何觉得有风险的东西，任何之前没有尝试过或对最终系统来说很关键的东西，任何未经证实、实验性或可疑的东西，以及任何让你不舒服的东西都可以使用原型。比如：
- 架构
- 已存在的系统中的新功能
- 数据结构或外部数据的内容
- 第三方工具或组件
- 性能问题
- 用户界面设计
原型设计是为了学习经验，它的价值不在于产生的代码，而在于吸取的教训。
不要把原型所产生的代码用于产品当中。
原型并不限制实现的语言，可以随意选用能更好的表达当前主题的编程语言，甚至不需要编程，一块白板，一些便签就够了。
制作架构原型
可以通过原型对整个系统建模，尽量推迟思考袭击而，需要确定的是，系统的各个部分是怎么结合成一个整体的。下面是一些特定领域，希望借由架构原型中找到其相关问题的答案：
- 主要组件的职责是否恰当，有没有定义清晰？
- 主要组件之间的协作是否定义清晰？
- 耦合度最小化了吗？
- 能确定重复的潜在来源吗？
- 接口的定义和约束能否接受？
- 在执行过程中是否每个模块都有访问所需数据的途径，在需要数据的时候，能访问到吗？
如果使用得当，原型利于在开发的早期就识别出潜在的问题点，并给予纠正——此时修正错误不仅廉价还容易。
如果可以明显的确定需要更多的细节，或者在所处的环境中，原型代码的目的有可能会被误解，那么此时可以考虑换用曳光弹模式。
曳光弹模式
在构建一些从未做过的东西时，就像尝试在黑暗中击中目标，由于缺乏经验，很难一次就做对，因此需要一种方法来帮助我们找到正确的方向。曳光弹模式就是这样一种方法，它可以帮助我们在黑暗中找到正确的方向。通过观察轨迹，得到反馈，进行修正，直到最终命中目标。
曳光弹之所以有用，是因为其工作环境和约束与真实子弹的相同。曳光弹能快速抵达目标，所以可以得到即时反馈。为了从编码中获得相同的效果，通常会找一些东西，能让我们快速、直观、可重复地从需求中得到最终的某个方面。类似于原型模式，首先寻找重要的需求，那些定义了系统的需求，寻找有疑问的地方，你认为有重大风险的地方。对这些地方进行优先级排序，首先从这些地方开始编码。
模式实践
比如需要开发一个具有五个架构层的系统，当我们对它们是如何集成的有些疑虑，那么就先实验一下这些层次是如何工作的，将五个层次之前的关系先打通，能够获得一个可用的环境，再去添加各种功能。
曳光弹代码的优势：
- 用户可以更早地获得能工作的东西
- 开发者构造了一个可以在其中工作的框架
- 有了一个集成平台
- 有可以演示的东西
- 对进度有更好的感觉
曳光弹并不能总击中目标，它会告诉我们击中了什么，需要不断调整瞄准，直到击中目标。当出现问题的时候，不要诧异，去弄清楚如何改变已经做好的东西，想办法让它靠近目标。受益于这种精益的开发方式，小块代码惯性也小——容易快速地变更。能够以更快的速度、更小的成本，收集到针对应用程序的反馈，并生成一个新的更准确的版本。
区别
原型生成的是一次性代码；曳光代码简单但是完整，它是最终系统框架的组成部分。可以将原型制作看作是在发射一颗曳光弹之前进行的侦察和情报收集工作。
总结
工欲善其事必先利其器，在开发之前和开发过程中，善用这些模式，可以提高开发效率，减少不必要的返工，让开发的过程更快乐。
以上内容来自《程序员修炼之道》