前言
功能業務實作，在小程式電商類應用上，新增邀請碼活動子產品，目的是提高使用者量與訂單量，更多的效用就是營運上的點了。那麼我接到功能時其實是很模糊的，上頭說來一個别人做出的那種邀請碼的子產品，我第一步想到的是背景一鍵開關？通過背景子產品的啟動、設定、關閉活動，這樣，這個子產品在接下來依舊可以繼續使用，而且活動時間與優惠券有效時間定制，有利于營運人員的活動策劃。
具體項目：請看【報告！7至8月中旬項目總結！】推文
業務分析
沒有原型我也很無奈呀，與UI的商量是出來了幾張效果圖，不過核心的流程與邏輯還是沒有文檔或原型說明，那我隻能自己動手啦！（手動摸胡子表情）
大緻畫了出來，一鍵式開關控制邀請碼活動（旺季開啟活動），邀請碼定制，背景會生成随機6位邀請碼，使用者也可以自己定制（這個點是營運上的政策），生成邀請碼後，可以在小程式内部分享給朋友（未注冊或注冊使用者），使用者填寫對應邀請碼後得到優惠券，當然發出邀請碼的人在這個使用者下單時，才能得到傭金，接下來說說，實作思路。
資料庫設計
新增兩個表，個人設計習慣問題，可能不是很符合規範，大家見諒，或者提一些建議。
Activites表是活動的主表，id預設自增即可，每一個資料代表每一次活動，status（開啟狀态 0-已結束、1-活動開啟中、2-未到開啟時間）、perger_time（本期活動優惠券有效時間）、startTime（開啟時間）、endTime（結束時間）；
Activites_master表是使用者活動資訊表，id依舊自增，act_id是對應哪個活動（Activites的Id）、user_id（使用者Id）、my_pass（本次活動使用者的邀請碼）、pass（本次活動使用者填寫的邀請碼）、person（本次活動邀請人數）、money（本次活動傭金）、perfer（本次活動優惠券 0：無、1：有）、cut_off_time（本次活動優惠券截止日期）
由于優惠券不是和活動時間一起失效，是以在Activites表的活動建立時設定了本期活動所有的優惠券有效時長，而cut_off_time是這個使用者得到優惠券有加上有效時長的優惠券截止日期。
技術突破
1、我們有這樣的業務需要，使用者分享給其他使用者時，其他使用者打開連接配接後是填寫邀請碼的界面，需要自動将發出邀請人的邀請碼填充進去，這個涉及前端開發，不過我也找了一下實作，好在小程式官方API有提到了，就像是在二維碼中多加參數一樣。擷取更多轉發資訊
2、傭金提現，老實說，我真的隻做過支付寶、微信支付的充值提現而已，由主體是小程式是以不能用公衆号的紅包接口，參數是對不上的，是以要啃一啃微信支付的另一個接口：企業付款到零錢。
3、餘下的就是一些業務代碼，下單優惠券抵消、邀請碼校驗等等（主要是1、2點）
API開發
0、省去背景操作，類似活動新增，開啟、關閉、查詢使用者清單資訊等。
1、頁面校驗 /api/v1/activites/check GET
進入子產品、使用者通路分享連結時，校驗目前是否輸入活動時間範圍
2、擷取邀請頁面資訊 /api/v1/activites/get_pass GET
擷取使用者的邀請活動資訊、自身邀請碼、邀請人數、傭金等
3、修改定制使用者邀請碼 /api/v1/activites/change_pass POST
使用者修改自身的邀請碼
4、填寫邀請碼 /api/v1/activites/pass POST
填寫他人邀請碼，擷取優惠券
5、擷取優惠券資訊 /api/v1/activites/perfer GET
擷取使用者優惠券資訊清單
6、提現接口、下單使用優惠券等等（這裡就不一一列舉了）
總結
大體上算了将思路走了一遍，還有腦補了具體實作，代碼實操部分已經完成85%左右，後期需要測試與測試服模拟提現功能等，小弟還有很多不足，希望朋友給些建議，将不斷完善并提升自身的業務了解能力與功能實作設計能力。