前端架构应该考虑哪些？
如何搭建一个合格的前端架构能够适配我们现在快速迭代和千变万化的迭代需求呢？我认为要通过（规范制定，模块化管理，组件管理，自动化打包测试）
规范制定
如图所示 想找到孩子的玩具 是非常困难的 熊孩子都是调皮的 那怎么让这些熊孩子的玩具都能放在该放的地方呢 。最好的办法就是 不在规定地方的玩具不能玩。
对于我们的 代码也是 相应的规范可以让自己和团队程序员更加容易理解代码 梳理逻辑 也能让程序员保持良好的心情 主要规范有以下几点
1 CSS规范
戳我查看CSS规范
2 HTML规范
戳我查看HTML规范
3 JS规范
戳我查看JS规范
4 文件目录规范
5 GIT使用发布规范
戳我查看git常用命令
6 接口规范
戳我查看阿里云前后端分离之API规范
7 UI规范
8 组件数据传递规范
模块化管理
什么是模块化思想呢，简单说就是 做该做的事情 具有原子性 单一性 例如 一个台电脑 需要 CPU 需要主板 电源 组装 起来 ，模块化的意思就是 电源只做电源的事情 那就是供电 ，至于是给风扇供电 还是给CPU供电 他是不用知道的，电源只需要暴露一个 接口 参数是需要多少伏的电即可。于此同理 模块化就是 单一功能的拆分
模块化是指在解决某一个复杂问题或者一系列的杂糅问题时，依照一种分类的思维把问题进行系统性的分解以之处理。模块化是一种处理复杂系统分解为代码结构更合理，可维护性更高的可管理的模块的方式。可以想象一个巨大的系统代码，被整合优化分割成逻辑性很强的模块时，对于软件是一种何等意义的存在。
在团队开发的过程中如果不考虑模块化会遇到下列问题：
命名冲突：每个人都有自己的开发习惯，或者说开发过程中新老交替，模块复杂就会导致命名一样的情况 比如js，都是时间的意思那么就会出现下面的代码
var time = "" //界面A
var time = ""//界面B
代码重复：一个小小的时间日期格式化函数可能写了30个版本，有些可能代码完全相同，另外CSS也存在这个问题 ，不当是命名重复 还有代码重复 功能重复
所以这时候我们需要模块化开发的概念用来 提升开发效率和方便后期维护
1 JS模块化
先说说Node.js 中关于module.exports与exorts的区别
exports = module.exports = {};
exports是module.exports的一个引用require引用模块后，返回给调用者的是module.exports而不是exportsexports.xxx，相当于在导出对象上挂属性，该属性对调用模块直接可见exports =相当于给exports对象重新赋值，调用模块不能访问exports对象及其属性如果此模块是一个类，就应该直接赋值module.exports，这样调用者就是一个类构造器，可以直接new实例
假如有模块a.js代码如下：
exports.str = 'a';
exports.fn = function() {};
对a模块的调用：
var a = require('./a');
console.log(a.str);
console.log(a.fn());
这样用是对的，如果改造a如下：
exports.str = 'a';
exports = function fn() {};
在调用a模块时自然没用fn属性了。
再改造下a模块：
exports.str = 'a';
module.exports = function fn() {};
这时a模块其实就是fn函数的引用，也就是说可以require('./a')()这样使用，而同时不再有str属性了。
ES6中的模块化
首先ES6 的模块自动采用严格模式，不管你有没有在模块头部加上"use strict";。
严格模式主要有以下限制。
变量必须声明后再使用
函数的参数不能有同名属性，否则报错
不能使用with语句
不能对只读属性赋值，否则报错
不能使用前缀 0 表示八进制数，否则报错
不能删除不可删除的属性，否则报错
不能删除变量delete prop，会报错，只能删除属性delete global[prop]
eval不会在它的外层作用域引入变量
eval和arguments不能被重新赋值
arguments不会自动反映函数参数的变化
不能使用arguments.callee
不能使用arguments.caller
禁止this指向全局对象
不能使用fn.caller和fn.arguments获取函数调用的堆栈
增加了保留字（比如protected、static和interface）
ES6的模块化的特点
每一个模块只加载一次， 每一个JS只执行一次， 如果下次再去加载同目录下同文件，直接从内存中读取。 一个模块就是一个单例，或者说就是一个对象；
每一个模块内声明的变量都是局部变量， 不会污染全局作用域；
模块内部的变量或者函数可以通过export导出；
一个模块可以导入别的模块
export多对象
export let getStore = function (name) {
return JSON.parse(localStorage.getItem(name))
}
/**
* 设置本地存储书籍 统一用Object或者Array
*/
export let setStore = function (name, val = {}) {
localStorage.setItem(name, JSON.stringify(val))
}
然后import
import {a]getStore,setStore} from '../../export/util.js';
如果不想暴露变量的名称：使用as可以重命名关键字
export {getStore as A, setStore as B} from '../../export/util.js';
想要了解ES6模块化的可以点这里ES6模块化
SASS/LESS模块化
定义基础颜色，字体，间距
// Colors
$black: hsl(0, 0%, 4%) !default
$black-bis: hsl(0, 0%, 7%) !default
$black-ter: hsl(0, 0%, 14%) !default
// Typography
$family-sans-serif: BlinkMacSystemFont, -apple-system, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue", "Helvetica", "Arial", sans-serif !default
$family-monospace: monospace !default
$render-mode: optimizeLegibility !default
……
定义基础的方法 工具类
定义基础组件
………………
什么是SASS 戳这里 Sass基本介绍
组件管理
什么是组件
组件就是 最原子的DOM结构 和 这些原子组件组成的业务组件
例如 一个Button 一个， CheckBox
一个分页组件， 一个 轮播图组件
甚至是 一个订单提交组件 支付组件
我们不当要知道自己的项目中应该使用哪些组件 应该拆分哪些组件 而且要理解这些组件之间的关系 比如 UI组件 业务组件
前面我们已经制定了UI规范那么程序员在写代码的过程中 比如一个按钮我们完全可以写一些基础的按钮库让团队调用 典型的例子 bootstrap
我们来看看vuetify的按钮调用
戳我查看button
其实很多业务组件我们也是可以封装好的
例如 Vant 甚至把商品的SKU筛选做成了组件
戳我查看Sku 商品购买组件
我们在做前端架构的时候 千万别忘了把这些基础组件抽离，用以提高开发效率，方便代码维护
另附
自动化打包测试
自动化包含了 以下几点
1 打包发布自动化
2 HTML JS CSS检查自动化
3 图片压缩 静态资源压缩 自动化
4 缓存清除自动化
5 工具函数UI组件测试自动化
下面介绍4个常用的打包工具
工具 webpack
webpack 是一个现代 JavaScript 应用程序的静态模块打包器(module bundler)。当 webpack 处理应用程序时，它会递归地构建一个依赖关系图(dependency graph)，其中包含应用程序需要的每个模块，然后将所有这些模块打包成一个或多个 bundle。
工具 grunt
为何要用构建工具？
一句话：自动化。对于需要反复重复的任务，例如压缩（minification）、编译、单元测试、linting等，自动化工具可以减轻你的劳动，简化你的工作。当你在 Gruntfile 文件正确配置好了任务，任务运行器就会自动帮你或你的小组完成大部分无聊的工作。
工具glup
通过代码优于配置的策略，Gulp 让简单的任务简单，复杂的任务可管理。
利用 Node.js 流的威力，你可以快速构建项目并减少频繁的 IO 操作。
Gulp 严格的插件指南确保插件如你期望的那样简洁高质得工作。
通过最少的 API，掌握 Gulp 毫不费力，构建工作尽在掌握：如同一系列流管道。
工具poi
A zero-config bundler for the web.
相比webpack 和grunt 他更加快速 用最少的配置文件 做最多的自动化打包
小结：
前端框架可以围绕这4大块来搭建，但是里面具体的细节 还是有很多需要完善的，规范的制定每个公司都有自己的标准，大家可以取其精华，慢慢沉淀，每一个技术细节深究起来都是学无止境的。 我们要适应变革，快速提高自己的软实力。具体罗列以下几点
1 要根据项目的具体情况来定制打包工具
有些是CMS活动界面 有些是商品详情界面 还有些是一些静态说明界面，那么打包工具可以配置不同的任务去适配这些场景 ，比如发布的环境 请求接口的地址 以及打包的策略，但是每个项目都一定要配置好代理跨域和环境切换（当然大家也可以多个模板项目）
2 根据实际情况合理的拆分基础组件 和业务组件
我们不能过度的拆分 ，什么意思呢 ？ 打个比方---一篇完整的文章 需要255个汉字和30个标点符号组成 那么我们不能拆分成255个字符组件和 30个标点组件 ，这样拆分基础组件太多了，如果有些汉字只能以词组形式出现 那么我们的最小单元就可以是词组，而不是单个的汉字本身。合理的拆分 能让我们的开发效率事半功倍。过度的拆分反而会阻碍开发效率。
3 不要过度的使用不稳定的版本
在BABLE出来之前 我自己也不怎么用ES6 但是在有解决方案以后就开始大量的使用了，不能抵制新的技术 也不能再没有合理的解决方案之前 过度的使用他到生产环境中，所以我们选择前端框架的时候 最好选择稳定版本，新的技术框架可以用在小型的项目中学习和试水，等社区成熟了在开始大量使用。
4 package.json的锁定
项目依赖文件创建以后 在发布生成环境一定的时间内可以锁定所有依赖模块的版本号，如果确实有重大BUG或者需要使用新版本中的方法的时候在打开。这样团队中所有人的环境保持一致，减少由于版本不对造成的差异性或者BUG。
其实前端还需要考虑负载均衡，数据缓存，前端日志，数据统计，SEO优化，性能监控，容灾机制，自适应，流程自动化测试，版本兼容等等……革命尚未成功 大家还需努力！