成长计划第一版上线已经四个月了，参与人数已经有四十万，期间又迭代了好几版。但是，现在回顾当初的设计，觉得有些欠妥。在此做一个回顾，毕竟以后也没什么机会再去想这些了。
第一版成长计划的核心是围绕着计划展开的，每个计划下面关联着详情、任务、勋章、提醒等，典型的主从表。
看起来，大概是这样的：
主要的功能就是：开始测试、生成计划、查看计划、完成任务、获得奖励。业务就这么简单，但是做起来可能并没有想象中的辣么简单。具体的实现前文已经说过，不再详陈。服务只有三个，结构也非常简单，如下图所示
故事的开头总是一帆风顺，无限美好。单单看成长计划，很简单，功能也比较单一。毕竟它只是一个提高用户留存和会员转化的工具而已。
但是，当它和新手礼包、微信裂变、会员等一起用的时候，业务就有些复杂了。
2. 成长计划+微信裂变
刚开始，阵地只是APP，后来扩大到微信，目的也很明显：拉新。这个时候就有些不一样了，问题来了：
1、一个普通的H5页面，只要是微信用户就可以点开。也就是说，非用户也可以参与。就这一点就够头疼的，因为在APP里面要求必须是我们的用户才能参加。为了兼容这种情况，我在计划主表上新增了一个渠道（channel 1:APP 2:微信）字段用于标识来源。还有，非用户开启了计划，但是他看不到，需要输入手机注册为我们的用户以后登录APP才能看到。这就需要有一个地方先存着这些非用户开启计划的数据，等到他成为用户以后再讲数据迁移过去。对于这种临时数据，为了不新建表，我直接存到了MongoDB中，为了能快速判断用户输入的手机号是否已经有计划了（以最后一次测试结果为准），我将手机号存到了Redis中。当用户注册成功以后，通过MQ我收到消息，便将数据迁移至MySQL。这样就完成了一个用户拉新。
2、当一个用户把链接分享出去（微信群、朋友圈等）以后，有三个人因此而成为我们的用户的话，就给分享者一张7天会员体验卡。简单地理解，就是拉3个新用户就得7天会员体验卡。这就必须要记着谁是因为点了谁的链接而成为用户的，需要记录这个对应关系。这个当然也是在临时数据中保存。
3. 成长计划+会员
最初，完成成长计划获得勋章（PS：成年人可能不能理解，勋章有毛用啊，我QQ勋章多得是……但是，请回忆一下，小时候为了收集各种卡片而买了多少小浣熊方便面）。后来，又新增了一种奖励：会员体验卡。完成7个计划以后，就得7天会员体验卡。这就意味着：
1、新增一种奖励类型（1：勋章，2：体验卡）。必须在生成计划的时候就要判断出，完成本次计划到底是得勋章还是得体验卡。因此，要在计划主表上新增一个字段以标识奖励类型。
2、勋章和体验卡的属性不一样，也就是字段不一样。本来它们是可以放在一起的，但是考虑到二者的获得的方式，也为了不想改动一起的逻辑，更为了便于日后数据统计，于是新增了一张表用于保存体验卡，等于说勋章是一张表，体验卡又是一张表。这里再多解释一下什么叫获得方式不同，勋章是常规任务奖励，体验卡算是额外的奖励。
4. 成长计划+AB测试
这里AB的区别在于测试题目不一样，这就意味着计算方式需要调整一下。这个小功能主要是通过前端传的标识来返回不同的数据而已，但是麻烦的是，我这边要记录有多少人是A，多少人是B，包括用户点到第几个页面，于是加了表保存打点数据。
5. 成长计划+新手礼包
成长计划和新手礼包打通以后，可以通过在成长计划完成任务来使奖励翻倍，比如新手礼包是7天会员体验卡，那么在成长计划完成任务后时长翻倍就变成14天了，如果没有领新手礼包，那么在成长计划页面也可以领，领完以后接着开启翻倍任务。至于首页楼层如何展示，是展示新手礼包楼层，还是成长计划楼层，以及成长计划楼层展示那种状态就不再详述了，是业务而定。稍微麻烦一点的是：在原来成长计划的常规任务前面硬生生加了一个新手礼包奖励翻倍任务。这个任务与常规任务大不一样，任务完成的方式也不一样，因此在目前的结构上来看，只能单独处理。
未来， 成长计划还有更多可能。成长计划简直就是儿童内容领域的互联网+ （PS：我自己胡诌的）
7. 成长计划之数据打点/统计