前端架构那些事

 　　在谈前端架构以前，须要先探讨一下不一样人群对前端产生的困惑。前端这个职业最近几年才逐渐被承认，以前一直是低端的代名词，因此多数高手很不屑搞这个。以前的不少项目，人们对前端这块的要求也只是能用就行，因此不多会在上面去细致、深刻地创建一套完善体系。而多数产品的技术经理也会是后端出身的，每每对前端的认识还停留在Java Struts那个原始的MVC模型上，或者首先想到的就是GWT和JSF，这是从后端角度出发的一种视角。用这类思惟方式作出来的产品，通常用户体验都不会很好。 　　另外一方面，从界面层上手的人群，他对用户体验这方面会把控得比较好，但一般缺架构意识，或者说是软件工程的意识。在界面层比较复杂的状况下，极可能会有失控的趋势。对整个系统结构的认知程度一般不够深刻，也缺少设计模式等方面的知识。 　　开发人员会有一些困惑： 建立项目的时候，通常没有人做前端的技术选型 拿到项目以后，没有直接可复制的基础版本 　　习惯于引用第三方组件 赶功能，须要某个组件或者特效 上网搜到一个合适的，加进来 它还依赖一些别的库 文件大仍是次要的 可能会产生冲突，样式也不一致 　　开发经理也会有一些困惑： 协做过程感受有问题 前端人员写原始界面，包含静态界面和特效 开发人员接着改，加逻辑 发现有问题要返工了 在谁的代码基础上继续改？如何合并？ 　　2014年了，为何还有这么多人工环节？ 能自动单元测试吗？ 能自动发布打包吗？ 　　用户会对这些事情感到烦恼： 　　长得丑 界面老土 风格不一致 　　速度慢 加载慢 渲染慢 执行慢 　　出错 　　架构的本质是什么？其实也是一种管理。一般咱们所说的管理，都是指对于任务和人员的管理，而架构管的是机器和代码。好比说，机器的部署属于运维的物理架构，SOA属于服务架构，那么，前端的架构指什么呢？ 　　长期以来，前端所处的位置是比较偏应用层，并且是很薄的一层，而架构又要求深度和广度，因此以前在前端里面作架构，比如在小水塘里游泳，稍微扑腾两下就处处碰壁。但最近这几年来，前端的范围被大大拓展了，因此这一层逐渐变得大有可为。 　　怎样去理解架构呢？在早期的文字MUD游戏里，有这么一句话：“你感受哪里不对，可是又说不上来。”在咱们开发和使用软件系统的过程当中，或多或少会遇到这样的感受，有这种感受就说明架构方面可能有些问题。 　　在狭义的前端领域，架构要处理的很重要的事情是组件的集成。因为JavaScript自己缺少命名空间这样的机制，多数框架都倾向于本身搞一套，因此这方面的碎片化是很严重的。若是一个公司的实力不足以自研全部用到的组件，就会一直面临这方面的问题。 　　好比说，在作某个功能的过程当中，发现须要一个组件，时间来不及作，就到网上搜了个，加到代码里面，先运行起来再说。一不当心，等功能作完的时候，已经引入了无数种组件了，有不少代码是重叠的，可能有的还有冲突，外观也不一致。 　　环顾四周的大型互联网公司，基本上都有本身的前端框架，好比阿里的Kissy和Arale，腾讯的JX，百度的Tangram，360的QWrap等，为何？由于要整合别的框架，而且在此基础上发展适合本身的组件库，代价很是大，初期没办法的时候只能凑合，长期来讲，全部代码均可控的意义很是重要。 　　那么，是否是一套框架能够包打天下呢，这个真的很难。对于不一样的产品形态，若是想要用一套框架去适应，有的会偏轻，有的又偏重，有的要兼容低端浏览器，有的又不要，很难取舍。 　　常见的前端产品形态包括： 内容型Web站点 侧重渲染方面的优化，前端逻辑比重小 操做型B/S系统 以数据和逻辑为中心，界面较规整 内嵌Web的本地应用 要处理缓存和一些本地接口，包括PC客户端和移动端 　　另外有Web游戏，由于跟咱们的企业形态关系不大，并且也比较独特，因此不包含在内。这三种产品的前端框架要处理的事情显然是不太同样的，因此能够细分红2-3种项目模板，整理出对应的种子项目，供同类产品初始化用。 　　最近咱们常常在前端领域据说两个词：全端、全栈。 　　全端的意思是，原来的只作在浏览器中运行的Web程序不够，还要作各类终端，包括iOS，Android等本地应用，甚至PC桌面应用。 　　为何广义的前端应当包含本地应用呢？由于如今的本地应用，基于不少考虑，都变成了混合应用，也就是说，开发这个应用的技术，既包含原生的代码，也包含了嵌入的HTML5代码。这么一来，就形成了开发本地应用的人技能要求较广，可以根据产品的场景，合理选择每一个功能应当使用的技术。 　　如今有一些PC端的混合应用开发技术，好比node-webkit和hex，前者的典型应用是Intel® XDK，后者的典型应用是有道词典，此外，豌豆荚的PC客户端也是采用相似技术的，也有一些产品是用的qt-webkit。这类技术能够方便作跨平台，极大减小开发工做量。 　　因此，咱们能够看到，在不少公司，开发安卓、iOS应用的人员跟Web前端的处于同一个团队中，这很大程度上就是考虑到这种状况。 　　全栈的意思是，除了只作在浏览器中运行的代码，还写一些服务端的代码，这个需求又是从哪里来的呢？ 　　这个需求其实来自优化。咱们要优化一个系统的前端部分，有这么一些事情能够作： HTML结构的优化，减小DOM树的层次等等 CSS渲染性能的优化，批量写入DOM变动之类 资源文件的优化，好比小图片的合并，图像格式的处理，图标字体的使用等 JavaScript逻辑的优化，模块化，异步加载，性能优化 加载字节量的优化，主要是分摊的策略 HTTP请求的优化 　　这里面，除了前三条，其余均可能跟后端有些关系，尤为是最后一条。可是前端的人无法去优化后端的东西，这是不一样的协做环节，因此就很麻烦。 　　那么，若是有了全栈，这个问题能够怎么解决呢？ 　　好比说，咱们要作最原始的小文件合并，能够在服务器作一些配置，把多个合并成一个请求，好比天猫的某个url： 　　http://g.tbcdn.cn/kissy/k/1.4.1/??dom/base-min.js,event-min.js,event/dom/base-min.js,event/base-min.js,event/dom/touch-min.js,event/dom/shake-min.js,event/dom/focusin-min.js,event/custom-min.js,cookie-min.js?t=1.js 　　这个就很明显是多个文件合并而成的，9个小文件的请求，合并成了一个64k的文件请求。 　　这种简单的事情能够在静态代理服务器上配置出来，更复杂的就比较难了，须要必定的服务端逻辑。好比说，咱们有多个ajax请求，请求不一样的服务，每一个请求的数据量都很是少，但由于请求数不少，可能会影响加载性能，若是能把它们在服务端就合并成一个就行了。但这个优化是前端发起的，传统模式下，他的职责范围有限，优化不到服务端去，而这多个服务极可能是跨产品模块的，想要合并，放在哪一个后端团队都很怪异。 　　这可真难办，就像老虎追猴子，猴子上了树，老虎只能在下面干瞪眼。可是若是咱们能让老虎上树，这就不是个问题了。若是有这么一层NodeJS，这一层彻底由前端程序员控制，他就能够在这个地方作这种合并，很是的合理。 　　除此以外，咱们经常会用到HTML模板，但使用它的最佳位置是随着产品的场景而不一样的，可能某个地方在前端更好，可能某个地方在后端好些。到底放在哪合适，只有前端开发人员才会知道，若是前端开发人员不能参与一部分后端代码的开发，优化工做也仍是作不完全。有NodeJS以后会怎样呢，由于无论前端模板仍是后端模板，都是JavaScript的，可使用同一套库，这样在作调整的时候不会有代码迁移的烦恼，直接把模板换地方便可。 　　如今，也有不少业务场景有实时通讯的需求，目前来讲最合适的方案是Socket.io，它默认使用NodeJS来当服务端，这也是NodeJS的一个重要使用场景。 　　这样，前端开发人员也部分参与了运行在服务端的代码，他的工做范围从原先客户端浏览器，向后拓展了一个薄层，因此就有了全栈的称呼。至于说这个称呼还继续扩展，一个前端开发人员从视觉到交互到静态HTML到JavaScript包办的状况，这个就有些过头了。 　　以上这些，主要解决的都是代码层面的事情。另外有一个方面，也是须要关注，但却经常不能引发重视的，那就是前端的工程化问题。 　　早期为何没有这些问题？由于那时候前端很简单，复杂度不高，如今整个很复杂了，就带来了不少管理问题。好比说整个系统的前端都组件化了以后，HTML会拆分红各类模板，JavaScript会拆分红各类模块，而CSS也经过LESS或者SASS这种方式，变成了一种编译式的语言。 　　这时候，咱们考虑一个所谓的组件，它就比较麻烦了。它多是一个或者多个HTML模板，加上一个或者多个JavaScript模块，再包含CSS中的一部分构成的，而前二者均可能有依赖项，三个部分也都要避免与其余组件的冲突。 　　这些东西都须要管理，而且提供一种比较好的方案去维护。在JavaScript被模块化以后，也能够经过单元测试来控制它们的质量，而且把这个过程自动化，每次版本有变动以前，保证它们最基本的正确性。最终，须要有一种自动化的发布机制，把这几类代码提取，打包合并，压缩，发布。 　　这个主题展开能够讲不少，因此咱们不在本次分享中涉及。在我以前的几篇文章中，也阐述过观点。 　　目前这方面研究最深刻的是以前百度FIS团队的张云龙，他的几篇文章在这里，强烈推荐阅读。 　　后记： 　　这篇文章是我入职苏宁以后第一次公开分享，目标受众主要是后端出身的技术经理，目的是让这个群体能有更多的前端意识。如今公司的项目基本都有前端模块，但人员专职程度较低，水平也良莠不齐。苏宁的战略口号之一是提高用户体验，从产品角度看，用户体验的提高并不是是UI作几个图，搞一些花哨效果就能够了，它是一个系统工程，涉及从用户习惯调研、产品设计、前端开发、甚至后端服务等一系列环节，须要从易用度、观感、加载性能、流畅度等各方面共同提高。 　　这些东西都须要从全局角度做规划，从源头控制起，不然只能是头疼医头，脚痛医脚。为此，基础技术中心会逐步整合几套适合不一样场景的基础前端框架，做为种子项目供从此的技术选型使用。此外，还会从前端开发的各类主题组织一些技术分享，而且逐步造成一套制度化，流程化的培训体系。