在我们平时的工作中，总会遇到老系统、老代码。它们是多年业务的积累，也是三四年前的技术选型造成的系统架构代码不合理、繁琐。维护这些代码总是让人头疼。遇到这样的代码，程序员总是边维护边骂娘。维护这些代码的方法不多：1.重新发明轮子，从设计愿景到前端代码甚至后端端口接口和逻辑都是全新的。2.修旧如旧，既然这么烂，那就更烂吧，反正已经这么恶心了。..3.新逻辑启用新架构和技术选型，最大限度减少对旧代码的依赖和对旧逻辑的修改一般来说：第一个选项永远是最好的，程序员的最爱，重构嘛，大家都喜欢。但也是工作量最大的。需要对现有业务的所有逻辑进行自上而下的梳理，视觉稿、交互稿、文案、逻辑处理、后端接口逻辑和测试需要返回所有案例。一个系统维护过三四个人，产品经理换过四五次，后端开发也换过三四次，文档也不完善。在这样的系统中整理一个模块需要一两周的时间。该系统有十几个这样的模块。.想想也是一项巨大的工作量。再加上重构。..总会有各种各样的阻力。..第二个方案：恢复原状，有人会做，“破窗论”，这种方案不评论。第三种方案是折中的选择。大多数情况下，维护旧系统就是修修补补，偶尔加入一些新的功能模块。一个粗略的例子如下：我在想，这些老代码能不能用稍微优雅一点的方式来维护呢？比如，我们尽量少改动旧的逻辑代码，我们为新的模块启用新的代码和技术选型。这样一来，虽然我们穿梭于新旧代码之间，但大部分时间都花在了新技术选型和技术选型上。代码在框架中维护。也可以一步步梳理熟悉的流程，慢慢将旧的逻辑迁移过来。缺点是需要维护两套代码，了解两套技术选型。好处是随着新的业务模块的加入，新的代码会越来越多，旧的代码会逐渐被淘汰。那么问题来了：新旧代码如何解耦？对于新代码，我们当然使用新的仓库、新的选项、新的打包工具。..比如：我在维护一个四五年前一直正常运行的系统。代码选项是kissy，模块依赖也是kissy技术体系。没有通用的UI控件，采用简单的压缩方式进行打包。也兼容这个IE6,7,8。事实上，这个系统现在只能在chrome上运行。从目前的角度来看，有些东西是可以舍弃的。新技术的选择有：webpack、vue、ES6等，当然这些都不是最重要的。最重要的是如何将新旧业务逻辑解耦，如何在AB模块之间插入一个A1模块。而且这个A1模块的js不需要在老仓库写，不受老技术选型的限制。关键点来了：发布-订阅模式（observermode）观察者设计模式定义了对象之间一对多的依赖关系，这样当一个对象的状态发生变化时，所有依赖它的对象都会被通知并自动刷新。观察者模式-百度百科具体操作如下：比如我们需要A1模块在A模块运行后进行处理，我们只需要在A模块触发一个自定义事件A1，然后把相关数据带过来，并在A1模块中监听这个事件，并进行相应的处理。示例代码如下：//AmodulefunctionA_active(){//balabala...doyourownthing$(document).trigger("A1",[data1,data2]);}//A1module$(document).on("A1",function(data1,data2){//balabala，做你自己的事});等等，只需要插入如$(document).trigger("A1",[data1,data2]);这样的代码，然后在新模块中监听相应的事件，使两个模块解耦。发布-订阅模式的缺点世界上没有救世主或灵丹妙药。..发布-订阅模式不是万能的。这只是我解决实际项目的经验和记录。发布-订阅模型的缺点是有些发布者只能发布事件而不知道订阅者是谁。可能遍及整个系统。---你终于变成了当初最讨厌的人--Gardner-Nicholas解决这个问题：**只收敛发布的事件，尽量减少订阅者的数量，最重要的是：文档，必须在订阅这些事件的文档记录中。该文档可以是注释或完整的项目文档。----未完待续--https://www.noway.pub/p/101.html
