引言
我在几个电子商务的项目中碰到这样的问题，网站因频繁推出各种商业促销活 动，并随着活动临近上线，技术开发人员不得不着急添加新的代码或修改程序以 满足新活动的要求。更“可怕”的是，这些活动上线的时机恰逢在周六周日和重 要节假日，开发人员和测试人员苦不堪言。记得七月份连续几个周六日，网站接 连上了三个促销活动：（一） 指定一些商品满三百减一百；( 二 ) 在活动一的 基础上再全场积分五十倍返还；( 三 ) 钻石用户在以上活动基础上再全场商品七 五折。促销活动的流程是这样的，活动的期间、参与活动的商品范围和活动规则 由市场和运营部一起定制，由技术部门实现和测试，最后由市场和运营进行验收 ，然后部署到生产环境。但由于活动规则的无规律性，技术部门在设计活动时很 难做到扩展性和复用性俱佳的设计，调整程序是不可避免的，使得每次上活动必 须相应调整很多代码。经初步分析，程序调整将涉及到商品展示，购物车和下订 单，这些调整几乎涉及到了网站的所有展示前台。这对技术部门提出了一个不小 的挑战。
从下图中我们可以看到活动实施前后的主要阶段和所花费的人力和时间。
图 1. 传统实现方式的周期示意
以上过程中开发和测试所花的时间将是整个过程中最长的，压力无疑也是最大 的。为了“挽救”这种对技术部门的不利局面，技术部门提出了一种新的解决办 法：将各种活动规则由运营人员“翻译”成公式，开发人员提供一个能影响活动 结果的公式“插件”，“插入”到需要受活动影响的地方。
从下图中我们可以看到按新的解决方案执行前后的主要阶段和所花费的人力和 时间。相对先前的模式，公式的编写和测试的周期相对技术部门的开发周期要短 很多，所以不会导致市场和运营部门过大的压力，但是对运营者角色提出了更高 的要求，他们需要学习掌握怎样编写公式。但相对于整体实现周期的大大缩短， 这些付出是很值得的。
图 2. 新的实现方式的周期示意
实现一个公式系统