新公司的一次重构升级

　　做为菜鸟，进入一个新公司，更多的是怀着学习的态度，期待遇到一个牛逼的大神，带领本身一路披荆斩棘，貌似这个新的环境和本身想的差距有点大~~~

　　无论环境怎么样，仍是从本身开始，但愿不能彻底压在别人身上。关于新公司的产品的重构，主要从技术角度说一下，尽可能剥离公司的业务。新人初来乍到，怎么插入别人正在作的工做呢？说实话很难！因此领导给了一个和别人的工做不交叉（代码上）模块——任务模块！

一、场景描述

　　公司：一个创业公司

　　技术：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）奖励方面的综合判断条件管理不合理，须要优化（考虑用职责链管理）

 

 

源码：待上传