野生前端架构入门

        本文假设你对Nodejs有一定的基础知识。

        先说说需求背景：我们做了一款门户小程序App，接入了很多业务模块，有业务A、业务B、业务C.....，一开始我用vue搭了一个框架，框架包含公共组件、工具方法、以及各个业务模块的代码，这样铿呲铿呲地码代码，码了十几个业务模块的时候发现不对劲了，一来编译的速度越来越慢了，打包也越来越慢，首屏加载也越来越慢了，十多个业务模块的代码加起来能不慢嘛；二来如果业务A在调整代码，但是业务C需要发版的时候，要么还原业务A的代码，要么等待业务A完成开发后一起发版。为了解决这些问题，于是就打算捣鼓个前端架构吧。

        做之前先确定这个架构需要做什么以达到优化的目的。我当时有三种方案：一是打包某一个业务模块的时候把其他业务模块的代码的路由引用给去掉，只打包公共组件部分及需要发版的业务模块；二则是搭建多页应用的形式，各业务模块形成自己的单页应用；三是有一个代码模板，包含了工程的基础公共组件，需要迭代新的业务模块的时候，把这个工程copy下来，再往里面添加业务代码就是了，发版也可以单独发。

        方案一和方案二会有个共同的缺点，就是同一个工程包含多个业务模块的代码，组员开发的时候往往是不需要看到或者改动其他业务模块的应用的，不能够给他们过高的项目权限，避免改错代码；方案二多页应用虽然有助于优化首屏加载，但是其多个业务模块耦合，未解决协同发版的问题，当时其实还考虑到会有第三方厂商需要按照我们的开发规范，把他们的业务应用接入到我们的小程序App的，最后选择了方案三的形式。

        怎么做？

        这里需要给大家介绍一下vue-cli，vue-cli大家用的多了，大家都是通过vue-cli去构建自己的vue应用的嘛，执行vue init webpack就可以创建一个vue工程出来了，但是面试了这么多人我还真没见过几个人能告诉我vue-cli执行这个命令究竟干了啥的（可能是我们公司太拉了，大牛不愿意来）。

        [email protected]执行init命令的时候实际上是通过nodeJs把github上的一个叫webpack的模板工程下载到临时目录，再通过metalsmith转换一下这个模板工程为vue语法的工程，这样就得到了一个可运行的webpack工程了。那改一下脚手架里模板工程代码的地址指向，再改一下这个工程模板的代码不就行了嘛！

        实现这个方案需要用到的材料包括：

        1、npm私服，用于发布改造的vue-cli脚手架，如果这个东西不敏感的话，你甚至可以发布到npm公服；

        2、gitlab私服，用于上传你的包含公共组件代码的工程，如果你这个工程不敏感的话，甚至可以用发布到github公服。

        理清楚关系了就铿呲铿呲跟老板提交架构方案，老板同意后就搭了gitlab和npm私服，虽然我一笔带过，但是过程的艰辛你们可能得自己感受。

        遇到什么问题？

        我把我的脚手架命名为kvue，发布到私服后，npm install了我自己的脚手架，执行kvue init h5app生成了一个工程，h5app就是我的模板工程，确认了里面的代码都包含了我的公共组件和工具方法，剩下要做的就是把旧工程的业务模块和路由迁移到新工程里面，于是我一口气初始化了十几个工程，把这些各个业务模块迁到各个工程去（这口气怎么也得十天半个月）。

         有了这个架构确实解决了这些问题：

                1、业务解藕及协同开发；

                2、代码权限控制；

                3、厂商接入不会影响到我们的业务开发；

                4、代码打包编译优化；

         同时也带来了新的问题：

                1、公共组件有bug需要更新怎么办？

                2、新增了新的公共组件项目要用怎么办？

                3、多个项目需要发版怎么办？

                4、模板工程新增公共组件后，有新的依赖安装到package.json怎么办？

        针对问题二、问题四，我在脚手架增加了update程序，原理是在模板工程的目录增加了一个update.js的文件，update.js中定义了项目的哪些文件夹会被更新，项目的哪些文件会被融合，开发人员在工程目录下执行kvue update的时候，读取update.js的配置进行相应的脚本操作，通过覆盖文件的形式解决问题一和问题二，通过代码融合的方式解决问题四，当然组件的版本出现冲突时优先以公共组件所用的版本为准。

        针对问题一，可以把这些工程放在同一个目录下，执行kvue update all，完成所有工程的公共组件更新。

模板工程配置：

template文件夹存放的工程配置：

 update.js配置：

        针对问题三，可以把这些工程放在同一个目录下，在kvue脚手架中增加deploy程序，通过执行kvue deploy moduleA moduleB批量完成自动化部署，因为工程的结构是一样的。

        新的问题？

        解决了上面四个问题了，是不是就没问题了呢？后来还是会有组员不小心修改了公共组件的代码，导致其执行kvue update之后代码被模板代码覆盖了，可以看到我们上面的模板工程目录是比较散乱的，因为模板文件和开发目录混在一起了，其实把模板文件放到一起，约定开发的文件只能放到src目录下即可，并且在update程序中增加backup程序，在更新项目代码之前先备份一下代码。

        现状

        经过两年的产品迭代，我们的小程序App扩展到了三十多个模块，价值也算小千万了，终究还是这套架构承担了所有，没点规模都不敢这么搞，虽然到现在还没有厂商接入我们的App...

        扩展

        当然是不是只有H5工程可以这么搞呢？当然不是，对于同一业务类型的应用群，你甚至可以搭建uni-app工程模板、微信小程序工程模板，nodejs服务工程模板，免去重复搭建工程的烦扰，当然java工程模板就不用各位操心了，因为java有类似的工具...

        写这篇文的时候vue cli已经发布到@5.0.1了，真是白云苍狗啊，不过看了最新的代码其实从思想上来说变化不大，但是代码量来说增加了很多预设插件的处理代码，从vue.js调到create.js再到Creator.js再到Generator.js，核心思想还是那些，增加了很多配置项和通过ui创建工程之类的花里胡哨的东西，我试了预设模板工程填gitlab私服的地址，报了错，看来并不适用于创建小程序模板工程，还是有一定的局限性，如果你想改造最新的@vue/cli工具来做架构的话可能不太合适，毕竟有点臃肿了。

        注意事项

        在你建设自己的架构的同时，脚手架的使用说明和相关公共组件文档、使用demo是必不可少的，请确保你们的成本cover得住或者你有足够的精力支撑你去完成这些在老板看来“不挣钱”的工作。