1. 回顧
成長計划第一版上線已經四個月了，參與人數已經有四十萬，期間又迭代了好幾版。但是，現在回顧當初的設計，覺得有些欠妥。在此做一個回顧，畢竟以后也沒什么機會再去想這些了。
第一版成長計划的核心是圍繞着計划展開的，每個計划下面關聯着詳情、任務、勛章、提醒等，典型的主從表。
看起來，大概是這樣的：
主要的功能就是：開始測試、生成計划、查看計划、完成任務、獲得獎勵。業務就這么簡單，但是做起來可能並沒有想象中的辣么簡單。具體的實現前文已經說過，不再詳陳。服務只有三個，結構也非常簡單，如下圖所示
故事的開頭總是一帆風順，無限美好。單單看成長計划，很簡單，功能也比較單一。畢竟它只是一個提高用戶留存和會員轉化的工具而已。
但是，當它和新手禮包、微信裂變、會員等一起用的時候，業務就有些復雜了。
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. 成長計划之數據打點/統計
開發任何功能，數據打點（或者叫埋點）都是必須的，是非常重要的。沒加打點，就好比是服務上線了卻沒有監控，這就沒有指標數據參考了呀。
打點主要跟客戶端密切相關，一般都是在客戶端打點，將數據采集上報到大數據那邊。服務端的打點也有，但相對較少。不過，為了后續統計更方便，必要的服務端打點還是不能少的。
這一次，除了用戶的行為，已經路徑（點到哪一個頁面了）等等這些數據外，其它絕大部分產品需要的統計都可以從數據庫里查出來。比如，每天新增用戶多少，會員轉化率多少，每日時長，次日留存，微信過來的有多少，發了多少體驗卡，AB哪個效果好一點等等。
8. 成長計划之彈窗
每個任務開始和結束的時候有彈窗，計划完成或過期有彈窗。最初設計的時候，彈窗是單獨的，與某個計划沒有關系，每次進首頁該彈什么窗都是根據計划完成情況計算出來的。后來，隨着業務越來越復雜，彈窗也有點亂了。比如，體驗卡的彈窗和勛章的彈窗就不一樣，翻倍任務的彈窗和常規任務的彈窗又不一樣。以至於后來，什么時候彈什么窗這部分邏輯變得越來越復雜。
后來，我想了一下，如果最好還是把彈窗與任務綁定在一起比較好。當前是什么任務就彈什么窗，給什么獎勵，多么清晰，多個簡潔明了。
9. 結構優化
我后來想到的是，將彈窗和獎勵都和任務進行綁定，而任務之間又是層層遞進的關系。
就像，攔截器和過濾器。類似的還有，js中的事件冒泡，設計模式中的責任鏈模式
於是，主要的關聯關系就變成了：計划之下是內容和任務，任務之下是獎勵和彈窗，APP和微信消息提醒是獨立的。
於是，按照我的設想，一個計划的生命周期應該是這樣的：
任務有任務類型：一次性任務和周期性任務。所謂一次性任務就是指完成就進入下一個任務，比如常規任務；周期性任務指的是每天任務都從新開始，直到任務完成，比如翻倍任務就是這樣的。
任務之間又內在的關聯關系，就像一個鏈表一樣，要知道它的上一個任務和下一個任務都是誰。
有了這種鏈表結構，那么想增加一個任務或者刪除一個任務就變得輕而易舉，如此巧妙靈活的設計，我可真是個小機靈鬼
再回到這次的翻倍任務上來，這種任務跟常規任務不一樣，獎勵什么的運行方式乃至彈窗都不一樣，簡直要瘋了。如果我們的任務是這種鏈表結構，那么，請隨便插入。
所有任務完成以后的獎勵掛在最后一任務的獎勵上。
10. 降本增效
為什么要用SSDB呢？最主要的原因是：降本增效
我就提幾點吧：
- 成本比Redis低
- 完美支持Redis常用的數據類型及操作
- 容量大，久經考驗
- 性能與Redis不相上下
- 從Redis遷移至SSDB也非常容易
文檔在這里：
https://github.com/ideawu/ssdb
具體的，看文檔吧，我就不多說了，這里直接引用了
11. 其它
曾經截了幾張接口優化過程中的截圖，一並放上來吧，留着也沒用，以后也沒有機會了
祝我們在2020年都好