Vue渐进式重构（一）——思路

[jmx164491960]

传送门

Vue渐进式重构（二）——规范

前言

我司当前技术栈主要分为jquery和Vue，jquery基本上都是老项目，而新项目都使用Vue。我们需要把jquery的项目重构成Vue，遇到几大难题：

1. 重构的同时，还要维护老项目的迭代，迭代任务还挺多的。比如：重构A项目需要两个月，而这两个月内A项目会有新的需求需要及时响应，我们在Vue项目上增加新功能同时也需求在旧项目里增加新功能。相当于一个新功能能要写两份代码
2. 重构和需求迭代两个任务并行，重构代码的速度追不上迭代新增需求的速度，比如当前有A，B，C三个项目，A项目重构需要两个月，等2个月重构完成之后，可能B，C项目已经增加了很多新的功能，jquery代码量比2个月前要多多了，重构的任务相当于一直被加重，每一份在老项目上增加的功能，都意味着日后重构需要多写一份。

解决方案：

第一个问题还比较好解决的：

1. 把需要重构的项目，从页面级别上做拆解，不要一次性整个项目重构。而是在原有项目上对某一个页面/弹窗重构，然后通过iframe内嵌在老项目中。一个一个页面地重构，不妨碍其他页面的需求迭代。
2. 而对第二个问题我有一个激进的想法，jquery项目需求迭代，当增加新功能的时候，在原有的代码基础上写Vue代码，即jquery + Vue一起用。

• 这听起来好像很疯狂，毕竟Vue和jquery完全是两个不同的框架，从来都是不被推崇一起用的，这两货放在一起不但功能冗余，而且显得代码混乱，估计以后接手的人看到想骂娘了。

但据具体情况具体分析，我把Vue + jquery维护老项目做了一下优缺点分析：

优点：

1. 打通jquery和vue的生态。在jquery上引入vue，就可以使用vue生态的组件库和插件，比如Element。同时在jquery项目用Vue封装新的组件，在Vue里也可以用到。
2. 采用Vue在jquery上写新功能，方便以后重构。假设A项目一半代码是jq，一半代码是Vue，那以后重构项目的时候，Vue部分的代码是可以直接迁移到新系统的，只需要重构剩下一半的jquery代码
3. 采用Vue写需求，管理页面的视图关系比jquery省事很多。大大加快开发效率

缺点：

1. 一个项目里两套框架，增加流量负担，加载慢。解决方案：做好CDN，保证部门内引用的Vue都是同一个链接，由于我部门负责的都是公司内部使用的ERP系统，所以这一条问题还不算大
2. 框架混用，代码风格不统一，使得代码难维护**（重点**）。解决方案：新的功能假如是一个新页面，即使用iframe嵌套，新页面写在Vue项目里而不写在jquery项目内。如果不是新页面，代码上做好规范，jquery和Vue做好模块化，组件化。新增的Vue代码不能和原有的Jquery代码写在一起，必须以组件形式应用。下面我将详细说明具体做法：

// newForm.js 新的功能：一个输入框

export default function(el) {
    return new Vue({
        el,
        template: `<el-input :value="value"></el-input>`,
        data() {
            value: '我是新加的功能'
        }
    })
}

// newTable.js 新的功能：一个表格

export default function(el) {
    return new Vue({
        el,
        template: `<el-table :data=""></el-table>`,
        data() {
            value: '我是新加的功能',
            data: []
        }
    })
}

// main.js jquery页面的js

import newForm from 'newForm.js'
import newTable from 'newTable.js'

// 挂载到对应节点上
const newFormEl = newForm('#newForm');
const newTableEl = newTable('#newTable');

$.ajax(
    done(res) {
        // 更新表格的数据
        newTableEl.data = // res.data;
    }
)

以上在jquery代码上使用了Vue，实现了局部的数据驱动，和组件化。虽然两框架混起来使用了，但始终遵循一个原则：jquery和Vue不混写，Vue代码始终以模块化形式提供调用。

总结

本文提供的思路我认为并不算是完美的解决方案，但一定程度上调和了重构和需求迭代的矛盾，执行得好的话我认为利大于弊。如果读者们遇到类似的问题，希望本文能给你起到参考作用。