前言

　　程式員輸出是他敲寫的程式碼，那麼輸入就是他思考好的設計。因此不做設計是不存在，設計只分優秀的設計和糟糕的設計。為了避免過度設計浪費成本，需要針對現有業務與問題進行展開。業務梳理是不可避免的。

　　最佳化是無止盡，為了更有成效的最佳化，必須瞭解已有的問題與需要最佳化的標的。

業務背景

 　　透過做任務獲得增值獎勵等形式，達到以下標的：

• 引導使用者完成與業務相關指定行為，進而參與業務
• 提高使用者業務黏度，減少使用者流失
• 完成日常指定任務，培養使用者APP使用習慣等

業務梳理

業務簡述

• 運營配置：由公司運營人員在運營系統對相關業務的活動進行配置。

  
• 任務串列：配置好的活動將在使用者端展示給使用者觀看，並給與【領獎】或【引導完成】的動作。

  
• 底層服務：根據已完成的業務資料源與其相關的活動配置，進行定時跑批完成任務與發放獎勵。

業務關鍵點

• 三步驟

　　參與、完成、領獎，一個使用者完成一個活動必須經歷前面三個步驟

• 十二個任務型別

　　註冊、實名、風險評測、簽到……意見反饋等等（避免過多的暴露公司業務，不一一例舉）

• 三個週期
  • 不限
  • 按日
  • 按周
  • 按月
  • 一次性
  • 日迴圈
  • 周迴圈
  • 月迴圈
  • 單次迴圈
  • 參與週期：隱藏屬性不需要配置
  • 任務週期：運營系統配置
  • 領獎週期：運營系統配置

• 7天領獎有效期

業務例子

　　為了更加好的理解，我以簽到任務舉個例子：

　　配置：簽到參與週期為每天一次，完成周期為周迴圈，領獎週期為按周，任務完成條件需要連續簽到3天。

　　場景：使用者已經在在星期日、星期一、星期二連續簽到了3天，那麼符合了完成條件，也在完成周期範圍內，因此可以完成任務並且領獎。

　　但是如果繼續簽到 星期三、四、五連續三天，雖然可以繼續參與任務，但是不可完成，因為任務週期是周迴圈。

　　再假設上面的配置只修改了完成周期為日迴圈，仍然是星期日到星期5連續簽到，在星期二的時候可以完成並且領獎一次，在星期五的時候又可完成任務，但是這個時候不能領獎，因此領獎週期按周，所以必須等到下個星期日，才能領獎。

業務流程圖

存在問題

業務過度設計

　　本業務一共有3個維度，參與、完成、領獎，其場景共有X*Y*Z的個數。原本產品的意思是想做一個靈活性比較大的配置，只要有新的活動來，可以隨意組合應對。

　　然而真實場景下，真正用到的組合併不多。

例如：

　　簽到幾乎連續一個月簽一個月才能完成與領獎。

　　綁卡雖然可以多次參與，但是我們是希望他綁了後用，而不是希望他綁了再解綁然後又要他綁卡，所以我們會設定成一次性完成周期。

　　可以看到不同型別的任務運營起來基本上是配置是固定的，很少說在通用配置裡隨意切換。

　　這麼多的組合情況也容易導致運營人員意外配置錯誤，並對於新加入參與業務的員工理解不友好。（先排除個人理解能力怎麼樣，反正我們的部分運營人員不理解怎麼用，大部分時間都需要我們技術部門協助配置）

　　我個人建議是簡化：

　　週期就一個維度，在週期內完成了就可以領獎，週期過了就重置，無論是否領獎。也不需要有效期，有效期沒有披露給使用者，對使用者來說不好接受，明明我放了幾天顯示能領的，怎麼今天一看就不能領了呢？

　　以上雖然是我個人想法，但是從產品的角度來看，既然已經做了一個“靈活性”這麼好的，那完全沒必要再花時間把他降級呀？

因此本系列只基於原業務進行討論。

任務頁面載入過慢

　　有多慢？11秒。具體問題分析與最佳化在下一篇文章《.NET-記一次架構最佳化實戰與方案-前端最佳化》討論。

程式碼冗餘

　　因為早期開發時缺少溝通，很多可以公共的方法單獨實現了一套。

時效性低

　　這個問題主要是因為早期設計的活動觸發方式由JOB定時跑導致的。

　　有些人會認為，只要把JOB的頻率調快就可以解決了，這不很簡單嗎？無論頻率快慢都會存在相應的問題。

　　以上具體兩個問題問題分析與最佳化在下一篇文章《.NET-記一次架構最佳化實戰與方案-底層服務最佳化》討論。

結尾

　　本篇花了一些時間整理了業務流程與問題點，為了更好的理解與驗證是否最適合的方案，業務整理的過程無法避免的。如果有其他的問題，可在下方評論反饋給我。