一个维护项目的重构改进之路

经常听到有祖传的代码一说,就是一些项目经过了很长时间的维护,经过了很多人之手,业务逻辑堆叠的越来越多,然后就变成了一个越来越难以维护。

前几个月,同事刚走,留下一个node支撑的Master/Slaver结构的分布的任务调度系统;

• 从运行部署角度看,现状是多个发布版本,而且版本依赖的node存在差异,而且部署需要手动进行一些依赖文件的拷贝;

• 从代码结构层面看,主要需要维护的版本,使用js语法编写,常常是大量的业务逻辑堆砌到了一个文件之中;

下面以Slaver为例,分析一些当前存在的问题,并且分析一些我考虑过的优化方案

首先我们看,Slaver部分包含了哪些模块和功能:

1.包含与Master之间的消息请求和响应;

2.包含了子任务的状态机;

3.包含了不同任务的处理细节;

从语法和性能角度看:

1. 比较多的以对象类型和变长参数形式作为传参;

2. 同文件中包含大量实体的定义和构造,过多的使用Object而不是定义实体对象,包含很多隐式的类型转换和冗长的元素引用;

3. 大量的使用sync形式的io操作,过多的文件操作;

4. 只有分散各处的错误打印,没有集中的错误定义;

5. 变量命名没有规则,无法区分局部和全局的,存在重复的名称使用,加重了理解的难度;

6. 变量的定义穿插分布,全局范围的函数调用穿插分散多处

7. 嵌套多层的try...catch语句

8. 持续性循环的任务设计造成服务器资源的浪费

9. 函数中多处使用绝对路径,迁移移植性差

优化方案的考虑:

1. js=>Ts,采用typescript语法重新组织代码结构;(这个方案前同事已经开发了一个版本,由于升级的调整幅度有些大,实际上线后发现还有比较多的功能问题,版本暂时搁置)

2. js=>java,采用java重新开发相关逻辑(业务代码逻辑较多,工作量较大);

3. 保留js语言不变,对原代码进行重构切分;

typescript/java相对于js都有更强的类型和更易于使用面向对象的软件设计的语法设计;

但是是不是采用js开发后端代码的就一定是个糟糕的选择呢,也不尽然,需要的更多的设计和规范坚持;

题外话,其实如果一个老系统运行的很好,也不需要在其基础上做大规模的二次开发,从投入成本角度看,我认为就没必要对这种项目进行重构了;

重构和解耦是软件开发中最长久的话题,

未完待续...

 参考文档: