北京最好治疗白癜风 http://www.wxlianghong.com/上一篇文章提到了曳光代码与原型设计有着不同的作用领域。在我熟知的世界里哪些是原型设计呢？在开发一个管理信息系统之前，我们大多数都会一个静态页面的Demo，来展示系统的大体功能与构成，以及大致是怎么实现用户的需求。在其他的领域呢？比如说在汽车制造的行业，肯定是先设计出各种各样的模型，来验证或测试汽车在某一方的性能和技术指标。虽然我不熟悉制造行业，但我敢肯定他们不会直接生产实车来进行测试。因为使用模型，测试周期短，效果好，并且花费要少很多。然后心中萌生一个想法，在我自己了解的软件领域中只有画Demo吗？又回想了一下最近几年的工作，突然发现有很多事情我都做了原型的设计。在一次系统的性能改善中，为了调查重复定义字符串对于系统性能的影响，于是做了两个对比示例：一个在循环体内定义变量，另一个使用StringBuilder在循环体外定义变量。将同样的文字加载到页面中，当循环次数到达次的时候，两个实例加载时间就相差很多了，对于内存的负载也是大不相同。于是我们做出了关于性能改善的提案。还有一次，在最近想在系统中新添加一个实时桌面通知的功能，我新建了一个工程，首先实现了基于浏览器的桌面通知功能，然后结合SignIR实现了实时的功能，然后Notification+SignIR的实时桌面提醒功能的技术调查与实现就完成了。
然后我发现，原型制作是为了学习和验证。
什么工作可以选择制作原型？
有风险的、未知的，关键的或者让你很不舒服的东西都可以先进行原型设计来预测风险和制定风险对策，来验证正确性、可行性等等。例如下面这些书中提到的事物：
架构
已有系统中的新工程
外部数据结构和内容
第三方工具和组件
性能问题
用户界面设计
但是不用纠结于原型的代码是不是够完美，重要的是经验教训。
怎样使用原型？
软件中下面这些方面不要纠结，否则你可能在直接打造一部车。
正确性。就像在静态页面中你必然会使用一些虚设的数据。
完整性。在有限的条件中完成最直接的验证，有时验证了技术的可行性就可以了。
健壮性。放弃那些check吧，即使你演示Demo的时候，由于偏离了原定演示方案发生了崩溃时间，就当是放了烟火了，然后告诉他们这个只是原型。
风格。不一定是代码，代码不一定需要注释，也不一定需要设计书。有可能只是在白板上的几张便笺的演算式而已。
原型的产物
在系统架构中，制作原型时需要寻求答案的问题，就是我们制作原型的原理（原书中的内容）：
主要组件的责任是否得到了良好定义？是否妥当？
主要组件的协同是否得到了良好的定义？
耦合是否得以最小化？
能否确定重复的潜在来源？
接口的各项定义和各项约束是否可以接受？
每个模块在执行过程中是否能访问到其所需的数据？是否能在需要时进行访问？
最后提醒大家一下，并不是所有人都能够原型是个什么东西。比如用户可能在Demo演示的时候指出你的数据不够准确。那么你需要判断你在做的东西对未来的代码到底起到什么作用，如果你在开发一个未来可以坚实使用的系统底层，适时的选择曳光代码的方式。
往期文章：
高效程序员途径4：曳光弹
-08-12
高效程序员途径３：坚持可撤销性的留好后路
-08-06
高效程序员途径2：使用正交（附带一题求解答）
-07-31
高效程序员的途径1：解决重复的代码
-07-30
预览时标签不可点收录于话题#个上一篇下一篇
