曳光弹之我的理解

最近看程序员修炼之道，看到曳光弹这里，一直被这个概念所困扰。

因为一直以来基本上碰到需求肯定是先写一个简单的Demo来实现，然后再将这些代码整理重构之后放入相应的模块中。

这可以简单的理解为原型。

但是显然与曳光弹不同，曳光弹的作用在于不断的接近目标，也就是用于定位目标。

那么实际的软件开发中又是如何使用曳光弹呢？

这一直困扰着我，然后查找相关资料才有点点感悟，却不知是否正确。

在我的理解中，可能是这样的。

某个需求到达了，那么为了开发这个需求，可能需要先写一部分相关业务逻辑代码。

但是这部分逻辑代码却不是很明确是否能够达到该功能的需求的要求，那么就需要写部分测试代码，来调用这部分逻辑代码，来证实这些代码是否可行。

这就是曳光弹的作用，在于黑暗中起到一个指向目标的作用.

所以这里与原型非常相似，但是又有不同，原型可能只是简单的能够达到演示的效果，甚至于可能还存在bug/奔溃等现象。

但是演示完了，原型将被彻底抛弃。而曳光弹则不同，可以随时进行测试与目标之间的差距，然后再次矫正。

如此，直到达成目标。一次次校验，却不抛弃，这可能就是与原型比较大的区别。

也可以参照http://geeker.blogbus.com/logs/49134150.html这里的观点。

曳光弹和原型
二者很像，最大的区别在于，曳光弹是最终开发的一部分，原型则很可能不会被带入开发
曳光弹可以作为最初迭代的开始，从最简单的串联起整个系统开始，支撑起一个软件身躯，后面的迭代就是让着身躯更加充实
原型可以采取任何形式，甚至与最终开发的手段完全不同，但它们为客户和开发人员架起一座桥梁，基于这座桥梁，开发人员可以更好的理解需求，明白最后要做到什么，而客户也更明确自己想要什么，还差什么