有幸参与了一个项目，项目中有技术断层现象，分5年以上经验的和一年经验一下的。因此有些需求在落地时跟想象的完全不一样，不管不重构的话后期项目风险极大。

一句话描述需求：从数据源批量或者单个采集数据放在本地，然后供外部调用；如果外部调用时发现本地数据库不存在或者过期，则从数据源采集数据。数据源有很多供应商，每个数据源提供的字段不一样，同时外部通过一个接口来获取商务上确定的字段。

说下项目中出现的问题吧，项目初期很多东西都要定下来，但全部靠中高级人员定下来，然后让初级人员介入就有些不切实际了。中高级累死累活而初级人员又得不到锻炼。因此有些时候都让初级先自己实现一部分功能。

罗列一下初级人员暴露的问题吧：

1. 不同的人不同的风格，甚至自己跟自己写的都不一样；
2. 代码重复现象很严重，2个近200行代码的类只有不到5行的地方是不一样的；
3. 代码耦合现象很严重，数据采集时的采集、解析和入库居然在一个方法中；
4. 代码耦合严重，导致代码不能重用，比如单个采集和批量采集被割裂开了，同时还导致测试成本上升；
5. 类名（含pojo）命名很随意，导致反射不好处理;
6. 方法名命名五花八门，插入新逻辑变成体力活，而且AOP也不好处理。
7. 相同业务逻辑的vo类属性有重复的或者类似的，没有抽象到父类；
8. ….

介于上述问题，落实了如下整改措施：

1. 整理业务逻辑，拆分代码，抽取代码，需要对外暴露的方法定义在接口中，相同业务逻辑的代码抽取出来放在父类中；
2. 为初级人员圈定“势力范围”，针对某个具体的业务逻辑需要初级人员实现的，定义在抽象方法中并使用protected修饰，需要暴露给外部的方法用final修饰；
3. 保证开发人员能随便写的方法，不能被外面随便调用。入口方法用final修饰，把口子扎紧，不能让初级人员在子类里面重写这方法；
4. 抽取pojo或者vo类，系统参数（如分页）抽取到顶级抽象父类中，各个数据源中的通用业务参数抽取到各个抽象父类中；