前端工程之模块化

  1. 云栖社区>
  2. 博客>
  3. 正文

前端工程之模块化

webmirror 2018-03-07 17:49:17 浏览5644
展开阅读全文

从本质上讲,所有Web应用都是一种运行在网页浏览器中的软件,这些软件的图形用户界面(Graphical User Interface,简称GUI)即为前端

随着Web业务日益复杂化和多元化,前端开发已由以WebPage模式为主转变为以WebApp模式为主;现在随便找个前端项目,都已经不是过去的拼个页面+搞几个jQuery插件就能完成的了;工程复杂了就会产生许多问题,比如:如何进行高效的多人协作,如何保证项目的可维护性,如何提高项目的开发质量

前端工程化是前端架构中重要的一环,主要是为了解决上述大部分问题的,而前端工程本质上是软件工程的一种,因此我们应该从软件工程的角度来研究前端工程

前端工程化面临的问题

要解决前端工程化的问题,可以从两个角度入手:开发和部署。

1.从开发角度,要解决的问题包括:

提高开发生产效率/降低维护难度/减少请求数,降低请求量/减少重绘&回流

2.这两个问题的解决方案有两点:

制定开发规范,提高团队协作能力

分治;软件工程中有个很重要的概念叫做模块化开发其中心思想就是分治

从部署角度要解决的问题主要是资源管理,包括:

代码审查

压缩打包:合并样式/脚本文件,合并背景图片,CSS3图标/Icon Font/开启GZip/优化静态资源,jQuery->Zepto/阉割IScroll/去除冗余代码/图片无损压缩/图片延迟加载/减少Cookie携带

增量更新

单元测试

要解决上述问题,需要引入构建/编译阶段

所以,我个人认为前端工程化主要应该从模块化/组件化/规范化/自动化四个方面来思考:

模块化

简单来说,模块化就是将一个大文件拆分成相互依赖的小文件,再进行统一的拼装和加载;只有这样,才有多人协作的可能

JS的模块化

ES6之前,JavaScript一直没有模块系统,这对开发大型复杂的前端工程造成了巨大的障碍;对此社区制定了一些模块加载方案,如CommonJS/AMD/CMD等,某些框架也会有自己模块系统,比如Angular1.x

现在ES6已经在语言层面上规定了模块系统,完全可以取代现有的CommonJS和AMD规范,而且使用起来相当简洁,并且有静态加载的特性

规范确定了,然后就是模块的打包和加载问题:

1.用Webpack+Babel将所有模块打包成一个文件同步加载,也可以打成多个chunk异步加载

2.用SystemJS+Babel主要是分模块异步加载

3.用浏览器的

CSS的模块化

虽然SASS/LESS/Stylus等预处理器实现了CSS的文件拆分,但没有解决CSS模块化的一个重要问题:选择器的全局污染问题;按道理,一个模块化的文件应该要隐藏内部作用域,只暴露少量接口给使用者,而按照目前预处理器的方式导入一个CSS模块后,已存在的样式有被覆盖的风险;虽然重写样式是CSS的一个优势,但这并不利于多人协作;为了避免全局选择器的冲突,各厂都制定了自己的CSS命名风格:

1.BEM风格

2.Bootstrap风格

3.Semantic UI风格

但这些都毕竟是弱约束,选择器随着项目的增长变得越多越复杂,然后项目组里再来个新人带入自己的风格,就更加混乱了

所以我很赞同这句话:与其费尽心思地告诉别人要遵守某种规则以规避某种痛苦,倒不如从工具层面就消灭这种痛苦

资源的模块化

Webpack的强大之处不仅仅在于它统一了JS的各种模块系统,取代了Browserify/RequireJS/SeaJS的工作,更重要的是它的万能模块加载理念,即所有的资源都可以且也应该模块化

资源模块化后有三个好处:

依赖关系单一化;所有CSS和图片等资源的依赖关系统一走JS路线,无需额外处理CSS预处理器的依赖关系,也不需处理代码迁移时的图片合并/字体图片等路径问题

资源处理集成化;现在可以用loader对各种资源做各种事情,比如复杂的vue-loader等

项目结构清晰化;使用Webpack后你的项目结构总可以表示成这样的函数:dest = webpack(src, config)

组件化

首先,组件化≠模块化;模块化只是在文件层面上对代码或资源的拆分,而组件化是在设计层面上对UI(用户界面)的拆分;从UI拆分下来的每个包含模板(HTML)+样式(CSS)+逻辑(JS)功能完备的结构单元,我们称之为组件

其实,组件化更重要的是一种分治思想;这句话就是说页面上所有的东西都是组件,页面是个大型组件,可以拆成若干个中型组件,然后中型组件还可以再拆成若干个小型组件,小型组件也可以再拆,直到拆成DOM元素为止;DOM元素可以看成是浏览器自身的组件,作为组件的基本单元

传统前端框架/类库的思想是先组织DOM,然后把某些可复用的逻辑封装成组件来操作DOM,是DOM优先;而组件化框架/类库的思想是先来构思组件,然后用DOM这种基本单元结合相应逻辑来实现组件,是组件优先;其次,组件化实际上是一种按照模板(HTML)+样式(CSS)+逻辑(JS)三位一体的形式对面向对象的进一步抽象;所以我们除了封装组件本身,还要合理处理组件之间的关系,比如(逻辑)继承/(样式)扩展/(模板)嵌套和包含等,这些关系都可以归为依赖

其实组件化不是什么新鲜的东西,以前的客户端框架,像WinForm/WPF/Android等,它们从诞生那天起就是组件化的,而前端领域发展曲折,是从展示页面为主的WebPage模式走过来的,近两年才从客户端框架经验中引入了组件化思想;目前市面上的组件化框架很多,主要的有Vue/React/Angular 2,其实Vue文档中的对比其他框架一文已经讲得很详细了

规范化

模块化和组件化确定了开发模型,而这些东西的实现就需要规范去落实,规范化其实是工程化中很重要的一个部分,项目初期规范制定的好坏会直接影响到后期的开发质量,我能想到的有:

目录结构的制定

编码规范

前后端接口规范

文档规范

组件管理

Git分支管理

Commit描述规范

定期CodeReview

视觉图标规范

其中编码规范最好采取强制措施,配置git hooks可以实现Lint不过不能提交代码等机制,因为人是靠不住的

自动化

作为多年程序猿,应该秉持的一个理念是:任何简单机械的重复劳动都应该让机器去完成

图标合并

不要再用PS拼雪碧图了,统一走Webpack吧;不要再用Icomoon了,统一走Webpack吧

持续集成

自动化构建

自动化部署

自动化测试:前端自动化测试能够提高代码质量/减少人肉测试等,这些优点是不言而喻的;市面上前端测试框架有很多,选择哪个都不会有太大问题

感悟:必须承认,人在被鞭子赶着的时候总比自觉向前走走得快

网友评论

登录后评论
0/500
评论
webmirror
+ 关注