背景
在前段时间做了L10的某个超复杂超多坑的三端专题之后，组里的小伙伴们一致认为是时候想办法统一一下组里的开发模式了。因为用nie那一套jQuery/zepto(下文jQuery默认包括zepto)的话，十个人就有十种习惯，不管是代码组织也好，页面结构也好，逻辑处理也好……
其实如果像一般的专题，开发周期短，生命周期短的，用传统的方式开发也还好，不需要后期维护，不需要多人协作。但是，如果项目稍微复杂一点，问题就来了，一碰到需要多人协作的项目，不同的人都有不同的组织代码的习惯，维护起来效率相当低下。所以，我们决定是时候在稍微复杂一点的项目中用一些特定的技术，这样就能通过某些约定好的方式来开发一个项目，尽量降低协作开发和维护的成本。
由于在这之前，我也用过一些mv*的技术去开发一些需要长期维护的项目，例如react、vue。考虑到相比较而言vue的易上手性，我和组内的同事决定用vue的那一套技术，vue用于视图层，vue-router用于单页应用的路由，vuex我觉得可以暂时不用考虑，因为我们现在做的项目多数为不需要长期维护的专题类网站，数据结构也不会复杂到需要用到数据流工具的程度，管理数据可以根据vuex的思想实现一个非常简单的简化版vuex。
Vue V.S. jQuery
讲道理把Vue和jQuery摆在一起比较是不太合适的，一个是mv*架构中的view层的一个库，一个是跟DOM操作结合比较紧密的js库，干的事情不同，也就不存在直接的对立关系。社区里很多人比较这两种技术可能是出于vue所提倡的数据驱动视图和jQuery的直接操作DOM在编写页面时的思路完全不同的考虑。虽然两种思路是完全不同的，但也不能说是不能一起用的，在某些没有办法的情况下(稍后会说到)，把jQuery和vue用在一块是完全没问题的，只是说在项目中没有了纯粹的数据驱动视图了而已。
当然把这两种技术用在一起是肯定不会出现在最佳实践里的，因为确实没有特殊情况的话，这样用就是有点自找麻烦了。尴尬的是，上面提到的没有办法的情况出现了，我们部门的组件库里的组件全部是基于jQuery的，其中有纯UI组件和跟业务有强关联的UI组件。其中，纯UI组件很好办，自己用vue写一个或者在vue社区里找一个代替就行(尤其是现在vue的社区资源正在蓬勃发展，有很多已经非常成熟的持续维护的vue组件库)，但是跟业务有关的组件就没办法了，这就是为什么会把vue和jQuery一起用的原因。
好在jQuery和vue只是在编程思路上有所不同，两个技术的应用场景并不冲突，只是在开发过程中需要多注意一下，在数据驱动视图的代码中，还混入了一些直接操作DOM的代码。
代码组织构建工具
在说代码组织之前，还得先说说构建工具，毕竟构建跟代码的组织方式息息相关。
你都用vue了，构建工具有啥好说的，不用webpack还有其他更好的？
没错，用vue开发项目，webpack绝对是首选，各种loader帮助你简化你的代码，还有其他各种分开打包的方案、js懒加载等帮助你优化页面的加载速度。
但是，第二个尴尬的情况又出现了，部门内部的所有项目都是基于fis3构建的，也就意味着所有测试机器和正式及其上都是fis3的这套构建系统，你在本地用webpack打包是没法发布的。
考虑到迁移成本，部门短期内是不可能从fis3迁移到webpack了，这也是没办法的事情。因此，要想舒服地使用vue就得想其他办法。如果仔细看过文档的话，其实vue是可以直接引入js文件来进行非构建开发的，需要做的事情就是引入vue的js文件然后用Vue对象初始化应用就行了，非常简单。但是如果没有构建过程的话，就意味着我们在写vue组件的时候需要写难读的字符串模板或者更难读的render函数，而没法写像用webpack时的单文件组件。
这个显然是不能忍的。写过或者读过webpack的loader的同学应该都清楚，loader其实就是一个处理字符串的函数，并不是啥黑科技，之所以webpack加了vue-loader之后能使用单文件组件，是因为vue-loader会将输入的.vue文件当成字符串，然后根据,