如何维护老旧代码

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

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

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

• 3.新的逻辑启用新的架构和技术选型，尽量减少对旧的代码的依赖和旧的逻辑的修改

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

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

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

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

那么问题就来了：

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

新代码我们当然是用新仓库，新选择，新打包工具。。。比如：我现在维护的一个系统是四五年前的一直正常的运行，代码选项是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://www.noway.pub/p/101.html