如何维护老旧代码

 

我们在平时的工作中,总是会遇到老旧的系统以及老旧陈的代码。他们是业务长年累月的积累,以及因为是三、四年前的技术选型造成的系统架构的不合理以及繁琐的代码。维护这些代码总是很头疼,程序员遇到这样的代码总是一边骂娘一边憋屈的维护这,维护这些代码选择的方式并不多:

一般来说:第一种选择总是最好的,程序员最喜欢的,重构么,大家都喜欢。不过也是工作量最繁重的,它需要从上到下梳理清楚现有业务的所有逻辑,视觉稿,交互稿,文案梳理,逻辑处理,后端接口逻辑以及测试需要回归所有的case。当一个系统已经被三四个人维护过,产品经理换了四五茬,后端开发也换了三四茬,文档不健全,梳理这样的系统里的一个模块都是需要一两周的,一个系统有十来个这样的模块。。想想就是一个巨量的工作。再加上重构。。。总是会遇到各种阻力的。。。

第二种选择:修旧如旧,也会有人这么干的,“破窗户理论”嘛,这种方案不发表评论。

第三种方案,算是一种折中的选择,维护旧的系统大部分情况下是修修补补,偶尔添加一些新功能模块。 大致示例如下: 如何维护老旧代码 第1张


我就在想,能不能通过稍微优雅一点的方式来维护这些老旧代码呢?比如旧的逻辑代码我们尽量少的改动,对于新加模块我们就启用新的代码和技术选型,这样我们虽然在新旧两种代码中穿梭,不过我们大部分时间都在新的技术选型和架构里维护代码。也可以逐步的梳理熟悉流程,慢慢的把旧的逻辑迁移过来。弊端就是:需要维护两套代码,理解两套技术选型。好处就是随着新增业务模块,新的代码会越来越多,慢慢的就把旧的代码废弃了。

那么问题就来了:

新的代码如何和旧的代码解耦?

新代码我们当然是用新仓库,新选择,新打包工具。。。比如:我现在维护的一个系统是四五年前的一直正常的运行,代码选项是kissy,模块依赖也是kissy的那一套技术体系,没有通用的UI控件,打包用的简单的压缩,代码里还兼容这IE6,7,8。而实际上现在这套系统只跑在chrome上。在现在的视角看,有些东西就可以舍弃。

新的技术选型是:webpack,vue,ES6之类的,当然这些不是最主要的,最主要的是如何解耦新旧业务逻辑,如何在AB模块之间插入一个A1模块。并且这个A1模块的js不用写在旧的仓库里面,不受旧的技术选型的制约。

重点来了: 发布订阅模式(观察者模式)

观察者设计模式定义了对象间的一种一对多的依赖关系,以便一个对象的状态发生变化时,所有依赖于它的对象都得到通知并自动刷新。观察者模式-百度百科 具体操作如下: 比如我们在A模块操作之后需要A1模块来处理则只需要在A模块里触发一个自定义事件A1,然后把相关数据带过去,在A1模块里监听这个事件,做相应处理。示例代码如下:

// A模块
function A_active(){
    //balabala...做自己的事情
    $(document).trigger("A1",[data1,data2]);
}
//A1模块
 $(document).on("A1",function(data1,data2){
    //balabala,做自己的事情
 });

依次类推,你只需要在旧的代码里插入诸如

$(document).trigger("A1",[data1,data2]);

这样的代码,然后在新模块里监听对应的事件这样两个模块就解耦了。

发布-订阅模式弊端

世界上本没有什么救世主,也没有什么银弹。。。发布-订阅模式并不是万能的,这只是我解决实际项目的一点心得和记录,发布-订阅模式弊端也是有的

发布者只能发布事件,并不知道订阅者有哪些,常年月累,订阅方可能遍布系统的各个角落。
            ---你终于变成了当初最讨厌的那个人--
By 高德纳-尼古拉斯

解决这个问题:

        只能收敛发布的事件,并且尽量减少订阅方,最主要的:文档,一定要在文档里记录哪些地方有订阅这些事件,这个文档可以是注释,也可以是完整的项目文档。


本文标题:如何维护老旧代码
本文链接:https://56way.com/p/101.html
作者授权:除特别说明外,本文由 无路 原创编译并授权 小无路 刊载发布。
版权声明:本文不使用任何协议授权,您可以任何形式自由转载或使用。

已有4位网友发表了看法:

1L无眉怪人 2017-05-07 21:59:15 回复
赞一个
2L无眉怪人 2017-05-07 21:59:22 回复
赞一个
3L无眉怪人 2017-05-07 21:59:58 回复
该文章好文
4L无眉怪人 2017-05-07 22:00:02 回复
该文章好文

发表评论

必填

选填

选填

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。