然后我发现，原型制作是为了学习和验证。
什么工作可以选择制作原型？
有风险的、未知的，关键的或者让你很不舒服的东西都可以先进行原型设计来预测风险和制定风险对策，来验证正确性、可行性等等。例如下面这些书中提到的事物：
架构
已有系统中的新工程
外部数据结构和内容
第三方工具和组件
性能问题
用户界面设计
但是不用纠结于原型的代码是不是够完美，重要的是经验教训。
怎样使用原型？
软件中下面这些方面不要纠结，否则你可能在直接打造一部车。
正确性。就像在静态页面中你必然会使用一些虚设的数据。
完整性。在有限的条件中完成最直接的验证，有时验证了技术的可行性就可以了。
健壮性。放弃那些check吧，即使你演示Demo的时候，由于偏离了原定演示方案发生了崩溃时间，就当是放了烟火了，然后告诉他们这个只是原型。
风格。不一定是代码，代码不一定需要注释，也不一定需要设计书。有可能只是在白板上的几张便笺的演算式而已。
原型的产物
在系统架构中，制作原型时需要寻求答案的问题，就是我们制作原型的原理（原书中的内容）：
主要组件的责任是否得到了良好定义？是否妥当？
主要组件的协同是否得到了良好的定义？
耦合是否得以最小化？
能否确定重复的潜在来源？
接口的各项定义和各项约束是否可以接受？
每个模块在执行过程中是否能访问到其所需的数据？是否能在需要时进行访问？
最后提醒大家一下，并不是所有人都能够原型是个什么东西。比如用户可能在Demo演示的时候指出你的数据不够准确。那么你需要判断你在做的东西对未来的代码到底起到什么作用，如果你在开发一个未来可以坚实使用的系统底层，适时的选择曳光代码的方式。往期文章：
高效程序员途径4：曳光弹
-08-12
高效程序员途径３：坚持可撤销性的留好后路
-08-06
高效程序员途径2：使用正交（附带一题求解答）
-07-31
高效程序员的途径1：解决重复的代码
-07-30
预览时标签不可点收录于话题#个上一篇下一篇