前端领域不需要架构师?

更新日期: 2019-12-12阅读: 1.8k标签: 架构

引言

在传统桌面软件开发中,架构师是一种通过设计架构保证团队能够良好分工和有序工作的岗位。在工程领域,我们凡是要做点什么事儿,都会有明确的目的性,这个目的性,一定是为了完成生产服务业务的。

为什么桌面软件开发需要架构师和架构设计呢?因为桌面软件开发具有高度的复杂性,如果没有架构,就没法分解成互相耦合低的模块来分工。所以一般来说,架构是为了分工而存在的。但是到了前端领域,这个问题是否还存在呢?答案是,不存在。

前端是个天然按照页面解耦的技术,在多页面架构中,页面的复杂度大约刚好适合一个人的工作量。(所以,我们的结论是,前端根本不需要架构设计。当然,我这句话是开玩笑的。)

前端不存在分工问题,但是在多人协同时,仍然要解决质量和效率的问题,这就需要组件化了。除此之外还有前端特有的兼容性问题,也是需要从架构的角度去解决的。

对于一些追求极致的团队来说,会挑战“单页面应用”,通过单页面应用来提升用户体验,单页面应用的升级版本是谷歌提出的 PWA,PWA 既是业务方案也是技术方案,在技术层面,它近乎苛刻地规定了网页的各方面的体验标准。

前端领域还有一个特有的生态:框架,第一代前端框架(如 jquery, PrototypeJS)重点解决了兼容问题和 api 的易用性问题,在现代浏览器普及之后,这些问题逐渐变得不存在或者不重要,所以第二代前端框架(如 vueangularreact)重点解决了组件化问题。选择合适的框架,可以节约架构的成本,还能够享受社区资源。

接下来,我会围绕前端架构的几个核心问题,为你介绍前端架构工作。


一、组件化

组件化讲起来是个非常简单的概念,前端主要的开发工作是 UI 开发,而把 UI 上的各种元素分解成组件,规定组件的标准,实现组件运行的环境就是组件化了。现行的组件化方案,目前有五种主流选择:

  • Web Component;
  • Vue;
  • React;
  • Angular;
  • 自研。

Web Component 是 W3C 推行的规范,理论上是未来的选项,但是实际上这份标准的状态堪忧。Shadow dom 的设计比较复杂,一般的前端掌握起来都比较困难。

此外,css 也比较难以应用,需要依靠 CSS Houdini。目前来说,我还没有看到那个前端团队实际在使用 Web Component 作为组件化方案。当然,它的优势也非常明显:不需要任何额外的运行时支持,就能在现代浏览器环境运行,也可以跟 html 无缝结合。

Vue 是目前最受欢迎的框架(从 GitHub star 来看),由华人程序员尤小右开发和维护。它有两个主要特点:一个是比较符合原本的 JS/CSS/HTML 书写习惯;另一个是它绑定了 MVVM 模式,直接确定了 UI 架构,通过 DSL 的支持,数据交互非常简洁。

React 是 Facebook 推行的新一代 Web 框架。它利用 JSX 模式,把 HTML、CSS 和 JS 都放进了 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 规则,单页应用重点是逻辑页面解耦、独立开发和发布和保持前进后退历史。

最后留一个思考问题,你所在的团队有前端架构师吗?如果有的话,他的工作职责是什么?

原文:https://zhuanlan.zhihu.com/p/87554025

链接: https://www.fly63.com/article/detial/6850

微内核架构在大型前端系统中的应用

架构和框架是独立的,本文仅仅是提出一种架构思路,而且这个架构也在百度的某款用户量很大的复杂前端产品中得以应用。基于这一套弹性架构并结合Vue/React的现代化开发理念,可以很好的完成高复杂度的前端系统。

怎么判定web前端架构师的能力高低?

软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。传统软件架构描述的对象是直接构成系统的抽象组件,侧重于系统的抽象、拆分、组织方式等

成为一个顶尖架构师

架构师的一个重要职责是,确保团队有共同的技术愿景,以帮助我们向客户交付他们想要的系统。在某些场景下,架构师只需要和一个团队一起工作,这时他们等同于技术引领者。在其他情况下,他们要对整个项目的技术愿景负责,通常需要协调多个团队之间,甚至是整个组织内的工作。

C/S和B/S两种架构区别与优缺点分析

C/S 架构是一种典型的两层架构,其全程是Client/Server,即客户端服务器端架构,其客户端包含一个或多个在用户的电脑上运行的程序,而服务器端有两种,一种是数据库服务器端,客户端通过数据库连接访问服务器端的数据

架构/构建高可用的网站

目的为保证服务器硬件故障时依然可用,数据依然保持并能够访问,手段:数据和服务的冗余备份以及失效转移机制,有状态 :在服务端保留之前的请求信息,用以处理当前请求(例如:session)无状态 :没有特殊状态的服务

大型web系统架构详解

动态应用,是相对于网站静态内容而言,是指以c/c++、php、Java、perl、.net等服务器端语言开发的网络应用软件,比如论坛、网络相册、交友、BLOG等常见应用。动态应用系统通常与数据库系统、缓存系统、分布式存储系统等密不可分。

讲讲亿级PV的负载均衡架构

本来没想写这个题材的,为了某某童鞋能够更好的茁壮成长,临时写一篇负载均衡的。负载均衡,大家可能听过什么3层负载均衡、4层负载均衡、7层负载均衡什么的?那这是怎么分的呢,ok,是根据osi七层网络模型来分的,例如nginx是工作在应用层

朱晔的互联网架构实践心得:品味Kubernetes的设计理念

Kubernetes(k8s)是一款开源的优秀的容器编排调度系统,其本身也是一款分布式应用程序。虽然本系列文章讨论的是互联网架构,但是k8s的一些设计理念非常值得深思和借鉴,本人并非运维专家,本文尝试从自己看到的一些k8s的架构理念结合自己的理解来分析 k8s在稳定性

大型网站核心架构要素

一般来说,除了当前的系统功能需求外,软件架构还需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素。性能是网站的一个重要指标,任何软件架构设计档案都必须考虑可能会带来的性能问题。

大型网站技术架构 构建高可用的网站 高可用的服务

本章介绍如何去构建高可用的服务,关键词:服务分级,超时设置,异步调用,服务降级,幂等性设计,一些架构设计中的常用方案,但是需要结合实际业务场景进行设计,没有一套方案能解决所有问题

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!