如何维护老旧代码

咱们在平时的工做中,老是会遇到老旧的系统以及老旧陈的代码。他们是业务终年累月的积累,以及由于是3、四年前的技术选型形成的系统架构的不合理以及繁琐的代码。维护这些代码老是很头疼,程序员遇到这样的代码老是一边骂娘一边憋屈的维护这,维护这些代码选择的方式并很少:javascript

  • 1.推倒重来,从设计视觉到前端代码甚至后端接口和逻辑全是新的。html

  • 2.修旧如旧,既然这么烂了咱们就让他更烂吧,反正已经这么恶心了。。。前端

  • 3.新的逻辑启用新的架构和技术选型,尽可能减小对旧的代码的依赖和旧的逻辑的修改vue

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

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

第三种方案,算是一种折中的选择,维护旧的系统大部分状况下是修修补补,偶尔添加一些新功能模块。
大体示例以下:

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

那么问题就来了:web

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

新代码咱们固然是用新仓库,新选择,新打包工具。。。好比:我如今维护的一个系统是四五年前的一直正常的运行,代码选项是kissy,模块依赖也是kissy的那一套技术体系,没有通用的UI控件,打包用的简单的压缩,代码里还兼容这IE6,7,8。而实际上如今这套系统只跑在chrome上。在如今的视角看,有些东西就能够舍弃。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://www.noway.pub/p/101.html

相关文章
相关标签/搜索