1. 电商前端架构设计
什么是前端架构
说到架构，很容易拉出一系列的概念知识点，像系统架构、软件架构、框架等等，这些不是今天探讨的重点，大家可以下去网络来理解。架构的本质是什么？其实也是一种管理。通常我们所说的管理，都是指对于任务和人员的管理，而架构管的是机器和代码。比如说，机器的部署属于运维的物理架构，SOA属于服务架构，那么，前端的架构指什么呢？
长期以来，前端所处的位置是比较偏应用层，很薄的一层，而架构又要求深度和广度，所以之前在前端里面做架构，好比在小水塘里游泳，稍微扑腾两下就到处碰壁。但最近这几年来，随着一些列新的技术和概念的出现，前端的范围被大大拓展了，所以这一层逐渐变得大有可为。
单纯从语言的角度来说，html、js、css是最简单最容易上手的开发语言，不考虑模块化、工具、压缩优化，任何人都可以快速上手，完成一两个功能简单的页面。在规模很小的项目中，前端技术要素彼此不会直接产生影响，因此无需架构相关的思考。由于前端语言这种灵活松散的特点，使得前端项目规模在达到一定规模后，工程问题凸显，成为发展瓶颈，原来孤立的技术要素开始彼此产生影响，各种技术要素彼此之间开始出现关联，要用模块化开发，就必须对应某个模块化框架，用这个框架就必须对应某个构建工具，要用这个工具，就必须对应某个包管理工具……这个时候，需要有人从比较高的角度去梳理、寻找适合自己团队的集成解决方案。而这一系列解决问题的工具和手段就是所谓的前端架构。
架构不等于框架这一点很好理解，相信大家都能够很深入的说明这里的差别，框架是架构的重要组成部分，架构决定框架的选型，框架决定架构的技术路线。架构围绕框架进行一系列的流程工具建设，从而形成完善自动的开发体系。
+框架不等于类库，这里就是很多人困惑的点，你用的什么框架？jquery、underscore、linq、seajs、requirejs等等，每个人都能够列举一大堆。但这个是不准确的，一套编码框架是有一系列的元素组成：开发模式，我们如何来实现代码的职责分离。以前整个前端是mvc中v这一层，而现在前端内部也进行了mvc的逻辑细分，Javascript的MVC框架现在很多，有的强化m、有的强化c。每一个框架其实都有其特点的，并且有越来越多的创新改造，比如现在最流行的是mvvm。有angular、react等等。我们是为了引入mvvc才把他们纳入到我们的开发体系，而不是因为他是一个好用的类库。
通讯，模块化、组件化是前端在推进开发模式过程中的一个过程产物，为了有效的进行组件隔离和独立，现在有各种各样的通信模型出来，不过由于实现简单，代码少，他往往是合入到某个类库里面，但本质也是一个类库。比较成熟的比如：消息总线、事件模拟、缓存中转、flux模型等等。
模板，我们用什么样的方式来集中的处理数据往html的转换过程，这里就不用多展开，这种类库现在太多了，光我们公司就有很多套，大家在代码行、缓存管理、预编译、运算性能、强大的语法等等各个维度不段追求各种极致。
基础类库最后才是传统类库，相信现在已经没有同学会在项目中去约束团队中的dom操作、常用函数、方法、异步化等等各种很基础东西，这个时候我们一般就是引入jq、zepto、underscor这些封装好的东西就行了。核心就是为了改善编码生产力。
对于框架的选型要从两面看，一是看该框架的本领，二是看你们团队的能耐。从经验上给几个点建议：
这里也可以顺便展开聊一下现在前端产品的形态分类：
从这些分类里面，我们这些年派生出了所谓全端和全栈的概念。但本质上怎么走还是要由所在产品的形态来决定。
内容型Web站点 侧重渲染方面的优化，前端逻辑比重小
操作型B/S系统 以数据和逻辑为中心，界面较规整
hybrid内置型，要处理缓存和一些本地接口，包括PC客户端和移动端。现在的本地应用，基于很多考虑，都变成了混合应用，也就是说，开发这个应用的技术，既包含原生的代码，也包含了嵌入的HTML5代码
Web游戏，前端的逻辑非常重，在代码结构上要求非常高的可管理性和更复杂的设计模式。
桌面应用型，现在有一些PC端的混合应用开发技术，比如node-webkit和hex，前者的典型应用是XDK，后者的典型应用是有道词典，此外，豌豆荚的PC客户端也是采用类似技术的，也有一些产品是用的qt-webkit。这类技术可以方便做跨平台，极大减少开发工作量。
大工程应该尽量避开谷歌产品，他的很多技术开源项目都是玩票性质的，GWT、Closure、Darty就是前车之鉴。曾今提出过很多的新技术，到现在还是独家的，变出太大。包括现在angular，喜欢做断崖式升级，做做运营后台系统问题不大，如果是线上系统的话，每次升级就是一次人月神话中的典型焦油坑。
关注应用场景，像刚才说到的boss后台是一种；另外我的平台是否有沉重的历史包袱，需要兼容ie6，还是可以轻装上阵；产品对于seo是什么样的态度？是否需要考虑自适应？或者我的团队足够大，能够各搞一套？；产品特征是强内容还是强交互或者是游戏性。这些都是选择不同框架的主要出发点。
没有最好，只有最适合自己的，基本上，针对每个平台，我们都可以列出一些主流框架，但不意味着你们都能驾驭得住。小马过马，老牛没过膝，松鼠淹个半死，就是这么回事。但无论我们选择什么框架或决定自己动手造轮子，都勿忘初心，技术必须让我们工作生活更为轻松愉快——我们只选择我们能驾驭住的框架，我们不能保证它在一年后是否会过时落后。
而且按照我个人这么多年的经验来看，任何框架都会过时，往往不是因为他不够好，而是因为一定有更好的出来。我们再选择一个框架或者一个类库的时候就要想好，未来我如何抛弃他。至少不能成为我们引入新的框架的绊脚石。现实的工作中很多的团队往往会陷入到年复一年的用今年的新框架去重构去年老框架代码的历史循环中去。对于引入框架如何尽量延长他的生命力，我个人的意见是选择框架时去追求概念，而不是潮流，当我的架构可以接受新的设计概念的时候才去考虑引入新的框架。用设计理念的选择代替框架的选择。之所以这么说是因为我观察到我们部门的后端架构的开发理念跟我进公司的时候是差不多的。更多你可以参考成都网站建设
架构的组成
组件框架
2. 什么是"前端工程化"
前端工程化是指使用软件工程的技术和方法来进行前端的开发流程、技术、工具、经验等规范化、标准化。其主要目的为了提高效率和降低成本，即提高开发过程中的开发效率，减少不必要的重复工作时间。
前端工程化是前端架构中重要的一环，主要就是为了解决上述大部分问题的。而前端工程本质上是软件工程的一种，因此我们应该从软件工程的角度来研究前端工程。
前端工程化有四个特点：模块化、组件化、自动化、规范化。
1、模块化：
就是将一个大文件拆分成相互依赖的小文件，再进行统一的拼装和加载。只有这样，才有多人协助的可能。在工程化之前，一直是使用js、jquery、ajax，这没有模块概念，对于开发大型且复杂的系统会有一定的限制。
2、组件化：
组件化≠模块化。模板化只是在文件层面上，对代码和资源的拆分；组件化是在设计层面上，对于UI的拆分。目前市场上的组件化框架最多，主要的有Vue，React，Angular2。
3、自动化：
“简单重复的工作交给机器来做”，自动化也就是有很多自动化工具代替我们来完成，例如持续集成、自动化构建、自动化部署、自动化测试等等。
4、规范化：（至关重要的一环）
在项目规划初期制定的好坏对于后期的开发有一定影响。包括的规范有：
目录结构的制定、编码规范、前后端接口规范、文档规范、组件管理、Git分支管理、Commit描述规范、定期codeReview、视觉图标规范。
(2)前端模块化组件化扩展阅读：
为什么需要前端工程化：
前端越来越复杂，设计的问题和环节也越来越多，不采用工程化管理，就无法很好的实现团队协同和降低复杂性。 原因如下：
1、前端范畴不断扩大
早期的前端只需要适配桌面浏览器，而现在的前端，需要适配不同类型和尺寸的设备，包括移动端网页，app应用等。
2、前后端分离
早期的前端只是后端 MVC 框架的一层模块， 而现在的前端普遍是从后端接口获取数据，编写处理逻辑，各种前端mvc前端框架也层出不穷。
3、模块化开发的出现
现在的前端开发不再是从零写起，重复造轮子，而是会引用大量内部和外部的组件和模块，这也导致前端必须进行模块管理。
4、转码器的盛行
为了提高效率，前端工程往往不会直接写html,css,和js代码，而是改用其他格式书写，再用工具编译为目标格式。
比如用Jade 写HTML，用less、sass、stylus 编写CSS,用ES6、Typescript编写JavaScript。
5、开发流程和团队
早期的前端团队往往只有几个人，而现在的前端团队可以扩展到几十人，甚至上百人。每个人只负责自己的一块内容。所以，如何协调多人多团队的工作，保证沟通顺畅，保证权限管理，越来越成为一大问题。
前端工程化的具体内容：
1、代码规范: 保证团队所有成员以同样的规范开发代码。
2、分支管理: 不同的开发人员开发不同的功能或组件，按照统一的流程合并到主干。
3、模块管理: 一方面，团队引用的模块应该是规范的;另一方面，必须保证这些模块可以正确的加入到最终编译好的包文件中。
4、自动化测试：为了保证和并进主干的代码达到质量标准，必须有测试，而且测试应该是自动化的，可以回归的；
5、构建：主干更新以后，自动将代码编译为最终的目标格式，并且准备好各种静态资源；
6、部署：将构建好的代码部署到生产环境。
3. 前端如何提升开发效率
来具体聊一聊提高前端工程师开发效率的那些方法！
当然除了以上5点，对于前端来说需要提高开发效率的地方还有很多，可谓任重而道远。希望以上几点能够给初识前端的同学带来启发并能够亲自实践。
4. 如何理解前端模块化
前端模块化
在JavaScript发展初期就是为了实现简单的页面交互逻辑，寥寥数语即可；如今CPU、浏览器性能得到了极大的提升，很多页面逻辑迁移到了客户端（表单验证等），随着web2.0时代的到来，Ajax技术得到广泛应用，jQuery等前端库层出不穷，前端代码日益膨胀
这时候JavaScript作为嵌入式的脚本语言的定位动摇了，JavaScript却没有为组织代码提供任何明显帮助，甚至没有类的概念，更不用说模块（mole）了，JavaScript极其简单的代码组织规范不足以驾驭如此庞大规模的代码
模块
既然JavaScript不能handle如此大规模的代码，我们可以借鉴一下其它语言是怎么处理大规模程序设计的，在Java中有一个重要带概念——package，逻辑上相关的代码组织到同一个包内，包内是一个相对独立的王国，不用担心命名冲突什么的，那么外部如果使用呢？直接import对应的package即可
import java.util.ArrayList;
遗憾的是JavaScript在设计时定位原因，没有提供类似的功能，开发者需要模拟出类似的功能，来隔离、组织复杂的JavaScript代码，我们称为模块化。
一个模块就是实现特定功能的文件，有了模块，我们就可以更方便地使用别人的代码，想要什么功能，就加载什么模块。模块开发需要遵循一定的规范，各行其是就都乱套了
规范形成的过程是痛苦的，前端的先驱在刀耕火种、茹毛饮血的阶段开始，发展到现在初具规模，简单了解一下这段不凡的历程
函数封装
我们在讲函数的时候提到，函数一个功能就是实现特定逻辑的一组语句打包，而且JavaScript的作用域就是基于函数的，所以把函数作为模块化的第一步是很自然的事情，在一个文件里面编写几个相关函数就是最开始的模块了
function fn1(){
statement
}
function fn2(){
statement
}
这样在需要的以后夹在函数所在文件，调用函数就可以了
这种做法的缺点很明显：污染了全局变量，无法保证不与其他模块发生变量名冲突，而且模块成员之间没什么关系。
对象
为了解决上面问题，对象的写法应运而生，可以把所有的模块成员封装在一个对象中
var myMole = {
var1: 1,
var2: 2,
fn1: function(){
},
fn2: function(){
}
}
这样我们在希望调用模块的时候引用对应文件，然后
myMole.fn2();
这样避免了变量污染，只要保证模块名唯一即可，同时同一模块内的成员也有了关系
看似不错的解决方案，但是也有缺陷，外部可以随意修改内部成员
myModel.var1 = 100;
这样就会产生意外的安全问题
立即执行函数
可以通过立即执行函数，来达到隐藏细节的目的
var myMole = (function(){
var var1 = 1;
var var2 = 2;
function fn1(){
}
function fn2(){
}
return {
fn1: fn1,
fn2: fn2
};
})();
这样在模块外部无法修改我们没有暴露出来的变量、函数
上述做法就是我们模块化的基础，目前，通行的JavaScript模块规范主要有两种：CommonJS和AMD
CommonJS
我们先从CommonJS谈起，因为在网页端没有模块化编程只是页面JavaScript逻辑复杂，但也可以工作下去，在服务器端却一定要有模块，所以虽然JavaScript在web端发展这么多年，第一个流行的模块化规范却由服务器端的JavaScript应用带来，CommonJS规范是由NodeJS发扬光大，这标志着JavaScript模块化编程正式登上舞台。
定义模块
根据CommonJS规范，一个单独的文件就是一个模块。每一个模块都是一个单独的作用域，也就是说，在该模块内部定义的变量，无法被其他模块读取，除非定义为global对象的属性
模块输出：
模块只有一个出口，mole.exports对象，我们需要把模块希望输出的内容放入该对象
加载模块：
加载模块使用require方法，该方法读取一个文件并执行，返回文件内部的mole.exports对象
5. web前端学完css，js,会写基本的网站了，接下来该学哪个框架
http基础知识，jquery+bootstrap之类的快速构建，设计模式思想，框架思想如reactjs/angular/vue.js,前端工程化，包括代码规范，模块化(CommonJS,AMD,UMD,ES2015 Moudle)，css模块化（主要是SASS,LESS的mixin)，前端自动化（如gulp自动化，webpack打包），前端组件化（reactjs之类的组件化思想），版本控制管理，前端黑客攻防，数据可视化，HTML5游戏开发，图形学/图形算法，Nodejs全栈开发，React native之类的安卓/ios开发等等。很多，前端知识量增长速度之快，变化之迅速，需要你我不断学习，保持一颗热情的心。
6. 如何实现项目的模块化（组件化）开发，最近的做这个
，产品形态五花八门，涉猎极广，什么高大上的基础库/框架，拽炫酷的宣传页面，还有屌炸天的小游戏……不过这些一两个文件的小项目并非是前端技术的主要应用场景，更具商业价值的则是复杂的Web应用，它们功能完善，界面繁多，为用户提供了完整的产品体验，可能是新闻聚合网站，可能是在线购物平台，可能是社交网络，可能是金融信贷应用，可能是音乐互动社区，也可能是视频上传与分享平台……
7. 什么叫组件化开发
张克军 提出的“组件化就是函数式界面开发”这一说法我是难以接受的，函数式界面开发就让它好好地叫“函数式组件化”吧，不然我们会在所谓的“传统UI框架”和“函数式界面开发”之间出现一个Gap，岂不是又要造个词给填上，多累……
我前面说会有一个Gap，这个Gap很可能就是我们现在想用“组件化”这个定义去表达的一些点，我想在此做一些个人的见解
我将之理解为以下几要素：
组件是对逻辑的封装，不限于图形元素。即我们可以把if做成组件、把一个倒计时做成组件、把一段动画做成组件、把路由做成组件、把数据架构做成组件，而这些并不能称为控件
组件具备单个可移植性，即“随加载随用”，不需要为其准备复杂的基础条件（如引入样式、引入框架等）。然而这一点现有那些所谓组件库做得并不好，技术上也不大现实
组件是声明式定义的，而非命令式。这个不想多说，很大程度上是自己主观的一个想法
而上面最重要的就是第一点，所以要问我什么是“组件化开发”，我的说法是：
把图形、非图形的各种逻辑均抽象为一个统一的概念（组件）来实现开发的模式
这与传统开发框架的最大区别就是统一了图形元素与非图形元素，除此之外我再想不出其它真正体现区别的点了
在这个概念下，包括router、ajax、mole loader、timer、animation、interval等，都是组件，共享统一的生命周期管理和对外接口，且都是声明式地进行组合
我的一位同事告诉我去年的深JS上，有位淘宝的朋友的话题叫做“前端组件服务化”，这里面提的那些个概念，是很符合我对“组件化”的认识的，他要是不给再强安个“服务化”的噱头就好了- -
不过话说回来，在这个要求之下，组件其实不是那么好进行抽象设计的，随便说几个例子，有难的也有简单的：
非图形元素的各种需求如何统一接口，如timer和ajax
组件可以横向组件，但是纵向复用如何解决，如希望任何图形元素都可以实现被鼠标拖拽的效果，则鼠标拖拽应该也是个组件，这个组件与其它组件的关系是什么
有些组件对其可被组合的组件是有要求的，比如HTML里就不大好意思把一个<p>放进一个<span>里，这一点如何在组件上表达（实现不难，表达比较难）
一些我们原本想当然认为纯的小函数的东西，是不是也能当组件玩，比如underscore.pick要不要也是个组件
8. 怎样提高前端工程师开发效率，都在这里
前端工程师其实是一个工作很杂的职位，除了要负责切图、写html/css/js外，还要解决一系列的浏览器兼容性、网页性能优化等问题，所以提高前端工程师的开发效率是势在必行的，也是前端工程化的体现。
对于开发效率，我个人理解是
开发效率 = 新增代码的效率 + 修改代码的效率 + 维护代码的效率
那么如何提高前端开发效率便可以按照前端工程化的理念来进行划分。下面我就介绍下7个提高前端开发效率的方法。
1.切图
切图是一个前端最基础的技能，一般我们使用Photoshop或者FireWorks基本都能搞定设计师交付给我们的设计图，但是要提高切图效率的话就得使用一些诀窍了，比如利用PS里的动作来实现“一键切图”功能，这里除了切图外还介绍了其他的实用方法和工具。
2.编码
对于编写代码部分我们首先要找到一款合适自己的IDE工具，建议不要使用Notepad++或者Dreamweaver，这些工具已经不符合前端潮流了，无法让自己优雅地敲代码。这里我主要推荐Sublime Text、Atom或者Webstrom，因为它们除了人性化的界面和支持大多数语法的高亮外，还可以安装各种各样的插件来拓展你的IDE工具，下面我主要介绍几款Sublime Text提高开发效率的插件：
其中Element是用于快速编写html/CSS的，比如输入 ul>li 后按下tab键便可以生成一个ul标签里面包含一个li标签
JSFormat用于格式化JS；CSScomb用于对样式属性进行一键排序；HTML-CSS-JS Prettify可以一键规范我们的HTML/CSS/JS，甚至JSON格式；SublimeTmpl可以快速新建HTML/CSS/JS文件; ColorPicker用于调用本地调色板功能。这些工具都非常实用，一定程度上可以提高我们的编码效率。
3.自动化
说到提高开发效率，这里不得不提一些前端的自动化工具，毕竟前端自动化是目前及未来的趋势，能够很大程度上缩减前端不必要的工作量，使我们能够专注前端本身。
这里我们可以使用NPM来管理我们的项目包文件；利用webpack来打包压缩我们的代码；利用Node.js来实现构建本地服务器；利用Karma、Jasmine来测试我们的前端代码。
用好前端自动化工具可以帮助我们处理很多琐碎的事情，比如一键压缩代码、图片，一键合并JS，检测文件更新等。
4.模块化
随着web2.0时代的到来，Ajax技术得到广泛应用，前端代码日益膨胀，而前端模块化能够方便我们对项目代码的维护，进行按需加载，从长远角度来看对我们提高项目的开发效率同样大有益处。
在ES6出来之前应该说前端代码本身不具备实现模块的功能，我们必须要使用一些模块化加载器来实现，比如RequireJS、SeaJs等。而随着ES6的普及，目前像RequireJS、SeaJs这样的工具已经没有存在的必要了。所以在基于ES6的开发环境下我建议使用ES6的模块化功能来实现我们的前端模块化。
5.组件化
前端组件化的概念也是由来已久，我们可以通过将我们的代码划分成不同组件来实现功能公用，一个同样的功能我们可能不用再次编写相同的代码，同时也可以提高前端代码的可维护性和清晰度。以下是目前流行的前端框架Vue的单文件组件的概念图：
我们可以将公用的组件抽离，将大组件拆分成小组件的形式实现前端组件化，组件与组件之间可以存在父子关系，也可以存在兄弟关系。在Vue的单文件组件中，一个组件包含了其HTML、CSS、JS的代码片段。
6.前后端分离
前后端分离的项目对提升前端开发效率非常有帮助，因为前端不再需要后台配置路由、搭建服务器环境、编写模板等，这样一来前端的生产力就会得到很大程度的解放，但是前后端分离的项目有利也有弊，如下图所示：
最终我们需要根据项目需求衡量利弊来决定是否使用前后端分离的模式。
7.规范与模式
团队协作离不开编码规范和开发模式的帮助。遵循编码规范文档可以帮助我们在团队开发时提高合作开发的效率。一个团队遵循一套编码规范可以使每个人的代码写出一个人的风格，这样团队间相互审查、测试、完善功能时会非常高效。下方是一些开源的前端编码规范文档：
网页链接
首页-TGuide
网页链接
网页链接
除了编码规范我们在开发时经常会沿袭了一些已经存在的模式来解决问题，比如当用JS编写弹框时我们往往会用到单例模式，用CSS编写动画时直接套用动画的常用属性等，我们不再需要从头开始思考某一个功能的实现，这就是模式带来的意义。
结语
当然除了以上7点，对于前端来说需要提高开发效率的地方还有很多，可谓任重而道远。只有将前端无序、繁杂的操作组织起来，利用工具简化、规范前端流程，才能实现项目构建、开发、维护的一体化。希望本文能够给初识前端的同学带来启发并付诸实践。
9. 模块化和组件化的区别
组件和模块的定位不同。组件一般用于前端,模块化在后台运用的比较多。例如vue中的组件,主要是为了拆分vue实例的代码量,让我们可以以不同的组件来划分不同的功能模块,将来我们需要什么样的功能,就直接调用对应的组件即可。
10. 在前端中什么是组件化 什么是模块化
模块化更一种开发规范，比如cmd amd 是为了更好的解藕，比如一个网站，按照不同的模块来开发，比如你有个评论区，a 项目有，b 项目有，如果仅是单纯的模块开发，这个js 文件你就可以单独来回引用，
更比如 ，一个页面 分好多个功能， 这时候你要是都写在一个js 中 会越来越大，
而你把他分成不同的模块，
比如评论是一块
分页又是一块，
已经上线，或你不做了，后期别人拉手，或你接手别人的项目， 这时候来个需求让你把分页去掉，或修改 你可以清楚的找到对应模块文件 进行修改 或去掉
模块是自定义的，
组件，更想当于一个通用的东西，有的分功能组件，有的分业务组件
大图切换，这种就是单纯的一个效果展示，只要调用就ok
一个分页，也是只单纯的调用，
组件更是一个多处都可以使用 ，不需要再单独开发的