当前位置: 棋牌电玩游戏平台 > 独家报道 > 正文

浅谈什么是前端工程化,浅谈工程化

时间:2019-09-03 01:44来源:独家报道
1. 什么是前端工程化 自有前端工程师这个称谓以来,前端的发展可谓是日新月异。相比较已经非常成熟的其他领域,前端虽是后起之秀,但其野蛮生长是其他领域不能比的。虽然前端技

1. 什么是前端工程化

自有前端工程师这个称谓以来,前端的发展可谓是日新月异。相比较已经非常成熟的其他领域,前端虽是后起之秀,但其野蛮生长是其他领域不能比的。虽然前端技术飞快发展,但是前端整体的工程生态并没有同步跟进。目前绝大多数的前端团队仍然使用非常原始的“切图(FE)->套模板(RD)”的开发模式,这种模式下的前端开发虽说不是刀耕火种的原始状态,但是效率非常低下。

前端的工程化问题与传统的软件工程虽然有所不同,但是面临的问题是一样的。我们首先回顾一下传统的软件开发流程模型:
图片 1

上图中的运行和维护并不是串行关系,也并非绝对的并行关系。维护贯穿从编码到运行的整个流程。

如果说计算机科学要解决的是系统的某个具体问题,或者更通俗点说是面向编码的,那么工程化要解决的是如何提高整个系统生产效率。所以,与其说软件工程是一门科学,不如说它更偏向于管理学和方法论。

软件工程是个很宽泛的话题,每个人都有自己的理解。以上是笔者个人的理解,仅供参考。

具体到前端工程化,面临的问题是如何提高编码->测试->维护阶段的生产效率。

可能会有人认为应该包括需求分析和设计阶段,上图展示的软件开发模型中,这两个阶段具体到前端开发领域,更恰当的称谓应该是功能需求分析和UI设计,分别由产品经理和UI工程师完成。至于API需求分析和API设计,应该包括在编码阶段。

浅谈什么是前端工程化,浅谈工程化

1. 什么是前端工程化

自有前端工程师这个称谓以来,前端的发展可谓是日新月异。相比较已经非常成熟的其他领域,前端虽是后起之秀,但其野蛮生长是其他领域不能比的。虽然前端技术飞快发展,但是前端整体的工程生态并没有同步跟进。目前绝大多数的前端团队仍然使用非常原始的“切图(FE)->套模板(RD)”的开发模式,这种模式下的前端开发虽说不是刀耕火种的原始状态,但是效率非常低下。

前端的工程化问题与传统的软件工程虽然有所不同,但是面临的问题是一样的。我们首先回顾一下传统的软件开发流程模型:
图片 2

上图中的运行和维护并不是串行关系,也并非绝对的并行关系。维护贯穿从编码到运行的整个流程。

如果说计算机科学要解决的是系统的某个具体问题,或者更通俗点说是面向编码的,那么工程化要解决的是如何提高整个系统生产效率。所以,与其说软件工程是一门科学,不如说它更偏向于管理学和方法论。

软件工程是个很宽泛的话题,每个人都有自己的理解。以上是笔者个人的理解,仅供参考。

具体到前端工程化,面临的问题是如何提高编码->测试->维护阶段的生产效率。

可能会有人认为应该包括需求分析和设计阶段,上图展示的软件开发模型中,这两个阶段具体到前端开发领域,更恰当的称谓应该是功能需求分析UI设计,分别由产品经理和UI工程师完成。至于API需求分析和API设计,应该包括在编码阶段。

2. 前端工程化面临的问题

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

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

  1. 提高开发生产效率;
  2. 降低维护难度。

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

  1. 制定开发规范,提高团队协作能力;
  2. 分治。软件工程中有个很重要的概念叫做模块化开发其中心思想就是分治。

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

  1. 代码审查;
  2. 压缩打包;
  3. 增量更新;
  4. 单元测试;

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

1. 什么是前端工程化

自有前端工程师这个称谓以来,前端的发展可谓是日新月异。相比较已经非常成熟的其他领域,前端虽是后起之秀,但其野蛮生长是其他领域不能比的。虽然前端技术飞快发展,但是前端整体的工程生态并没有同步跟进。目前绝大多数的前端团队仍然使用非常原始的“切图(FE)->套模板(RD)”的开发模式,这种模式下的前端开发虽说不是刀耕火种的原始状态,但是效率非常低下。

前端的工程化问题与传统的软件工程虽然有所不同,但是面临的问题是一样的。我们首先回顾一下传统的软件开发流程模型:
图片 3

上图中的运行和维护并不是串行关系,也并非绝对的并行关系。维护贯穿从编码到运行的整个流程。

如果说计算机科学要解决的是系统的某个具体问题,或者更通俗点说是面向编码的,那么工程化要解决的是如何提高整个系统生产效率。所以,与其说软件工程是一门科学,不如说它更偏向于管理学和方法论。

软件工程是个很宽泛的话题,每个人都有自己的理解。以上是笔者个人的理解,仅供参考。

具体到前端工程化,面临的问题是如何提高编码->测试->维护阶段的生产效率。

可能会有人认为应该包括需求分析和设计阶段,上图展示的软件开发模型中,这两个阶段具体到前端开发领域,更恰当的称谓应该是功能需求分析和UI设计,分别由产品经理和UI工程师完成。至于API需求分析和API设计,应该包括在编码阶段。

2. 前端工程化面临的问题

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

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

  1. 提高开发生产效率;
  2. 降低维护难度。

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

  1. 制定开发规范,提高团队协作能力;
  2. 分治。软件工程中有个很重要的概念叫做模块化开发其中心思想就是分治。

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

  1. 代码审查;
  2. 压缩打包;
  3. 增量更新;
  4. 单元测试;

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

2.1 开发规范

开发规范的目的是统一团队成员的编码规范,便于团队协作和代码维护。开发规范没有统一的标准,每个团队可以建立自己的一套规范体系。

值得一提的是JavaScript的开发规范,尤其是在ES2015越来越普及的局面下,保持良好的编码风格是非常必要的。笔者推荐Airbnb的eslint规范。

2. 前端工程化面临的问题

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

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

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

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

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

2.1 开发规范

开发规范的目的是统一团队成员的编码规范,便于团队协作和代码维护。开发规范没有统一的标准,每个团队可以建立自己的一套规范体系。

值得一提的是JavaScript的开发规范,尤其是在ES2015越来越普及的局面下,保持良好的编码风格是非常必要的。笔者推荐Airbnb的eslint规范。

2.2 模块/组件化开发

2.1 开发规范

开发规范的目的是统一团队成员的编码规范,便于团队协作和代码维护。开发规范没有统一的标准,每个团队可以建立自己的一套规范体系。

值得一提的是JavaScript的开发规范,尤其是在ES2015越来越普及的局面下,保持良好的编码风格是非常必要的。笔者推荐Airbnb的eslint规范。

2.2 模块/组件化开发

2.2.1 模块还是组件?

很多人会混淆模块化开发和组件化开发。但是严格来讲,组件(component)和模块(module)应该是两个不同的概念。两者的区别主要在颗粒度方面。《Documenting Software Architectures》一书中对于component和module的解释如下:

A module tends to refer first and foremost to a design-time entity. ... information hiding as the criterion for allocating responsibility to a module.
A component tends to refer to a runtime entity. ... The emphasis is clearly on the finished product and not on the design considerations that went into it.

In short, a module suggests encapsulation properties, with less emphasis on the delivery medium and what goest on at runtime. Not so with components. A delivered binary maintains its "separateness" throughout execution. A component suggests independently deployed units of software with no visibility into the development process.

简单讲,module侧重的是对属性的封装,重心是在设计和开发阶段,不关注runtime的逻辑。module是一个白盒;而component是一个可以独立部署的软件单元,面向的是runtime,侧重于产品的功能性。component是一个黑盒,内部的逻辑是不可见的。

用通俗的话讲,模块可以理解为零件,比如轮胎上的螺丝钉;而组件则是轮胎,是具备某项完整功能的一个整体。具体到前端领域,一个button是一个模块,一个包括多个button的nav是一个组件。

模块和组件的争论由来已久,甚至某些编程语言对两者的实现都模糊不清。前端领域也是如此,使用过bower的同行知道bower安装的第三方依赖目录是bower_component;而npm安装的目录是node_modules。也没必要为了这个争得头破血流,一个团队只要统一思想,保证开发效率就可以了。至于是命名为module还是component都无所谓。

笔者个人倾向组件黑盒、模块白盒这种思想。

2.2 模块/组件化开发

2.2.1 模块还是组件?

很多人会混淆模块化开发和组件化开发。但是严格来讲,组件(component)和模块(module)应该是两个不同的概念。两者的区别主要在颗粒度方面。《Documenting Software Architectures》一书中对于component和module的解释如下:

A module tends to refer first and foremost to a design-time entity. ... information hiding as the criterion for allocating responsibility to a module.
A component tends to refer to a runtime entity. ... The emphasis is clearly on the finished product and not on the design considerations that went into it.

In short, a module suggests encapsulation properties, with less emphasis on the delivery medium and what goest on at runtime. Not so with components. A delivered binary maintains its "separateness" throughout execution. A component suggests independently deployed units of software with no visibility into the development process.

简单讲,module侧重的是对属性的封装,重心是在设计和开发阶段,不关注runtime的逻辑。module是一个白盒;而component是一个可以独立部署的软件单元,面向的是runtime,侧重于产品的功能性。component是一个黑盒,内部的逻辑是不可见的。

用通俗的话讲,模块可以理解为零件,比如轮胎上的螺丝钉;而组件则是轮胎,是具备某项完整功能的一个整体。具体到前端领域,一个button是一个模块,一个包括多个button的nav是一个组件。

模块和组件的争论由来已久,甚至某些编程语言对两者的实现都模糊不清。前端领域也是如此,使用过bower的同行知道bower安装的第三方依赖目录是bower_component;而npm安装的目录是node_modules。也没必要为了这个争得头破血流,一个团队只要统一思想,保证开发效率就可以了。至于是命名为module还是component都无所谓。

笔者个人倾向组件黑盒、模块白盒这种思想。

编辑:独家报道 本文来源:浅谈什么是前端工程化,浅谈工程化

关键词: Web前端 Html/Css JavaScript ES6 前端