前言
程序員輸出是他敲寫的代碼，那麼輸入就是他思考好的設計。因此不做設計是不存在，設計只分優秀的設計和糟糕的設計。爲了避免過度設計浪費成本，需要針對現有業務與問題進行展開。業務梳理是不可避免的。
優化是無止盡，爲了更有成效的優化，必須瞭解已有的問題與需要優化的目標。
業務背景
通過做任務獲得增值獎勵等形式，達到以下目標：
- 引導用戶完成與業務相關指定行爲，進而參與業務
- 提高用戶業務黏度，減少用戶流失
- 完成日常指定任務，培養用戶APP使用習慣等
業務梳理
業務簡述
- 運營配置：由公司運營人員在運營系統對相關業務的活動進行配置。
![]()
-
- 任務列表：配置好的活動將在用戶端展示給用戶觀看，並給與【領獎】或【引導完成】的動作。
![]()
-
- 底層服務：根據已完成的業務數據源與其相關的活動配置，進行定時跑批完成任務與發放獎勵。
業務關鍵點
- 三步驟
參與、完成、領獎，一個用戶完成一個活動必須經歷前面三個步驟
- 十二個任務類型
註冊、實名、風險評測、簽到……意見反饋等等（避免過多的暴露公司業務，不一一例舉）
- 三個週期
- 參與週期：隱藏屬性不需要配置
- 任務週期：運營系統配置
- 一次性
- 日循環
- 周循環
- 月循環
- 單次循環
- 領獎週期：運營系統配置
- 不限
- 按日
- 按周
- 按月
-
7天領獎有效期
業務例子
爲了更加好的理解，我以簽到任務舉個例子：
配置：簽到參與週期爲每天一次，完成周期爲周循環，領獎週期爲按周，任務完成條件需要連續簽到3天。
場景：用戶已經在在星期日、星期一、星期二連續簽到了3天，那麼符合了完成條件，也在完成周期範圍內，因此可以完成任務並且領獎。
但是如果繼續簽到 星期三、四、五連續三天，雖然可以繼續參與任務，但是不可完成，因爲任務週期是周循環。
再假設上面的配置只修改了完成周期爲日循環，仍然是星期日到星期5連續簽到，在星期二的時候可以完成並且領獎一次，在星期五的時候又可完成任務，但是這個時候不能領獎，因此領獎週期按周，所以必須等到下個星期日，才能領獎。
業務流程圖
存在問題
業務過度設計
本業務一共有3個維度，參與、完成、領獎，其場景共有X*Y*Z的個數。原本產品的意思是想做一個靈活性比較大的配置，只要有新的活動來，可以隨意組合應對。
然而真實場景下，真正用到的組合並不多。
例如：
簽到幾乎連續一個月籤一個月才能完成與領獎。
綁卡雖然可以多次參與，但是我們是希望他綁了後用，而不是希望他綁了再解綁然後又要他綁卡，所以我們會設置成一次性完成周期。
可以看到不同類型的任務運營起來基本上是配置是固定的，很少說在通用配置裏隨意切換。
這麼多的組合情況也容易導致運營人員意外配置錯誤，並對於新加入參與業務的員工理解不友好。（先排除個人理解能力怎麼樣，反正我們的部分運營人員不理解怎麼用，大部分時間都需要我們技術部門協助配置）
我個人建議是簡化：
週期就一個維度，在週期內完成了就可以領獎，週期過了就重置，無論是否領獎。也不需要有效期，有效期沒有披露給用戶，對用戶來說不好接受，明明我放了幾天顯示能領的，怎麼今天一看就不能領了呢？
以上雖然是我個人想法，但是從產品的角度來看，既然已經做了一個“靈活性”這麼好的，那完全沒必要再花時間把他降級呀？
因此本系列只基於原業務進行討論。
任務頁面加載過慢
有多慢？11秒。具體問題分析與優化在下一篇文章《.NET-架構優化實戰-前端優化》討論。
代碼冗餘
因爲早期開發時缺少溝通，很多可以公共的方法單獨實現了一套。
具體問題分析與優化在下一篇文章《.NET-架構優化實戰-底層服務優化1》討論。
時效性低
這個問題主要是因爲早期設計的活動觸發方式由JOB定時跑導致的。
有些人會認爲，只要把JOB的頻率調快就可以解決了，這不很簡單嗎？無論頻率快慢都會存在相應的問題。
具體問題分析與解決方案將在《.NET-架構優化實戰-底層服務優化2》進行詳細的描述。
結尾
本篇花了一些時間整理了業務流程與問題點，爲了更好的理解與驗證是否最適合的方案，業務整理的過程無法避免的。如果有其他的問題，可在下方評論反饋給我。