我们平时的工作中，总是会遇到老旧的系统以及老旧的代码。他们是业务经年累月的基类，以及因为是三、四年前的技术选型造成的系统架构的不合理以及繁琐的代码。维护这些代码总是很头疼，程序员遇到这样的代码总是一边骂娘一边憋屈的维护着，维护这些代码选择的方式并不多。
1.推倒重来，从设计视觉到前端代码甚至后端接口和逻辑全是新的。
2.依旧如旧，既然这么烂了我们就让他更烂吧，反正已经这么恶心了。。。
3.新的逻辑启用新的架构和技术选型，尽量减少对旧的代码的依赖和旧的逻辑的修改。
一般来说：第一种选择总是最好的,程序员最喜欢的,重构么,大家都喜欢。不过也是工作量最繁重的，他需要从上到下梳理清楚现在业务的所有逻辑，视觉稿，交互稿，文案梳理，逻辑处理，后端接口逻辑以及测试需要回归的所有case。当一个系统已经被三四个人维护过，产品经理换了四五茬，后端开发也换了三四茬，文档不健全，梳理这样的系统里的一个模块都是需要一两周的，一个系统有十来个这样的模块。。想想就是一个巨量的工作。再加上重构。。。总是会遇到各种阻力的。。。
第二种选择：修旧如旧，也会有人这么干的，“破窗户理论”嘛，这种方案不发表评论。
第三种方案，算是一种折中的选择，维护旧的系统大部分情况下是修修补补，偶尔添加一些新功能模块。
大致示例如下：
我就在想，能不能通过稍微优雅一点的方式来维护这些老旧代码呢？比如旧的逻辑代码我们尽量少的改动，对于新加模块我们就启用新的代码和技术选型，这样我们虽然在新旧两种代码中穿梭，不过我们大部分时间都在新的技术选型和架构里维护代码。也可以逐步的梳理熟悉流程，慢慢的把旧的逻辑迁移过来。弊端就是：需要维护两套代码，理解两套技术选型。好处就是随着新增业务模块，新的代码会越来越多，慢慢的就把旧的代码废弃了。
那么问题就来了：
新的代码如何和旧的代码解耦？
新代码我们当然是用新仓库，新选择，新打包工具。。。比如：我现在维护的一个系统是四五年前的一直正常的运行，代码选项是kissy，模块依赖也是kissy的那一套技术体系，没有通用的UI控件，打包用的简单的压缩，代码里还兼容这IE6,7,8。而实际上现在这套系统只跑在chrome上。在现在的视角看，有些东西就可以舍弃。
新的技术选型是：webpack，vue，ES6之类的，当然这些不是最主要的，最主要的是如何解耦新旧业务逻辑，如何在AB模块之间插入一个A1模块。并且这个A1模块的js不用写在旧的仓库里面，不受旧的技术选型的制约。
重点来了： 发布订阅模式(观察者模式)
观察者设计模式定义了对象间的一种一对多的依赖关系，以便一个对象的状态发生变化时，所有依赖于它的对象都得到通知并自动刷新。观察者模式-百度百科
具体操作如下：
比如我们在A模块操作之后需要A1模块来处理则只需要在A模块里触发一个自定义事件A1，然后把相关数据带过去，在A1模块里监听这个事件，做相应处理。示例代码如下：
依次类推，你只需要在旧的代码里插入诸如：
这样的代码，然后在新模块里监听对应的事件这样两个模块就解耦了。
发布-订阅模式弊端
世界上本没有什么救世主，也没有什么银弹。。。发布-订阅模式并不是万能的，这只是我解决实际项目的一点心得和记录，发布-订阅模式弊端也是有的。
解决这个问题：**只能收敛发布的事件，并且尽量减少订阅方，最主要的：文档，一定要在文档里记录哪些地方有订阅这些事件，这个文档可以是注释，也可以是完整的项目文档。
