新公司的一次重構升級

　　做爲菜鳥，進入一個新公司，更多的是懷着學習的態度，期待遇到一個牛逼的大神，帶領本身一路披荊斬棘，貌似這個新的環境和本身想的差距有點大~~~

　　無論環境怎麼樣，仍是從本身開始，但願不能徹底壓在別人身上。關於新公司的產品的重構，主要從技術角度說一下，儘可能剝離公司的業務。新人初來乍到，怎麼插入別人正在作的工做呢？說實話很難！因此領導給了一個和別人的工做不交叉（代碼上）模塊——任務模塊！

一、場景描述

　　公司：一個創業公司

　　技術：java以及一堆開源框架

　　產品現狀：已經經歷了1.0的大版本，這次是2.0的開發和重構。據老員工講，產品1.0時代是我現任領導和他不分晝夜，整出來的，具體多長時間不知道。說的代碼裏都是坑，慢慢的都填的差很少了，可是代碼變成一坨一坨的了！2.0的使命就是，讓已經有的看起來有條理，更合理，讓尚未的作起來更容易。

直白的說，就是把1.0中的隱含的坑，更加優質的解決掉，讓1.0裏面的代碼更加的優雅，讓不少固定死的地方，在2.0裏面活起來，更加容易擴展，更加容易修改。

二、任務模塊介紹

　　我拿到的初版需求的描述很簡單，讓用戶更活躍，讓用戶作任務，任務分爲天天不一樣的任務（之後稱爲每日任務）和長期積累完成的任務（之後稱爲長期任務），還包括用戶等級的管理，而後給我發了一個excel表格，裏面是一堆不一樣的任務。這些任務涉及到不一樣的業務中，對用戶的不一樣業務行爲進行統計處理，最後分析用戶的任務完成狀況，進行獎勵。總的時間（包括分析需求，設計，開發）是兩週。

三、需求分析

　　其實聽完需求後的腦子裏面只有倆字「懵逼」，思考了一下，腦子裏面仍是「懵逼」。理不清的主要緣由是對公司的現有業務不熟悉，不知道的結果。而後就是找個老員工，聊了聊，明白了，這個任務在1.0是個怎麼回事，要求就是在2.0也有，可是從代碼上要更優雅，更靈活。

　　研讀需求後，總結了一下幾方面的要點：

　　任務分類：

　　　　a）每日任務：不要領取任務，天天自動推送給用戶；須要用戶手動領取獎勵；完成後再也不進行獎勵（只獎勵一次）

　　　　b）長期任務：須要用戶手動領取任務，跟蹤用戶任務完成進度；任務完成後用戶手動領取獎勵；只獎勵一次

　　　　c）營銷活動：對用戶是不可見的，只有說明；跟蹤用戶行爲，完成後自動發放獎勵；不限制次數，只要完成一次，就獎勵一次

　　業務分類：

　　　　a）登陸APP

　　　　b）購物

　　　　c）加好友

　　　　d）爲好友點贊

　　　　e）發佈文章

　　　　f）爲APP提出建議，並採納

　　　　g）完善我的信息

　　獎勵分類：

　　　　獎勵的分類算是整個模塊最簡單可是很重要的地方。獎勵劃分以下：

　　　　a）應用的虛擬幣（之後稱爲金幣）能夠和人民幣有必定的兌換率的

　　　　b）優惠券在應用商城裏面的可使用的優惠券

　　　　c）標誌獎勵相似鵝廠的黃鑽紅鑽的

　　　　d) 用戶的等級獎勵

四、模塊設計

　　爲了保證代碼的靈活性，須要儘可能少的對現有代碼的侵入，就考慮到了AOP（AOP關於面向切面方面的東西就很少說了）；要保證業務的靈活性，就是在業務擴展的時候，能夠很最大程度的簡化開發流程，就須要對整個模塊總體進行抽象設計。中間的思考過程，不知道該怎麼描述，可是我覺的和我的經驗有很大關係。

　　整個模塊要作的事是結合業務和用戶的操做行爲，對用戶進行獎勵，這是目標！

　　從目標中能夠得出兩個明顯的對象：業務、獎勵。怎麼肯定業務和獎勵的關係，就是前面說的任務（每日任務和長期任務）作的事了。總體需求已經很明確了。

　　對軟件結構進行設計，整個結構我設計的是一個漏斗形狀的，最頂端是業務，最底端是獎勵。如圖：

　　圖中的業務塊是其餘人開發的，就不詳細進行描述了。主要說一下邏輯處理和獎勵用戶的流程。如圖：

　　代碼結構，經過工廠和觀察結合，完成整個模塊。簡單類圖以下：

　　對於不一樣的業務有不一樣的處理流程，不一樣業務也會產生不一樣獎勵操做。不一樣業務的處理過程的處理器是經過工廠模式，得到具體的處理器；根據業務須要爲不一樣的處理器設置不一樣的獎勵觀察對象。處理器通過不一樣的業務處理，對獎勵條件的通知獎勵觀察對象，進行獎勵操做。

五、總結

　　優勢：

　　　　a）業務處理過程，對於橫向擴展能夠知足，只對新增業務的開發便可，對現有代碼的侵入性很低

　　　　b）獎勵的橫向擴展知足必定程度的靈活性，可是會對處理器的觀察對象，具備必定的侵入性

　　缺點：

　　　　a）業務的縱向擴展靈活性不足，若是須要對某一個業務進行更深層次的挖掘，須要調整現有代碼

　　　　b）獎勵的橫向擴展示在作的不足，下一步須要擴展

　　　　c）獎勵方面的綜合判斷條件管理不合理，須要優化（考慮用職責鏈管理）

 

 

源碼：待上傳