今天整体上又恢复了一些，手腕的疼痛也有所缓解，不过总还是有点感冒的阴影，不是那么100%的状态。导致今天需求讨论会上又有些着急，没能做到我师父亮哥的心如止水。
继续来看下一个原则，这个原则起的名字叫曳光弹，这个曳我还百度了一下读音读作夜。我理解概念上近似于常说的POC (proof of concept) 也就是用一个简单的能够跑的代码来验证一些新的技术和概念。他通常用来在新技术或者新概念引入之前，利用极其简化的模型，以微小的代价做出一个能够跑的系统，来证明这个技术和概念的可行性。
这个原则非常有用，首先能帮助我们以较小的代价试错，比如我们今年引入了一个report的引擎data wiz，那么在引入之前除了听引擎方的介绍之外，最主要的工作就是快速用这个引擎和我们的系统结合做一个最简单的excel报表。在这个过程中，我们基本上能确认工具的适用性，基本能力，使用复杂度，后续扩展性等诸多需要清楚的方面，所谓百闻不如一见，百见不如一试。
曳光弹也不仅仅只用用来试错，还有一个非常重要的目的是引发思考不断完善，这个常常被用在复杂产品的设计中，比如我们今年做的一个快速放箱的POC，一个船公司，车队，堆场，客户，四方之间利用二维码快速提取空箱的业务模式，要把这么多参与方都加进来，整理需求，完善系统是一个大工程。用一个简化的，快速的，基本上现有流程的基础上稍作修改的，各方快速的尝试一下，有利于各方进一步明确诉求与收益，对推进的障碍和阻力也有所准备，在此基础上针对性的优化流程和系统，能起到事半功倍的效果。
实际上曳光弹的思想可以用在方方面面，可大可小，比如这两天戴夫同学在做计费模块的性能调优，在正式改动代码之前，他整了一些数据，用预想的思路和方法做了些实验，来明确调优的思路与方式是不是如预期所想，快速试错，再基于此进行调整，也是一种曳光单，是帮助快速达到成功彼岸的好工具。
小结一下，曳光弹，用在拿不定主意，或者对方案不确信，或者有些实际需求模糊不清的情况下，利用缩小范围抓核心，快速实现明方向，促进思考再完善的方式，啃下一块难啃的骨头。
