关注「前端向后」微信公众号,你将收获一系列「用心原创」的高质量技术文章,主题包括但不限于前端、Node.js以及服务端技术
从面向过程的角度来看前端工程,就是各个过程,以及过程之间的衔接:
(面向过程视角下的)前端工程 = 过程 + 过程间的衔接
其中,过程旨在解决效率问题,而过程间衔接关注更多的是体验问题,前端工作流相关的所有工程设施都可以按这个标准来划分,要么是过程,要么是衔接
反过来从问题角度看,体验问题能够通过衔接来缓解,比如打通上下游工具/平台、写个批处理工具、搭个管理平台,效率问题则必须通过更优、更快的过程来解决,比如协作模式升级、构建速度优化
但面向过程的划分也存在一些问题,例如:
既然如此,不妨换个视角观察,从面向对象的角度来看
对象,是对前端应用生产活动中各个实体的抽象,其中一些对象是主体(比如充当不同角色的人),另一些是客体(比如工具、平台等各种具体事物)
对象之间通过一系列交互行为来完成前端应用的开发和交付:
与面向过程的视角不同,这里更关心的是对象和对象间的交互行为,以前端开发工作为例:
也就是说:
(面向对象视角下的)前端工程 = 对象 + 对象间的关系及交互
其中,对象的数量关系到体验,对象数量越多,主体需要关注的东西越多,体验越差,对象依赖关系的复杂度决定了效率,对象关系越复杂,交互越多越繁琐,效率越低
接口,是在前端应用生产过程中的一些抽象产物,不直接体现在最终交付物中,例如:
这些抽象产物定义了对象间通信的消息格式,让人与人、工具与工具、工具与人都能够紧密协作
抽象类,也是前端应用生产过程中的一些抽象产物,定义了不同对象之间的关联和交互方式,例如:
与接口不同,这些“抽象类”能够约束多个对象之间的联动关系,而接口要约束的是两个对象之间的一次交互行为
先将视角爬升到白云之上足够高的地方,再看前端生产活动:
现实问题(用户需求) -> 前端生产活动 -> (解决方案)前端应用程序
P.S.前端生产活动,指的是前端项目从需求到发布上线的整个生命周期
即,通过前端应用程序解决现实问题,中间的生产活动就是前端工程所关注的领域
如果把前端工程看作一个系统,其运作原理大致是这样:
一些人,通过一些交互,生成一些中间产物,最终交付前端应用程序
输入用户需求,输出前端应用程序,前端工程一直以来所要解决的问题无非两个:
P.S.当然,质量是前提条件,就像CAP 中的 P,实属没得选。所以伤及质量的效率、体验提升不在讨论范围内
首先,识别出系统中的所有主体对象:
那么顶层应该是前端生产平台,定义了研发模式和流程标准,让这些角色能够协同工作:
第二层是 5 大中心,承载前端应用程序在生命周期不同阶段的生产活动,关键类如下:
其中,以源码编辑为中心的研发工作台已经成为趋势,前端工作流相关的工具、平台与定制化端 IDE/云 IDE提供的开发环境充分融合,集中解决过程间衔接的体验问题
另一方面,传统的前端研发模式也正在发生变革,例如:
整个前端工程系统都是为了更快捷地交付前端应用程序,从这个角度来看,研发模式上的这些变革也是顺理成章的
抽象的目的是增加灵活性和通用性(抵抗变化),前端工程中有 3 种常见的抽象:
其中,抽象层的作用分为两种:
封装的目的是信息隐藏,就像一个柜台窗口,隔开了后厨与前厅,用来区分实现者和使用者
在前端工程中按关注点 的是平台维护者和用户,例如:
封装能够有效减少顶层对象数量,将内部的依赖隐藏起来,主体对象需要关注的对象更少,不必了解内部具体交互细节也能轻松完成一些复杂工作
继承的目的是复用现有对象的属性或行为,前端工程中常见的复用形式有:
其中,IDE 插件包是一种相对新的复用形式,比定制 IDE 和 GUI 客户端的成本更低,也不失为一种好的选择
多态的目的是扩展,从前端工程上看,多态体现在:
因此,不同的角色能够在一套系统中完成各自的工作,同样的研发模式能够产出不同类型的前端应用程序
从面向对象的角度来看,前端工程是对象和对象间的关系及交互行为:
一些人,通过一些交互,生成一些中间产物,最终交付前端应用程序
对象的数量直接关系到体验,对象间依赖关系的复杂度决定着效率。因此,要么减少主体对象需要关注的顶层对象数量,要么简化对象间的依赖关系
联系我