前端架构

在谈前端架构之前,需要先探讨一下不同人群对前端产生的困惑。前端这个职业最近几年才逐渐被认可,之前一直是低端的代名词,所以多数高手很不屑搞这个。之前的很多项目,人们对前端这块的要求也只是能用就行,所以很少会在上面去细致、深入地建立一套完善体系。而多数产品的技术经理也会是后端出身的,往往对前端的认识还停留在Java Struts那个原始的MVC模型上,或者首先想到的就是GWT和JSF,这是从后端角度出发的一种视角。用这类思维方式做出来的产品,一般用户体验都不会很好。

     另一方面,从界面层上手的人群,他对用户体验这方面会把控得比较好,但通常缺架构意识,或者说是软件工程的意识。在界面层比较复杂的情况下,很可能会有失控的趋势。对整个系统结构的认知程度通常不够深入,也缺乏设计模式等方面的知识。

开发人员会有一些困惑:

   § 创建项目的时候,一般没有人作前端的技术选型

                ·         拿到项目之后,没有直接可复制的基础版本

   §  习惯于引用第三方组件

                ·         赶功能,需要某个组件或者特效

                ·         上网搜到一个合适的,加进来

                ·         它还依赖一些别的库

                ·         文件大还是次要的

                ·         可能会产生冲突,样式也不一致

开发经理也会有一些困惑:

   §  协作过程感觉有问题

                ·         前端人员写原始界面,包含静态界面和特效

                ·         开发人员接着改,加逻辑

                ·         发现有问题要返工了

                ·         在谁的代码基础上继续改?如何合并?

   §  2014年了,为什么还有这么多人工环节?

                ·         能自动单元测试吗?

                ·         能自动发布打包吗?

用户会对这些事情感到烦恼:

   §  长得丑

                ·     界面老土

                ·         风格不一致

   §  速度慢

                ·         加载慢

                ·         渲染慢

                ·         执行慢

   §  出错

架构的本质是什么?其实也是一种管理。通常我们所说的管理,都是指对于任务和人员的管理,而架构管的是机器和代码。比如说,机器的部署属于运维的物理架构,SOA属于服务架构,那么,前端的架构指什么呢?

长期以来,前端所处的位置是比较偏应用层,而且是很薄的一层,而架构又要求深度和广度,所以之前在前端里面做架构,好比在小水塘里游泳,稍微扑腾两下就到处碰壁。但最近这几年来,前端的范围被大大拓展了,所以这一层逐渐变得大有可为。

怎样去理解架构呢?在早期的文字MUD游戏里,有这么一句话:“你感觉哪里不对,但是又说不上来。”在我们开发和使用软件系统的过程中,或多或少会遇到这样的感觉,有这种感觉就说明架构方面可能有些问题。

在狭义的前端领域,架构要处理的很重要的事情是组件的集成。由于JavaScript本身缺乏命名空间这样的机制,多数框架都倾向于自己搞一套,所以这方面的碎片化是很严重的。如果一个公司的实力不足以自研所有用到的组件,就会一直面临这方面的问题。

比如说,在做某个功能的过程中,发现需要一个组件,时间来不及做,就到网上搜了个,加到代码里面,先运行起来再说。一不小心,等功能做完的时候,已经引入了无数种组件了,有很多代码是重叠的,可能有的还有冲突,外观也不一致。

环顾四周的大型互联网公司,基本上都有自己的前端框架,比如阿里的Kissy和Arale,腾讯的JX,百度的Tangram,360的QWrap等,为什么?因为要整合别的框架,并且在此基础上发展适合自己的组件库,代价非常大,初期没办法的时候只能凑合,长期来说,所有代码都可控的意义非常重要。

那么,是不是一套框架可以包打天下呢,这个真的很难。对于不同的产品形态,如果想要用一套框架去适应,有的会偏轻,有的又偏重,有的要兼容低端浏览器,有的又不要,很难取舍。

常见的前端产品形态包括:

 §  内容型web站点 侧重渲染方面的优化,前端逻辑比重小

 §  操作型B/S系统 以数据和逻辑为中心,界面较规整

 §  内嵌Web的本地应用 要处理缓存和一些本地接口,包括PC客户端和移动端

另外有Web游戏,因为跟我们的企业形态关系不大,而且也比较独特,所以不包含在内。这三种产品的前端框架要处理的事情显然是不太一样的,所以可以细分成2-3种项目模板,整理出对应的种子项目,供同类产品初始化用。

   最近我们经常在前端领域听说两个词:全端、全栈

全端的意思是,原来的只做在浏览器中运行的Web程序不够,还要做各种终端,包括iosAndroid等本地应用,甚至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做几个图,搞一些花哨效果就可以了,它是一个系统工程,涉及从用户习惯调研、产品设计、前端开发、甚至后端服务等一系列环节,需要从易用度、观感、加载性能、流畅度等各方面共同提升。

这些东西都需要从全局角度作规划,从源头控制起,否则只能是头疼医头,脚痛医脚。为此,基础技术中心会逐步整合几套适合不同场景的基础前端框架,作为种子项目供今后的技术选型使用。此外,还会从前端开发的各种主题组织一些技术分享,并且逐步形成一套制度化,流程化的培训体系。

「五年博客,如果觉得我的文章对您有用,请帮助本站成长」

订阅周报 关注微博

发表评论

请登录后发表评论:

“前端架构”有2个评论

  1. leifeng

    转载 请注明出处!!!!!

    登录回复
    • 前端博客

      不知道哪个人写的。是从新浪博客摘来的。如果你知道可以告诉我一声。

      登录回复