前端都在谈什么 - 前端工程化

什么叫工程化,大概就是能有个方法,让一大堆人,有组织有纪律地一起干活,目的是提高效率,保证质量。

早些年的前端都是Web后端开发人员兼着写的,用大型框架的少,最多的就是拿着jQuery做些事,一个页面来一发。如果找5个人写5个页面,写出来的代码可能就跟作文大赛一样的飘忽,好在那年头的代码量不多,凑合着用。

后来前端的系统越来越大,复杂性越来越高,玩不转了,就有很多新的东西出现,这两年是新的套路刷的飞起,各种工具跟打了激素一样。

进入正题,说说我眼中的前端工程化,先列个提纲

  1. 语言和转译器
  2. UI大型化
  3. MV转换引擎
  4. 组件化
  5. 路由
  6. 状态管理
  7. 前端测试
  8. 依赖管理和发布打包
  9. UED合作和设计规范

语言和转译器

现在主导JavaScript语言发展的是ECMA(European Computer Manufacturers Association,反正就是个标准化组织)下面的某个Group或者Committee之类的组织,所有语言标准叫做ECMAScript,语言的版本就叫做ECMAScriptX(数字),简称ESX。早期语言发展缓慢,ES3不知道写了多少年,后面来了ES5,做了小幅的进化。如果你问为什么没有ES4,据说是因为ES4的进化过于激进,完全得不到响应,就被丢弃了。最近的版本是2015年完成的ES6,后来被改名为ES2015,至少在我看来,进化的步子是相当大(激进)的。ES6被改名为ES2015的原因应该是(我个人揣测),ES想要加速推进语言的计划,所有用年份代替版本号,可以更频繁地推出小幅进化地版本。
那么问题来了,兼容性怎么处理呢,这个在国内问题更为突出。国外(当然主要是欧美)由于浏览器淘汰得快,所以还好。国内各种老旧浏览器的高覆盖率 ... 所有就产生了转译器。在开发时用高版本语言编写代码,然后用转译器转换成低版本的代码,在正式环境上运行以兼容旧浏览器。
那么用高版本语言(比方说ES6)写代码有什么好处呢?在我开来,至少像箭头函数和类申明这样的语法糖衣是显然能提升开发效率和代码可读性(美感)的。大家也可以看看知乎的争论。
然而有人还是不满意JavaScript,所有有了TypeScript、CoffeeScript这样的语言,同样的可以通过转译这样的方式来是使用。
在我看来,由于语言进化和兼容性之间的冲突在可见未来会一直在,转译在前端领域也会长期的存在。
这个领域现在最著名的应该是Babel了。

UI大型化

核心目标还是在提升效率和增加可靠性。

MV转换引擎

我用了个拗口的词汇,似乎其他地方都没有见过,因为找不到更合适的词来描述我心中这样的功能。通过模板语言和单向/双向数据绑定,前端开发效率得到大幅的提升。从以前的DOM操作到现在的模板语言操作,感觉就像是汽车从手动挡换到了自动挡。不知道再过5年,像DOM操作这样的内容还是不是前端的必备技能。

组件化

程序大型的关键就是组件化,一则能够把程序的逻辑拆分到组件的颗粒度以降低复杂度,二则能够通过复用的方式提升系统的开发效率和可维护性。从这些角度看,组件化的目的和面向对象其实是共通的。

MV转换引擎和组件化是MV*框架的核心功能,这个领域最著名的是AngularJS、React 和 Vue。

路由

当程序越来越大的时候,前端的路由开始出现了。从感觉上来说,路由的作用非常像是模板页,动态的模板页。如果需要通过URL来定位,那么可以通过把URL的hash部分和路由的状态做绑定,但这个其实不是必须的。实际的代码经验是,要完全从URL恢复程序状态,不仅需要框架,也需要业务层的代码写的完善。
每个MV*框架都会有自己的路由库,像AngularJS就有自带的ngRoute和官方的第三方路由ui-router。

状态管理

程序复杂了之后,状态变的越来越不可控。常用AngularJS的同学应该有感觉,AngularJS是自动化程度相当高的框架,数据的双向绑定,指令内外的自动同步,如果你还用很多的watch,那 ... 随之而来,要判断数据改变的原因也越来越困难,程序变的很难琢磨。
于是前端的状态管理工具/模式诞生了,能找到的源头是flux。应用最广和知名度最高的应该算是Redux。

前端测试

跟界面操作有关的东西怎么做测试呢?之前和测试合作交流的时候知道,测试是有UI测试的套路的,也有相对应的工具比方说selenium。
开发角度的测试又是另一个路数。从两个方面讲讲前端的测试,一工具,二类型。
用比较流行的组合karma + jasmine来说明,karma把自己叫做Test Runner,其实就是一种自动化工具,能自动打开浏览器,运行测试代码,显示结果。这样能够减少人操作界面的重复劳动。而jasmine这样的呢,被称为测试框架,提供断言这样测试所需要的API。
从类型上说有单元测试和端到端测试。单元测试的思想和后端比较像,但是前端是用户操作的,怎么测呢?现在的MV*框架都有逻辑和视图分离的套路,单元测试一般只测逻辑。

依赖管理和发布打包

JavaScript长期以来都是没有正式的模块化方案的。对,ES6刚出了正统的模块化方案,但总觉得他不能解决所有的问题,比方说正式环境需要合并代码怎么办?
上古时期,前端就靠脚本加载的顺序实现以来管理,但是一个页面有20个相互依赖的脚本你试试?哎,我还真写过 ...
后来因为长期没有正式的规范,各路兵马就自己起了炉灶,CommonJS和AMD是使用最广泛的,最重要的区别是AMD支持异步方式,这对浏览器环境很重要。
由于Node.js的出现,CommonJS用的已经相当相当广泛了,AMD在前端开发中用的也不少,ES6又来了import的模块化方案,于是三种方案并存就是现在的局面了,所以现在的发布打包工具就要支持3种模块化方案。
用模块化的方式编写代码,用发布工具生成正式代码,只是其中的一个功能。这些工具要能支撑完整的工作流,把前端开发从开发代码到正式代码所有的转换都集成到一个工具中,通过各种插件实现功能,比方所前面提到的转译,比方说合并、按需切分代码、压缩等等。
这个领域最著名的是webpack 和 browserify。

UED合作和设计规范

码农不懂设计,先放着 ...

你可能感兴趣的:(前端都在谈什么 - 前端工程化)