引 言 在黑暗中用机枪射击有两种方式(非咬文嚼字)。你可以找出目标的确切位置(射程、仰角及方位)，也可以确定环境状况(温度、湿度、气压、风等)。你可以确定你使用的弹药筒和子弹的精确规格，以及它们与你使用的机枪的交互作用。然后你可以用计算表或射击计算机计算枪管的确切方向及仰角。如果每一样东西都严格按照规定的方式工作，你的计算表正确无误，而且环境没有发生变化，你的子弹应该能落在距目标不远的地方。
或者，你可以使用曳光弹。
曳光弹与常规弹药交错着装在弹药带上。发射时，曳光弹中的磷点燃，在枪与它们击中的地方之间留下一条烟火般的踪迹。如果曳光弹击中目标，那么常规子弹也会击中目标。
并不让人惊奇的是，曳光弹比费力计算更可取。反馈是即时的，而且因为它们工作在与真正的弹药相同的环境中，外部影响得以降至最低。
这个类比也许有点暴力，但它适用于新的项目，特别是当你构建从未构建过的东西时。与枪手一样，你也设法在黑暗中击中目标。因为你的用户从未见过这样的系统，他们的需求可能会含糊不清。因为你在使用不熟悉的算法、技术、语言或库，你面对着大量未知的事物。同时，因为完成项目需要时间，在很大程度上你能够确知，你的工作环境将在你完成之前发生变化。
经典的做法是把系统定死。制作大量文档，逐一列出每项需求、确定所有未知因素、并限定环境。根据死的计算射击。预先进行一次大量计算，然后射击并企望击中目标。
然而，注重实效的程序员往往更喜欢使用曳光弹。
在黑暗中发光的代码
曳光弹行之有效，是因为它们与真正的子弹在相同的环境、相同的约束下工作。它们快速飞向目标，所以枪手可以得到即时的反馈。同时，从实践角度看，这样的解决方案也更便宜。
为了在代码中获得同样的效果，我们要找到某种东西，让我们能快速、直观和可重复地从需求出发，满足最终系统的某个方面要求。
作者举例分析
有一次，我们接受了一个复杂的客户－服务器数据库营销项目。其部分需求是要能够指定并执行临时查询。服务器是一系列专用的关系数据库。用Object Pascal编写的客户GUI使用一组C库提供给服务器的接口。在转换为优化的SQL之前，用户的查询以类似Lisp的表示方式存储在服务器上；转换直到执行前才进行。有许多未知因素和许多不同的环境，没有人清楚地知道GUI应该怎样工作。
这是个使用曳光代码的好机会。我们开发了前端框架、用于表示查询的库以及用于把所存储的查询转换为具体数据库的查询的结构。随后我们把它们集中在一起，并检查它们是否能工作。使用最初构建的系统，我们所能做的只是提交一个查询，列出某个表中的所有行，但它证明了UI能够与库交谈，库能够对查询进行序列化和解序列化，而服务器能够根据结果生成SQL。在接下来的几个月里，我们逐渐充实这个基本结构，通过并行地扩大曳光代码的各个组件增加新的功能。当UI增加了新的查询类型时，库随之成长，而我们也使SQL生成变得更为成熟。
曳光代码并非用过就仍的代码：你编写了它，是为了保留它。它含有任何一段产品代码都拥有的完整的错误检查、结构、文档、以及自查。它只不过功能不全而已。但是，一旦你在系统的各组件间实现了端到端的连接，你就可以检查你离目标还有多远，并在必要的情况下进行调整。一旦你完全瞄准，增加功能将是一件容易的事情。
曳光开发与项目永不会结束的理念是一致的：总有改动需要完成，总有功能需要增加。这是一个渐进的过程。
曳光代码的优点
- 用户能够及早看到能工作的东西。如果你成功地就你做的事情与用户进行了交流，用户就会知道他们看到的是还未完成的东西。他们并不会因为缺少功能而失望。
- 开发者构建了一个他们能在其中工作的结构。能够尽早的把你所要设计的东西体现到具体的代码里，你的团队会变得更有生产力。
- 你有了一个集成平台。一旦新的代码通过了测试，你就可以把它们集成进来，你拥有了一个环境。
- 你有了可用于演示的东西。拿给项目出资人和高级官员他们看。
- 你将更能够感觉到工作进展。
曳光弹并非总能击中目标
曳光弹告诉你击中的是什么。那不一定就是目标。于是你可以调整准星，直到完全击中目标为止。这正是要点所在。
大多数情况下，你不能100%确定该在何处使用这项技术。如果最初几次尝试错过了目标——用户说：“那不是我的意思”。——你不应感到惊奇。找出怎样改变已有的东西、让其更接近目标的办法才是最重要的。
( 文章内容摘自《程序员修炼之道》，更详细内容也可以参阅该书 )
个人感触
较传统的软件设计方法大多使用模块设计，任务比较繁重，而且并不便于开发人员做优化控制，往往是等到所有的模块开发完毕，才可以将应用呈现给用户。
曳光弹这种方法其实大多数程序员都或多或少的使用过，一段并不完整的代码，一个简单的功能实现其实都是应用了曳光弹的设计思想。在《程序员修炼之道》书中还提到曳光代码和原型制作的相互比较，其实我个人认为原型的设计很大程度上依赖于用户最初提出的需求；另外原型设计强调的是方便与用户更好的交流，从而可以更具体地探究最终系统的设计。原型设计更多应用在软件设计的初期，而且原型本身往往没有价值，通过原型学到的经验教训才最有价值。
曳光弹的使用就大大不同，它虽然简约，但却是完整的，并且可以作为最终系统的一部分来使用。正如上面文中所述：曳光代码并非用过就仍的代码：你编写了它，是为了保留它。
Trackback: http://tb.donews.net/TrackBack.aspx?PostId=356855