翻新系统实践
基本情况
- freemark+jsp+java14的怪异组合
- 有部分内部接口采用feign
- 大部分接口采用nacos作为profile管理以及服务注册发现
- 前端部分仅使用了以jquery和easyui为主的插件，工程化程度不高
需求说明
来自于上线时候的苦恼，每次更新代码总会引发未在版本规划内的前端代码提交，且升级时间较长，失败回滚时候还有cache问题
问题分析
- 交互代码和逻辑代码均由同一个开发人员完成，此时心智负担较大，在工期较为短的时候，非常容易造成误操作，且只有上线后才能发现
- 系统经历了十年左右的开发，每个开发人员有不同的技术栈喜好，例如早期约定使用Spring Cloud的早期版本，而在五年后发现Spring Cloud很多功能又要二次开发，转向了nacos为主的国产。成员变换中不习惯，有部分接口就干脆采取域名+Nginx网关直连的形式
- 除此之外业务系统的拧巴逻辑也是翻新的重大障碍
方案选择
经过和开发小组成员讨论，建议先从增量做起，避开旧有尚能完备运行的业务，其中最简单的是需要抽出一个专门的开发人力，进行前端框架的搭建。(目前使用vue2，开发人员易于招聘)
框架需要完成以下几个事项：
- 要替换掉原来依靠服务器进行状态管理的现状，将状态管理放在前端
- 要将功能路由管理放在前端框架进行管理
- 要维护一个列表，标记哪些路由是用于直接走原来的逻辑，哪些路由是新增的有前端管理的逻辑
- 需要后端软件新增接口用以维护新旧软件的状态（一次性开发成本）
在前端框架开发完成一个月后，选取更新频率最低的应用作为试点应用，避免与正在开发的任务同时进行
当前后端代码可以剥离完毕后，在考虑后端的技术栈提纯，不应将改造任务混杂
一些结局
- 成功改造了从外包厂商回收的代码
- 在重要业务中，成功替换了进门抬杆页面的代码
- 为后续的业务不中断升级铺平道路