作為菜鳥，進入一個新公司，更多的是懷着學習的態度，期待遇到一個牛逼的大神，帶領自己一路披荊斬棘，貌似這個新的環境和自己想的差距有點大~~~
不管環境怎么樣，還是從自己開始，希望不能完全壓在別人身上。關於新公司的產品的重構，主要從技術角度說一下，盡量剝離公司的業務。新人初來乍到，怎么插入別人正在做的工作呢？說實話很難！所以領導給了一個和別人的工作不交叉（代碼上）模塊——任務模塊！
1、場景描述
公司：一個創業公司
技術：java以及一堆開源框架
產品現狀：已經經歷了1.0的大版本，此次是2.0的開發和重構。據老員工講，產品1.0時代是我現任領導和他不分晝夜，整出來的，具體多長時間不知道。說的代碼里都是坑，慢慢的都填的差不多了，但是代碼變成一坨一坨的了！2.0的使命就是，讓已經有的看起來有條理，更合理，讓還沒有的做起來更容易。
直白的說，就是把1.0中的隱含的坑，更加優質的解決掉，讓1.0里面的代碼更加的優雅，讓很多固定死的地方，在2.0里面活起來，更加容易擴展，更加容易修改。
2、任務模塊介紹
我拿到的第一版需求的描述很簡單，讓用戶更活躍，讓用戶做任務，任務分為每天不同的任務（以后稱為每日任務）和長期積累完成的任務（以后稱為長期任務），還包括用戶等級的管理，然后給我發了一個excel表格，里面是一堆不同的任務。這些任務涉及到不同的業務中，對用戶的不同業務行為進行統計處理，最后分析用戶的任務完成情況，進行獎勵。總的時間（包括分析需求，設計，開發）是兩周。
3、需求分析
其實聽完需求后的腦子里面只有倆字“懵逼”，思考了一下，腦子里面還是“懵逼”。理不清的主要原因是對公司的現有業務不熟悉，不知道的結果。然后就是找個老員工，聊了聊，明白了，這個任務在1.0是個怎么回事，要求就是在2.0也有，但是從代碼上要更優雅，更靈活。
研讀需求后，總結了一下幾方面的要點：
任務分類：
a）每日任務：不要領取任務，每天自動推送給用戶；需要用戶手動領取獎勵；完成后不再進行獎勵（只獎勵一次）
b）長期任務：需要用戶手動領取任務，跟蹤用戶任務完成進度；任務完成后用戶手動領取獎勵；只獎勵一次
c）營銷活動：對用戶是不可見的，只有說明；跟蹤用戶行為，完成后自動發放獎勵；不限制次數，只要完成一次，就獎勵一次
業務分類：
a）登錄APP
b）購物
c）加好友
d）為好友點贊
e）發布文章
f）為APP提出建議，並采納
g）完善個人信息
獎勵分類：
獎勵的分類算是整個模塊最簡單但是很重要的地方。獎勵划分如下：
a）應用的虛擬幣（以后稱為金幣）可以和人民幣有一定的兌換率的
b）優惠券在應用商城里面的可以使用的優惠券
c）標志獎勵類似鵝廠的黃鑽紅鑽的
d) 用戶的等級獎勵
4、模塊設計
為了保證代碼的靈活性，需要盡量少的對現有代碼的侵入，就考慮到了AOP（AOP關於面向切面方面的東西就不多說了）；要保證業務的靈活性，就是在業務擴展的時候，可以很最大程度的簡化開發流程，就需要對整個模塊整體進行抽象設計。中間的思考過程，不知道該怎么描述，但是我覺的和個人經驗有很大關系。
整個模塊要做的事是結合業務和用戶的操作行為，對用戶進行獎勵，這是目標！
從目標中可以得出兩個明顯的對象：業務、獎勵。怎么確定業務和獎勵的關系，就是前面說的任務（每日任務和長期任務）做的事了。整體需求已經很明確了。
對軟件結構進行設計，整個結構我設計的是一個漏斗形狀的，最頂端是業務，最底端是獎勵。如圖：
圖中的業務塊是其他人開發的，就不詳細進行描述了。主要說一下邏輯處理和獎勵用戶的流程。如圖：
代碼結構，通過工廠和觀察結合，完成整個模塊。簡單類圖如下：
對於不同的業務有不同的處理流程，不同業務也會產生不同獎勵操作。不同業務的處理過程的處理器是通過工廠模式，獲得具體的處理器；根據業務需要為不同的處理器設置不同的獎勵觀察對象。處理器經過不同的業務處理，對獎勵條件的通知獎勵觀察對象，進行獎勵操作。
5、總結
優點：
a）業務處理過程，對於橫向擴展可以滿足，只對新增業務的開發即可，對現有代碼的侵入性很低
b）獎勵的橫向擴展滿足一定程度的靈活性，但是會對處理器的觀察對象，具有一定的侵入性
缺點：
a）業務的縱向擴展靈活性不足，如果需要對某一個業務進行更深層次的挖掘，需要調整現有代碼
b）獎勵的橫向擴展現在做的不足，下一步需要擴展
c）獎勵方面的綜合判斷條件管理不合理，需要優化（考慮用職責鏈管理）
源碼：待上傳