极客时间已完结课程限时免费阅读

前端架构:前端架构有哪些核心问题?

前端架构:前端架构有哪些核心问题?-极客时间

前端架构:前端架构有哪些核心问题?

讲述:winter

时长08:02大小6.42M

你好,我是 winter,今天我们来谈谈架构。
在传统桌面软件开发中,架构师是一种通过设计架构保证团队能够良好分工和有序工作的岗位。
在工程领域,我们凡是要做点什么事儿,都会有明确的目的性,这个目的性,一定是为了完成生产服务业务的。
为什么桌面软件开发需要架构师和架构设计呢?因为桌面软件开发具有高度的复杂性,如果没有架构,就没法分解成互相耦合低的模块来分工。
所以一般来说,架构是为了分工而存在的。但是到了前端领域,这个问题是否还存在呢?答案是,不存在。
前端是个天然按照页面解耦的技术,在多页面架构中,页面的复杂度大约刚好适合一个人的工作量。(所以,我们的结论是,前端根本不需要架构设计。当然,我这句话是开玩笑的。)
前端不存在分工问题,但是在多人协同时,仍然要解决质量和效率的问题,这就需要组件化了。除此之外还有前端特有的兼容性问题,也是需要从架构的角度去解决的。
对于一些追求极致的团队来说,会挑战“单页面应用”,通过单页面应用来提升用户体验,单页面应用的升级版本是谷歌提出的 PWA,PWA 既是业务方案也是技术方案,在技术层面,它近乎苛刻地规定了网页的各方面的体验标准。
前端领域还有一个特有的生态:框架,第一代前端框架(如 jQuery, PrototypeJS)重点解决了兼容问题和 API 的易用性问题,在现代浏览器普及之后,这些问题逐渐变得不存在或者不重要,所以第二代前端框架(如 Vue,Angular,React)重点解决了组件化问题。选择合适的框架,可以节约架构的成本,还能够享受社区资源。
本节课,我会围绕前端架构的几个核心问题,为你介绍前端架构工作。
首先我们来讲讲组件化。

组件化

组件化讲起来是个非常简单的概念,前端主要的开发工作是 UI 开发,而把 UI 上的各种元素分解成组件,规定组件的标准,实现组件运行的环境就是组件化了。
现行的组件化方案,目前有五种主流选择:
Web Component;
Vue;
React;
Angular;
自研。
Web Component 是 W3C 推行的规范,理论上是未来的选项;但是实际上这份标准的状态堪忧,Shadow DOM 的设计比较复杂,一般的前端掌握起来都比较困难。
此外,CSS 也比较难以应用,需要依靠 CSS Houdini。目前来说,我还没有看到那个前端团队实际在使用 Web Component 作为组件化方案。当然,它的优势也非常明显:不需要任何额外的运行时支持,就能在现代浏览器环境运行,也可以跟 HTML 无缝结合。
Vue 是目前最受欢迎的框架(从 github star 来看),由华人程序员尤小右开发和维护。它有两个主要特点,一个是比较符合原本的 JavaScript/CSS/HTML 书写习惯;另一个是它绑定了 MVVM 模式,直接确定了 UI 架构,通过 DSL 的支持,数据交互非常简洁。
React 是 Facebook 推行的新一代 Web 框架。它利用 JSX 模式,把 HTML、CSS 和 JavaScript 都放进了 js 文件中,对于不喜欢 CSS 和 HTML 的前端工程师来说,是很理想的。它还可以迁移到 React Native,直接编写简单的客户端应用。
Angular 是 Google 推出的 Web 框架,它是比较标准的 MVVM 模式。Angular 曾经因为大版本兼容性而饱受诟病,目前它的核心竞争力是与 TypeScript 结合得较好。
上面是我对几种方案的简单介绍。但是实际上,我们做技术选型时的主要依据是团队的现状,开发移动端还是桌面端、是否跟 Native 结合、团队成员的技能分布都是需要考虑的因素,这些框架本身的特点,目前我认为仅仅是一种偏好选项,而不是关键因素。

兼容性和适配性

前端开发的特有问题就是兼容性,到了移动时代,需要面对不同的机型,我们又需要解决适配性问题。
兼容性问题到 2011 年左右都是前端的主旋律,但是在之后,随着现代浏览器的逐渐普及,兼容性问题逐渐减小,所以我们这里就不多谈兼容性问题了。
适配问题主要适配的是屏幕的三个要素。
单位英寸像素数(Pixel Per Inch,PPI):现实世界的一英寸内像素数,决定了屏幕的显示质量。
设备像素比率(Device Pixel Ratio,DPR):物理像素与逻辑像素(px)的对应关系。
分辨率(Resolution):屏幕区域的宽高所占像素数。
在当前环境下,分辨率适配可以使用 vw 单位解决,DPR 适配则需要用到 CSS 的 viewport 规则来控制缩放比例解决,而 PPI 主要影响的是文字,可以采用 media 规则来适配。

单页应用

前文已经讲过,前端架构的解耦问题不大,因为页面是天然解耦的,但是,大家都知道,浏览器加载 HTML 时是会有白屏过程的,对追求极致体验的团队来说,希望能够进一步提升体验,于是就有了“单页应用(SPA)”的概念。
单页应用是把多个页面的内容实现在同一个实际页面内的技术,因为失去了页面的天然解耦,所以就要解决耦合问题。也就是说,我们要在一个“物理页面”内,通过架构设计来实现若干个“逻辑页面”。
逻辑页面应该做到独立开发和独立发布,一种思路是,每个逻辑页面一个 js,用一个 SPA 框架加载 js 文件。
从交互的角度,这并不困难,但是,这里还有一个隐性需求:保持前进后退历史。
一般来说,前进后退历史使用 URL 的 Hash 部分来控制,但是 onhashchange 事件并没有提供前进或者后退信息,目前还没有完美的解决方案,只能牺牲一部分体验。实现单页应用的逻辑页面发布需要改造发布系统,在工程上,这也是一个比较大的挑战。

扩展前端新边界

除了解决现实问题,我认为前端架构的职责还包括扩展前端的边界,所以前端架构还包含了很多 Native 开发任务:如客户端和前端结合的方案 Weex 和 React Native;如前端和图形学结合的方案 GCanvas;如前端的 3D 框架 Three.js,这些都是试图用架构的手段赋予前端新的能力的尝试。
这些具体的尝试涉及很多领域知识,我这里就不做详细介绍了,但是如果你成为了一个前端架构师,我希望你也把“拓展前端边界”当做团队的核心目标之一。

总结

今天我从宏观的角度介绍了前端架构相关的知识,我重点介绍了“组件化”“适配性”“单页应用”三个前端架构需要解决的核心问题,组件化在社区有很多现成的方案,我们需要做的主要工作是框架选型。适配性需要用到 CSS 的几种特性:vw 单位、viewport 规则和 media 规则,单页应用重点是逻辑页面解耦、独立开发和发布和保持前进后退历史。
最后留一个思考问题,你所在的团队有前端架构师吗?如果有的话,他的工作职责是什么?
分享给需要的人,Ta购买本课程,你将得18
生成海报并分享

赞 11

提建议

上一篇
搭建系统:大量的低价值需求应该如何应对?
下一篇
新年彩蛋 | 2019,有哪些前端技术值得关注?
 写留言

精选留言(20)

  • 阿成
    2019-05-18
    我头铁,直接上新技术(react+hooks),因此遇到不少坑,不过是个小项目且只有我在做啦😂😂😂 怎么说,我觉得有时候还是要大胆一些... 当然多人协作的项目就不要搞人家了...
    35
  • Neil 陈荣
    2019-05-18
    我觉得在 spa 成为普遍现象的今天,前端架构特别重要。 然后大多数的小团队单是跟进前端技术的发展就已经很费力了,这时候如果是一个前端技术工具方面玩的溜一点的,却缺少架构思维的人在早期来主导项目的代码结构的话,往往会成为整个项目的灾难。 在团队缺少架构高手的情况下,还是做多页应用来得更可控些,需要体验优化的页面就是自己做成一个简单一些的 spa. 这是我从之前两个项目中学到的教训。
    展开
    18
  • 行云
    2019-05-22
    我很无耻的说一下,感觉spa更简单,反而传统的多页面开发模式,更麻烦
    11
  • fish·jade
    2019-05-21
    请问每个逻辑页面如何可以做到独立发布呢?
    8
  • 佚名
    2019-07-23
    在公司闲着无聊搭了一套 React 的架子想推广,结果被 CTO 直接拍死,说国内这么多学 Vue 的你给我搞什么 React...😂😂😂
    共 5 条评论
    6
  • 爱学习的大叔
    2019-07-15
    感觉我们没有前端架构,就是撸代码。实现功能就行。

    作者回复: 每个人都觉得是别人的事,但是总得有人第一个做。

    共 2 条评论
    6
  • Neil 陈荣
    2019-05-18
    关于组件化,我很不喜欢 react 中的 Functional Component 以及 HOC. 对于整个产品需求非常稳定情况来说,这样做也许没问题。把 UI表现和功能,按照不同的 perspective 去拆开,即所谓 separation by concern 的思路。 但对于一般的项目而言,往往需求变化都是比较频繁的,我认为更好的组件化方式是按功能切分。因为这样的组件内聚性比较好,会更便于代码阅读以及快速开发迭代。 在 React 上有些人比较推崇的那种纯 ui 表现类的组件,然后通过 HOC 来组装,实在是太绕了,完全不对我的胃口。
    展开
    共 5 条评论
    4
  • 靠人品去赢
    2019-07-08
    你好老师,现在管理的一个后台系统是JSP+Java合在一块的东西。想弄个功能类似上传视频,找到很多插件都是很久没有维护的,就在想要不要把这个前端JSP展示的部分提出来作为一个前端,后台只是作为一个core响应请求。如果是你的话,你会怎么做? 想问一下,想阿里的后台管理是怎么搞的,是不是前后端分离的,因为我知道阿里也是Java大户,像这种后台管理怎么做的?

    作者回复: 在现代服务端架构中,视频都是需要CDN支持的,所以很难通过“插件”来解决,这跟你的服务端架构强相关,如果是我的话就直接扔给云存储,后面用服务端逻辑解决。

    3
  • cjd
    2019-05-18
    没有架构 项目用什么自己定 经常会很纠结用什么技术😂 有些想尝试的新技术 由于能力有限加项目通常都很赶 不敢实践到项目中 不加班的时候 会自己写些demo 折腾折腾
    3
  • Cool
    2019-07-18
    一个人撸到尾,github就是我的架构
    2
  • Yully
    2020-06-08
    有前端架构师 公司的后台管理系统就是公司大佬用web component实现的,并且也一直在推,但是就像老师文章里写的,不好上手,组件库对前端团队公开之后,陆陆续续后来新增的组件,基本上都不是web component了……
    1
  • sugar
    2019-10-10
    spa好像不止hash一种实现方式,抛弃老版本浏览器的话,似乎可以利用history api,结合服务端url path接力,实现可前进后退的spa吧?我见过这样的 不知这种方式除了旧版本兼容性外 还有没有啥坑~

    作者回复: 你说的没错,但是history api配合URL就需要服务端做很多事情了,这个是个综合架构问题,目前我还没见过特别好的案例

    1
  • sugar
    2019-10-10
    目前实现spa方面 是否有较为成熟的框架推荐

    作者回复: 这个我不太了解,目前社区方案我没有太满意的。

    1
  • 令狐洋葱
    2019-08-19
    “实现单页应用的逻辑页面发布需要改造发布系统,在工程上,这也是一个比较大的挑战。” 老师,这句话是指单独发布部分逻辑页面么?
    1
  • 小孔
    2019-05-28
    如果项目只有我自己写的话 我会用新技术、自己不熟悉的领域去练习, 自己思考组价架构,设计模式等。。如果是多人协作 我可能就随大流了。。不敢瞎搞
    1
  • Scorpio
    2019-05-18
    自己写代码,自己规划架构。。。
    1
  • ryannz
    2022-03-18
    今天连webide都出现了,在中后台领域,架构的重要性还是无法忽视的
  • 马玉珍
    2021-11-20
    老师您好,使用vue做的saas系统,需要将外部应用优雅的嵌入到当前的系统中,有什么推荐的方案么?
    共 1 条评论
  • Geek_6718a9
    2020-08-24
    公司也在用spa,angular自带的路由机制可以满足绝大部分需求了
  • metthew😀
    2019-06-10
    没有前段架构师,有部分人维护框架,但是架构升级或较大优化就没人了