我的架构经验系列文章 - 前端架构

标签: 架构 经验 系列 | 发表时间:2014-07-23 16:28 | 作者:agevs
出处:http://www.iteye.com

框架层面:近几年前端发展很快,前端之所以叫前端因为前端是已经可以独立成为一种职业了,js也不再是十年前的玩具了,以前富客户端RIA的应用可能会用flash/flex或是silverlight,现在可以使用js来完成大部分的功能,因此js作为一门前端的支撑语言也不仅仅是进行的简单的编码,越来越多框架性的东西出现了。越来越多的开发模式转变为后端只是吐json的数据源,而前端做所有UI的事情。

MVC
MVC实现职责分离是很好的,大多数网站在后端都会引入MVC框架,对于一个前端负责所有呈现和前端业务逻辑的网站来说,使用MVC框架也是很有好处的。Javascript的MVC框架现在很多。每一个框架其实都有其特点的,但是前端的MVC框架会和后端的有些不同的。比如前端的MVC框架可能会做一些M和V元素的双向绑定,对于后端来说往往是单向的比较多。通过引入MVC框架我们可以让同一个页面做很多事情,通过一个不刷新的页面实现一个应用程序的根基,还可以很清晰地进行MVC的分离并且突出M的概念,这是没有框架所办不到的。

通讯
对于一个比较复杂的页面可能会有比较多的Javascript模块,如果要进行模块之间通讯的话(比如一个页面有左边菜单和导航以及列表,左边菜单点选一级分类之后要通知导航加上去这项,并且通知列表重新读取数据并刷新,然后从导航删除这个选择的话要通知列表重新获取数据,通知菜单显示所有)。对于比较复杂的通讯,如果把模块模块之间进行强耦合直接调用其它模块的函数的话是不利于可维护性的,我觉得可以引入发布订阅机制,每一个模块做了什么修改把信息发布出去,关心这个信息的人订阅这个信息,并且在回调函数里面做相应的操作就可以了。可以使用Amplifyjs作为发布订阅的框架。

模板
对于前端来说和后端一样一个比较麻烦的问题就是往往会在脚本里面把html也混在一起,个人觉得是这样的,如果对于非常琐碎一些dom修改问题倒不大,如果是大块的html拼接的话,数据和html甚至是css混合在一起,那么代码的可维护程度非常差。此时可以考虑使用一些模板引擎来分离数据和表现,比如Twitter hoganjs。由于很多模板引擎,比如大胡子引擎不仅仅是针对前端的,后端语言也有相应的引擎,因此甚至可以把模板放在文本文件中,前端后端共同使用一套模板引擎,也就是说现在的代码偏向于服务端渲染的那么就在后端使用模板,如果要以后改为客户端渲染了这套模板可以直接被前端使用。 资源示例

类库
除了框架之外还有很多类库,比如jquery,underscore,linq.js(linq to javascript),jscex(wind)反正后端有啥现在前端也有啥,尽情发挥想象吧。用好这些框架可以大大改善生产力的,脚本能做的事情真的比想象的要多的多。我是做后端的前端知道的不多在这里列出的可能只是九牛一毛。

依赖
可以使用Requirejs、Commonjs之类的组件来管理脚本之间的依赖,好处很多的,我们的模块只需要写清楚需要依赖什么,Requirejs自然会帮我们按照一定的次序加载进来,这样我们既不用担心顺序问题也不用担心组件的版本号问题。基于Requirejs它具有丰富的配置,即使是我们进行了静态资源合并也完全能处理,只要通过配置把组件配置到相同的服务端生成的一个路径上即可,不过以前在做的时候发现它会自动加上.js 扩展名,不过完全可以通过改Requirejs源代码解决。在架构上我的观点是既然使用开源的东西,遇到问题了就不要去怕改源代码。我们一定不能停留在框架的使用者,定制框架甚至向作者贡献自己的代码没有这么难。 设计层面:

职责分离的理念
虽然我们都知道CSS样式、JS行为以及HTML结构。个人觉得只有HTML是必须的,也就是说如果一个页面没有样式没有脚本的话它应该是一个清晰的页面,可以大致表现出页面需要表现的内容,只不过样子比较难看,并且也是交互的。如果说很多功能是ajax实现的话那么就把交互工作转到服务端实现服务端的渲染。多了样式只是布局上样子上更好看,多了脚本只是交互性上更友好,不需要刷新页面,但是少了也不代表这个网站就是废物了,现在有很多理念其实目的是一样的。如果达不到这个境界至少我们要很明确的让css、js和html履行自己的职责,不要把过多的事情赋予不相关的组件。比如尽量不要在html中包含操作性的脚本代码,而是应该直接在脚本中选择dom元素进行操作,尽量不要在脚本中包含大段的html代码而是应该从模板读取然后把数据填充进去,也尽量不要在html代码中包含大量内嵌的样式而是应该通过选择器选择进行样式赋值。 资源示例

分层和目录结构
对于一个比较复杂的大型的项目,合理规划目录结构也是很重要的,你可能会说脚本和样式分两个目录就可以了,但是如果一个复杂的项目有几百个脚本都列在一个文件夹下吗?后端有分层的概念其实前端完全也可以有分层的概念,有表现层、业务逻辑层和模型层,然后是下面的数据访问ajax层,当然还会有常量的文件,我反问觉得前端的分层可以超大型项目的ios或android程序来靠。比如之前我做的一个ios程序的示例,个人觉得这样的分层就比较一目了然的。

合并和拆分的平衡
很多时候架构上的东西就是一种权衡,如果有固定的标准的话也就不需要架构师了,我们只需要按照固定的标准去做就行了。比如,一个页面上使用了10个脚本文件,5个样式文件,按道理说合并成两个文件可以达到最小的请求数,但这样一定是好的吗?这个10个脚本和5个样式文件中有很多或许是其它页面也需要公用的,如果仅仅简单的合并在一起反而可能增加用户的下载流量,因此怎么规划通用的东西合成一个文件,框架的文件单独,而每一个页面都有自己独特的脚本和样式,也是一种学问。 性能层面:

性能检测
诸如YSlow和PageSpeed等工具可以分析出前端的性能问题,在这里就不展开讨论了。对于前端来说由于涉及到用户的客户端环境和网络环境所以情况不是这么单纯,但是我们可以做到的就是在我们的可控范围之内尽量减少用户域名解析数量,减少用户下载的数据量,增加并发等等。其实说白了,我们就是清理管道使得管道更大,或者增加更多的管道,或者就是尽量让管道之内的水少一点了,这样就可以更顺畅。 资源示例

性能分析

现在有一些工具可以对Javascript的性能甚至是DOM解析的情况进行细致的分析,比如dynaTrace AJAX Edition,通过这样的工具我们可以分析我们的脚本代码以及页面布局是否合理,从开发的角度来全面了解和优化我们的前端代码。客户端的资源虽然不像服务端的资源这么重要,但是为了给用户的机制体验最好还是对客户端的性能消耗有所优化。

最后分享关于这个主题的一个小的精美组件: 这里



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [架构 经验 系列] 推荐:

我的架构经验系列文章 - 前端架构

- - JavaScript - Web前端 - ITeye博客
框架层面:近几年前端发展很快,前端之所以叫前端因为前端是已经可以独立成为一种职业了,js也不再是十年前的玩具了,以前富客户端RIA的应用可能会用flash/flex或是silverlight,现在可以使用js来完成大部分的功能,因此js作为一门前端的支撑语言也不仅仅是进行的简单的编码,越来越多框架性的东西出现了.

可伸缩系统的架构经验

- - 简单文本
最近,阅读了Will Larson的文章 Introduction to Architecting System for Scale,感觉很有价值. 作者分享了他在Yahoo!与Digg收获的设计可伸缩系统的架构经验. 在我过往的架构经验中,由于主要参与开发企业软件系统,这种面向企业内部的软件系统通常不会有太大的负载量,太多的并发量,因而对于系统的可伸缩性考虑较少.

AMD发布“推土机”架构FX系列处理器

- 洞箫 - cnBeta.COM
北京时间10月12日下午消息,经过漫长等待,AMD最终揭开了FX系列处理器的神秘面纱,这一系列处理器采用AMD耗时多年研发的新一代“推土机”架构. 据AMD介绍,该公司开发FX系列处理器是用以“满足那些寻求获得最高性能和可升级性的用户的需求. ”换言之,AMD希望通过率先推出重磅产品引领业界潮流,今后还将推出价格更为低廉的组件.

TC Disrupt 系列:马化腾谈创业经验和困难

- blueslan - 爱范儿 · Beats of Bits
作为 TechCrunch Disrupt 的第一场访谈嘉宾,马化腾花了很多时间来讲述自己早期的创业故事. “腾讯在初期,其实也是依托于中国移动的需求而成长起来的. 那个时候还没有生态环境的概念,但对于第三方开发商来说,机会是非常重要的. 腾讯早期想开发软件或游戏卖给互联网公司,QQ (OICQ)只是项目之一.

服务好“最后一公里”,高效CDN架构经验

- - 神刀网
国内,随着互联网的高速发展,因为各大通信公司的政策,造成了南电信北联通互通有局限性,再加上大小且质量参差不齐的运营商,在这特殊的氛围的互联互通下号称“八线合一”的机房开始崭露头角. 互联网的广泛性使得网民分散在全国各地,由于全国地区的经济发展和互联网建设的不平衡,实际网民的体验往往受限于最后一公里的速度.

高可用可伸缩架构实用经验谈

- - 博客园_知识库
  移动互联网、云计算和大数据的成熟和发展,让更多的好想法得以在很短的时间内实现为产品. 此时,如果用户需求抓得准,用户数量将很可能获得爆发式增长,而不需要像以往一样需要精心运营几年的时间. 然而用户数量的快速增长(尤其是短时间内的爆发式增长),通常会让应用开发者有些吃不消,不得不面临一些严峻的技术挑战:如何避免因为单台机器当机导致服务不可用;如何避免在服务容量不足时,用户体验下降,等等.

x86服务器新主流:Intel Xeon E5-2600系列架构与性能详解

- - 服务器运维与网站架构|Linux运维|X研究
PS:从2012年年中开始,Intel Xeon E5-2600系列的新型CPU已经逐渐在各种主流的x86服务器上成标配了,如Dell R720、Dell R620、IBM x3650 M4等,发现很多搞系统运维的兄弟对这些服务器硬件配置了解不多,一知半解. 还是有必要深入了解,转载一篇对理解这方面很有用的文章:.

千万级规模高性能、高并发的网络架构经验分享

- - 编程语言 - ITeye博客
在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们 战略上 要重 视 它 , 战术上又 要 藐 视 它. 先举个例子感受一下千万级到底是什么数量级. 现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右.

资深架构师的经验分享——软件项目开发和决策

- - Java - 编程语言 - ITeye博客
参与项目决策的人必须意识到他们的决定对项目的成功和成本以及时间和金钱的影响. 对于我20多年的软件开发经验和10多年的咨询工作,我作为架构师或开发人员参与了许多项目 - 其中大多数成功,有些失败,但每个项目(无论成功与否)都涉及好的和不好的决策由各种人制作. 本文的目的是通过提倡根据我的经验做出的决定以及避免错误的决策来为项目成功奠定基础.

微众银行数据库架构演进及 TiDB 实践经验 - 推酷

- -
胡盼盼,微众银行数据平台室室经理. 硕士毕业于华中科技大学,毕业后加入腾讯,任高级工程师,从事分布式存储与云数据库相关的研发与运营工作;2014 年加入微众银行,负责微众银行的数据库平台的建设与运营. 黄蔚,微众银行数据库平台室高级 DBA. 2011 年加入腾讯互动娱乐运营部,担任英雄联盟在内的多款海量用户产品的数据库运维工作.