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

　　不管环境怎么样，还是从自己开始，希望不能完全压在别人身上。关于新公司的产品的重构，主要从技术角度说一下，尽量剥离公司的业务。新人初来乍到，怎么插入别人正在做的工作呢？说实话很难！所以领导给了一个和别人的工作不交叉（代码上）模块——任务模块！

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

源码：待上传