如何维护老旧代码

y1chuan 发布于2019-08-01 16:44 / 1488人阅读

摘要：我们在平时的工作中，总是会遇到老旧的系统以及老旧陈的代码。弊端就是需要维护两套代码，理解两套技术选型。那么问题就来了新的代码如何和旧的代码解耦新代码我们当然是用新仓库，新选择，新打包工具。。。

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

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

云服务器 GPU云服务器代码维护老旧网站维护html代码代码维护堡垒机怎么样

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/50714.html

如何维护老旧代码

摘要：我们在平时的工作中，总是会遇到老旧的系统以及老旧陈的代码。弊端就是需要维护两套代码，理解两套技术选型。那么问题就来了新的代码如何和旧的代码解耦新代码我们当然是用新仓库，新选择，新打包工具。。。我们在平时的工作中，总是会遇到老旧的系统以及老旧陈的代码。他们是业务长年累月的积累,以及因为是三、四年前的技术选型造成的系统架构的不合理以及繁琐的代码。维护这些代码总是很头疼，程序员遇到这样的代...

lcodecorex 2019-08-22 11:03 评论0 收藏0
【译】遗留浏览器中的表单

摘要：提到老旧浏览器，我们脑海中往往复现的就是旧版的。但幸运的是，有一些技巧可以协助解决由老旧浏览器引起的的问题。放弃表单和老旧浏览器的最大问题是对的支持。结论如你所见，处理老旧浏览器所涉及的内容不止有表单。系列文章说明原文所有的web开发者都会很快（或者很痛苦地）意识到Web是一个粗糙的环境，其中最糟糕的一点就是老旧的浏览器。提到老旧浏览器，我们脑海中往往复现的就是旧版的IE。但...

张宪坤 2019-08-20 18:10 评论0 收藏0
【译】遗留浏览器中的表单

摘要：提到老旧浏览器，我们脑海中往往复现的就是旧版的。但幸运的是，有一些技巧可以协助解决由老旧浏览器引起的的问题。放弃表单和老旧浏览器的最大问题是对的支持。结论如你所见，处理老旧浏览器所涉及的内容不止有表单。系列文章说明原文所有的web开发者都会很快（或者很痛苦地）意识到Web是一个粗糙的环境，其中最糟糕的一点就是老旧的浏览器。提到老旧浏览器，我们脑海中往往复现的就是旧版的IE。但...

Airmusic 2019-08-01 17:12 评论0 收藏0
Java程序员必读的书籍

摘要：对于专业的开发者来说，单元测试是一项必备的技能，多数的程序员却不具备测试驱动开发的能力。对于工程来说，开源项目基本都严格遵守执行单元测试，而很多商业的工程则在单元测试方面有所缺失。一个拥有单元测试的项目会变得更加容易维护和更改。　　作为一名合格的Java程序员，日常工作除了上班撸代码就是加班撸代码。撸码其实不难，无非询问Google，StackOverflow，解决方法和demo一箩...

aisuhua 2019-08-14 17:51 评论0 收藏0