一、项目背景和重构背景
背景：原项目的主要包含一个近2000行的service。
公司最近变动较大，前段时间，一个同事离职了，交接给我们一个司机排序相关的项目。输入是：订单和司机列表。服务根据订单的特定状态，采取多个不同的策略对这批司机进行组合排序。
其实在数个月前，我尝试过对这个项目进行重构，当时不懂业务，挣扎了一周左右，代码看的头晕，一个参数从入口一直用到了出口，有的参数在半道上产生，跨越了几百行代码之后被使用了。单测无法写，先抽离了一部分工具类，但是感觉对整个类改善不大，最终放弃了。
大概两周前，领导发话，要重构这个服务，还组织了几次评审。目标明确：就是要重构，集成到另一个服务里面，把原服务下掉。
二、重构设计
我虽然工作了这么多年，大大小小的项目也经历过，但是完全重构一个项目的事情没有做太多。设计模式挨个看了一遍，感觉用不上。最后重构时对自己的要求就是：封装变化。
我根据之前的几次评审，画了大致的流程图，写了大体的思路，进行了组内评审，没发现什么大问题。
大致流程如下：
1、分流
分流内部需要开发人员自己修改，这块主要逻辑是：根据订单特定参数选取特定的算法。
算法：包括多个策略，以及各个策略的打分权重。
策略：最小执行单元。需实现指定的策略接口，如果需要其他策略的数据，可以通过“session”进行交互。
关于“session”：看了ThreadLocal的实现，感觉弱引用可能存在线程执行过程中数据被GC清理的情况，于是自己实现了一个类ThreadLocal。后来又看了大量文章，发现是自己对GC理解的不够深刻。
2、算法执行
根据分流获取到的算法，按约定顺序执行包含的各个策略，并更新最终得分。
3、结果判定
封装返回结果
按照以上流程，开发人员添加算法时，需要：1、开发自己的策略，2、然后手动封装一个算法集，3、在分流阶段增加自己的判定分支
整个流程框架写完之后，由另一个对业务很熟的同事W开发了策略、算法、结果判定。项目完成之后，同事W进行了一次串讲。
三、发现问题
串讲的时候，我才发现，对于结果判定这块没有太多设计，之前设计时觉得这块是固定流程。
听流程发现，有的策略依赖之前所有的策略的总结果。按照当前的设计，只有所有策略执行结束时才会进行结果汇总。
因为同事W工程能力很强，直接修改了“结果判定”这块的流程，也正是因为此处，我才发现这个问题（相当于框架被改了）。。
后期改进：让策略在执行中能够获取到结果汇总。“结果判定”应该让算法开发人员自己来判定。
四、项目总结
对于这次的重构， 整体结果是可以接受的。开发一周半，测试不到两周，重构了一个累计开发了两年的项目来说，个人感觉是很好了。
个人经历：
封装变化，是为了把变化的权限掌握在自己手里。需要时可以从大局整体改变项目结构，而不影响太多框架的使用者。
个人觉得：
一个项目，开发者关注的代码越少，涉及改动的类越少，越不容易出错。该强制的就强制，编码不能太自由（约定优于配置）
五、总结
1、在不够了解业务的前提进行重构，进行架构设计，风险较高。
2、在设计开始之前，应该充分讨论业务场景。（幸好这次重构漏掉的不多）
3、新项目完成之后，进行流程串讲是有必要的。