MSDN Online Voices - More or Hess：演示剖析
你们有些程序员可能很轻松：舒舒服服地坐在桌子前，按照事先精心设计的规范编写代码。面前的里程碑经过精细策划，清楚地标识着组里所有成员为之奋斗的功能目标。在开发周期的某些阶段，你们会进入所谓“最后冲刺”的阶段。计划风险重重，当然，每个人都要工作到深夜，还要在周末加班，才能完成计划。尽管如此，你们面前的道路往往是清晰可见的。大家很清楚自己要去哪里，怎样才能到达。
另一些程序员的境遇则完全不同。这些人设计和开发的代码仅仅是用作演示，或者是用来展示即将开发的软件解决方案的原型。不是每个公司都进行和需要这种开发的。但是毫无疑问，这种工作需要一类不同的程序员，同样，这类编程需要一类不同的编程方法。
我这里所说的演示并不只是在观众面前演示一个已完成（或接近完成）的应用程序的功能。我所说的是，在对于“实际”产品还根本未做多少开发的情况下，对产品演示进行的设计与开发。这种演示用来向管理人员、合作伙伴和投资者展示应用程序和技术所具备的“潜力”。
在一个基于 GUI/Web 的环境中工作，在开发周期中的某些时候，一切都取决于它“看起来”像什么。而如果演示的目的是唤起兴趣和制造兴奋，演示的视觉效果就往往会成为清楚阐述意图的关键。
想象一下如何演示将 PC 连接至家庭自动化。你的应用程序上有个按钮，上面写着“关灯”。你按下按钮，灯灭了。是啊，真没劲。现在，想象一下这个演示是用 PocketPC 来做的。屏幕上出现的是房间布局的俯视图，还标出了灯的位置。演示者使用“拖放”功能从房间里选择了几个灯，把它们拖到 PocketPC 屏幕的虚拟开关上。然后，演示者轻轻一按屏幕上的虚拟开关，所有选中的灯都灭了。接着，演示者将虚拟开关拖到房间里代表开关的图标上。他走向开关并轻轻按下开关，所有的灯又都亮了。是的，还是一个简单的演示，不过给人的印象比第一个深刻多了。从技术角度讲，这个演示实在没什么变化；改变的只是进行演示的方式和完成演示所使用的道具。
需要着重注意的一点是，这样一个小小的自动化演示，并不能代表在通常情况下系统的使用方式。我的意思是，有多少人愿意这样来开灯和关灯呢？——不得不打开 PocketPC，查看房间的布局图，选择灯，把它们拖到屏幕的按钮上，然后按下按钮。在现实生活中，这样的工具的使用时间是很短的：第一次安装自动化系统时用它们来“设置”房间里灯开关的物理位置，然后就很少使用了。但是，如果你只是走向一个实在的开关，轻轻一按，一盏灯亮了。然后告诉观众：“相信我，这盏灯是通过家庭自动化系统与开关连接的。”这样的演示又怎能让人兴奋呢？
要完成这样的原型和演示，需要一类略有不同的程序员和一种不同的思维方式。一切以一个演示脚本开始，这个脚本用来简单地介绍你认为能够打动人的演示是什么样子的。也许你需要使用像 Adobe PhotoShop 或 Microsoft PowerPoint® 这样的工具来制作几幅界面模拟图。这样可以推动进程，帮助组里的其他成员从总体上把握演示需要传达的概念。下一步，你需要编写一些底层技术基础结构——只要足够让你连接部分组件并令其工作即可。然后，开始创建要使用的视觉界面，要尽量让它们引人注目。
在这一过程中，让许多开发人员比较难以理解的一点是，他们很少根据一个定义清晰的技术规范来展开工作。他们不是在创建一个能够完美工作多年的、稳定而结构完善的基础结构；他们所做的是迅速将刚好够用的真实代码片断拼凑在一个新奇的界面下，从而使演示尽可能真实。
设计这种演示的时间要求往往也很残酷。设计演示方案的时间距演示时间只有几周的情况是很常见的。任务组迅速地分配任务，以求在最后期限内完成一切。正在这时，经理走进来向大家宣布，公司的副总裁听了有关演示的介绍感到非常兴奋，下周就想看到演示。当天，过了一些时候，经理又回来告诉大家，公司的 CEO 将在第二天召开员工会，希望在会上看到演示，以便定位它和其他几种正在开发的技术。这样，曾经是两周的期限——这已经够短了——突然被缩减到仅仅 24 小时。生命之车驶入了快车道。
但是，对于开发人员而言，最困难的可能是临时性的通知，整个演示可能会被更改，甚至变得面目全非。就其本质来说，这些演示需要快节奏而且富于动感。作为基础的脚本和方案经常在一天之内发生根本性的改变。由于开发人员被飞速涂写的概念弄得无暇喘息，他们的工作方式经常是与其他成员进行头脑风暴式的讨论，以确定怎样才能使演示更打动人、更好地阐明计划开发的底层技术。
现在，想象你已越过了所有这些障碍。你和队友们已经创建了一个令人兴奋的演示方案，该方案与某些底层技术具有很好的联系性。在整个过程中，你把自己想象成电影“星际旅行”中的总工程师，经过与敌人的浴血奋战夺回远程传送器，重新回到了自己的时空。你控制了局势，但只是暂时的。现在，真正的考验到来了。公司管理层要观看你的演示，以决定你的方案是否值得人员和资金的投入——这是赋予方案生命力的必要因素。
让我们假设演示进行得非常完满，不只是演示方案本身抓住了观众的注意力，你甚至还为一些可能被即兴问到的功能做了准备。当然，如你所料地，一些问题被提到了，而演示恰好能够说明被询问的情况是如何处理的。这可以说是数周——有时是数月——以来长时间艰苦工作和无数次反复设计的最完美的结局。
面对这种情况，最可能出现的问题是：这个演示“过于”完美了。它看上去工作得如此完美，将有关的技术阐述到了如此程度，让观众们认为大部分工作已经完成了。他们不能理解为什么你需要两年的时间和四倍的人员与预算来完成这个程序：它看上去只用了三周开发时间，而且已经完成了 80% 的工作。
有时候，生活就是这样不公平。
