2019Thinking(上) -- 一个前端开发者的个人思考

奋飛

发布于 2019-08-15 16:49:40

9520

发布于 2019-08-15 16:49:40

文章被收录于专栏：Super 前端Super 前端

本文链接：https://ligang.blog.csdn.net/article/details/96026345

以下内容多为自己平时积累而来，思考和结论正确与否纯个人观点，希望对大家有所感悟和触发~~~

先写下两个观点和感悟：

每一项技术的诞生都是为了解决现有技术的一些弊端或满足现有发展的诉求；技术的发展会推动行业发展；行业的变革会衍生技术的变革！
前端行业是第二次信息产业浪潮的新产物！第三次、乃至第四次浪潮会带来怎样的变革以及淘汰哪些已有的观念，值得我们思考~~

回顾

17年9月刚到公司，感觉公司前端最大的问题：不是统一UI、不是搞个新框架，而是要通过建全基础设施，改变开发方式以及改变公司对前端的认知，将所有业务彻底解藕才是症结（前后端解耦、前端组件解耦）。

我们花了大约一年半的时间，来确立一套自己的基本游戏规则：代码规范、code review、Git的用法、开发流程、图表管理等等；现在我们需要熟练这套规则，与此同时想着如何添砖加瓦（我们的fusion系列已经陆续展开 — 旨在打造自己的前端生态圈闭环）。

做这些事情往往要求我们忍耐默默无闻、要就经常跳出自己的舒适区，到另一个不熟的领域甘心当小白，目的只有一个切实有效的把产品中的前端问题解决掉。对我们而言，通常这么做可以收获到更多更深刻的经验和知识，所以我们也乐此不疲。

首先，回顾从2017年10月份以来，我们做了哪些~~

「技术架构的确认」 — 我们确定并巩固了 Vue 作为观安前端团队的基础架构地位，ElementUI + Echarts 成为了我们首选。技术栈的统一，降低了产品间人员调动地成本，大大降低了架构层面的重复性问题。大家上手也可以更快，到目前为止，大部分人独立完成过前端架构的搭建~~
「源代码管理规范化」 — 我们出台了包括代码开发、代码管理、代码发布等等各种规范，避免了因多人协作而导致的风格不统一，保证产品的快速持续的功能集成。与此同时，我们提供了 Eslint 和 Commit Hooks 的结合处理；
「规范化 Git 工作流」 — 作为公司的支撑线，我们面对的项目众多，版本众多。制定了 Git 管理流程（fork+分支）以及提交规范，以及采用Angular cz 来约束大家提交信息。在众多业务线之间，达到了互不影响、平稳推进的效果；
「组件化过程」 — components => fusion 系列；组件化开发理念，可以快速拼装出产品；
「衍生」 — 基于 fusion 构想，我们完成了大屏生成工具、自动打包工具等一系列脚手架和工具集。

再者，回顾近几年前端圈，都发生了那些~~

[框架] — 2013年 React 诞生，意味着 jQuery、Bootstrap 当红时代即将结束。到今天前端框架逐渐形成 React/Vue/Angular 三足鼎立之势。几年前还在争论单向数据流和双向数据流孰优孰劣，现在三大框架已经不约而同选择单向数据流，双向绑定沦为单纯的语法糖。随着应用复杂度上升，会发现数据散落在不同的组件，组件通信会变得异常复杂，Redux、Vuex、NgRx 相应的问世。框架间的差异越来越小！！！
[端] — 2014年前后 IOS 以及 Android 开发炙手可热，到如今的H5、RN、Flutter 以及混合式开发 PWA 已占居鳌头。更多用户交互方式上变化，带了技术的变更。

总之，拥抱变化是前端工作中应被灌输的价值观！

这么多的变化，我们该何去何从？

工具是易变的，包括各种库、框架到构建工具、编辑器等；(jquery => vue；webstorm => vscode；grunt=>webpack)
前端技术是演变的，其不会像工具那样完全弃用，但新的标准（如ES6、TS）需要积极拥抱；
开发思想是不变的，在长期的开发实践中不断的总结、反思、衍生，其永远不会过时。

切实解决问题为导向，我们追求“最流行”的技术，但不盲目、不强加，加入自己的思考。

当下

所谓“当下”，即是我们必须积极拥抱的技术，需要我们学习、尝试并用到我们的项目上来~

TypeScript

Angular，React，Vue 底层语言已陆续全部换成了 Typescript（TS 是 JavaScript 类型的超集，其可以编译成纯 JavaScript）。TypeScript 提供最新的和不断发展的 JavaScript 特性，包括那些来自2015年的 ECMAScript 和未来的提案中的特性，比如 async…awati 和 Decorators，以帮助建立健壮的组件。TypeScript 最大的优势是它提供了强大的静态分析能力，结合 TSLint 能对代码做到更加严格的检查约束。实现了从后端 API 接口到 View 组件的全链路静态分析，具有了完善的代码提示和校验能力。编译通过几乎就代表运行正常！！

自己的独想：三大框架发展至今，经过了 MVVM 思想刚诞生一刻的疯狂叫卖，每个框架都沿着自己的理解发展壮大；经过2-3 年的沉淀，框架思想上又趋于了一致性，这里包括单向数据流、虚拟DOM、状态管理等。这样的发展并不是不好，而是一种趋势，所谓的“天下大势，合久必分，分久必合”吧。也相信在一个新的技术出现之前，三大框架在思想方面会越来越靠拢~~

GraphQL

GraphQL(Graph Query Language)一种用于 API 的查询语言也是一个满足你数据查询的运行时。其提供了一套易于理解的完整描述，使得客户端能够准确地获得它需要的数据，而且没有任何冗余，也让 API 更容易地随着时间推移而演进，还能用于构建强大的开发者工具。

GraphQL 诞生之前，是 Restful 的天下，GraphQL 带来了哪些重量级改观：

请求你所要的数据不多不少；通过 GraphQL 可以准确获得你想要的数据

  {
    user {
      name
      address
    }
    role {
      org
    }
  }

获取多个资源只用一个请求；典型的 REST API 请求多个资源时得载入多个 URL，而 GraphQL 可以通过一次请求就获取你应用所需的所有数据

GraphQL 除了 JavaScript 实现，已有多种编程语言（包括Go、Java、PHP、Python等）支持。

web components

当时 document.querySelector 首次被浏览器广泛采用，就此终结了 jQuery 的通用时代（无需强依赖，带来了一种更好的选择）。随着 web components 被各大浏览器厂商的支持，圈内出现了类 Web 组件即将取代前端框架 的讨论，不管是否真的替代，但发展方向上值得我们关注

现代 Web API 发展至今，使我们有能力不依赖框架来创建可复用的前端组件。我们所需创建的自定义组件就是自定义元素和影子DOM，这可以在任意地方复用。这也是第一次我们仅通过 HTML，CSS 和 JavaScript 就成功构建了可兼容任意浏览器的可复用组件。单从 web components 给我们带来的其不需要依赖于任何框架，即能完成组件的复用的效果，就可以博得我们的重视！

再深入讨论，目前基本任一浏览器都可以使用Web组件，包括移动端浏览器（端的概念也得到了一种原生适配模式）。

css-in-js

css-in-js 方案依旧争论不休，虽然它确实解决了一些 CSS 语言天生的问题，但同时增加了不少成本，新手不够友好、全局样式覆盖成本高涨、伪类处理复杂、与AntD（样式使用了Less作为开发语言）等组件库结合有坑。与此同时 Sass/Less 社区也在飞速发展，尤其是 Stylelint 的成熟，可以通过技术约束的手段来避免 CSS 的 Bad Parts。

微前端

中台，一个被"玩坏"的词，现在每个公司都在搞中台，但其方式却千万种。对于前端来说，灵活多变是特色，但中台却是要趋于强大平稳。微前端，以独立运行、独立开发、独立部署为宗旨。

注意需要前后端分离的单页应用，这是谈论微前端的基础

微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。

为什么微前端开始在流行

前端需要的是解耦，更需要的是解耦后的聚合！

技术没有银弹，采用新技术，更多不是因为先进，而是因为它能解决痛点。解决遗留系统，才是人们采用微前端方案最重要的原因。

思考我们的现状：情况一：一系列的安全产品且历史版本较多（这反应了我们是按业务线划分的组织架构）。但在用户眼里，观安是一家公司，其应该就是一个产品（或者说，各产品应该相通的）。我认为这个点在未来的某一天可能是我们最大的问题！情况二：全文检索、规则引擎，在每个产品中都有体现，存在各种迁移的情况。如果这些模块达到了可以独立运行和维护，以及和主项目组合的理想方式，我们便可以节省大量的时间！ 到底前端中台（微前端）该如何实现？我们该做哪些思考呢？

所以，聚合成为了一个趋势，体现在前端的聚合就是微服务化架构。

微件化、微应用化、路由分发、前端微服务化等。

微前端特点

各个前端应用还可以独立运行、独立开发、独立部署。

业务专一：领域模型更聚焦，功能更单一，产品通道业务高度内敛；
职责专一：谁负责产品，谁就负责微前端和专属业务中台建设，并保证全通道内业务的高可用；
隔离性：同类产品的问题修复和代码修改在一个产品通道内，不会影响其他产品通道的业务；
复用性：微前端可快速加入前端集成主页面，或将微前端直接发布成 APP；
响应能力：新产品通道可以独立开发、测试、集成和部署；
测试和沟通成本低：一个产品通道由一个中台项目团队负责；
技术敏感度低：微前端只要符合规范即可快速动态加载到前端集成主页面，前端项目在前端集成过程中不需要关注中台的技术实现和 API 集成，降低技术敏感度。

哪些方式

使用 HTTP 服务器的路由来重定向多个应用
在不同的框架之上设计通讯、加载机制，诸如 Mooa 和 Single-SPA
通过组合多个独立应用、组件来构建一个单体应用(路由) 应用分发路由 ==> 路由分发应用 微服务在这个过程中做的事情是，将调用由函数调用变成了远程调用，诸如远程 HTTP 调用。而微前端呢，也是类似的，它是将应用内的组件调用变成了更细粒度的应用间组件调用，即原先我们只是将路由分发到应用的组件执行，现在则需要根据路由来找到对应的应用，再由应用分发到对应的组件上。
iFrame，使用 iFrame 及自定义消息传递机制
结合 Web Components 构建

关注问题

依赖独立。即各个微前端应用的依赖是要统一管理，还是要在各个应该中自己管理。统一管理可以解决重复加载依赖的问题，独立管理会带来额外的流量开销和等待时间。
抛开前端中台不谈，如何切割前端业务粒度呢？同一业务、页面、组件？还是如何？
业务切分下去，如何聚合？大的规则和平台的搭建原则是什么，路由？如果一个页面是综合页，该如何处理？
UI及交互的统一问题，以及各模块或页面的跳转问题？
微服务用到的公共组件和方式如何处理，各自引用？还是集中构建时统一提供？按需？
多项目、多团队，这是一个事实也是趋势。如何统一构建和统一处理，是关键！

参考链接

Flutter

对于移动端开发，越来越多的人关注这样一句话：Learn once, write everywhere. Write once, use everywhere. 低成本、高复用是移动端目前的一个主要方向。

回顾整体发展阶段：

第一阶段：Native App 在系统的 framework 上面不断的开发新功能，Android、IOS、winphone、网页端等等需要我们维护众多版本，成本很高。所以就有了一个迫切的需求，能否开发一套在多个平台上运行，这样可以大大降低开发成本。
第二阶段： H5 H5 的诞生，市面上出现了好多 H5 将替代 Android 等原生开发，与此同时出现了很多开源框架来实现 H5 与底层的交互框架(PhoneGap、cordova等)，实现了低成本、跨平台的效果，但是性能问题导致其只能在很少的应用上取得成功。
第三阶段： RN/WEEX H5 性能瓶颈之一是绘制问题，通过原声绘制的方式来实现成为了主流。RN、weex等跨平台方案应用而生。这种开发带来的便利的同时，又有了新的问题产生了，就是桥的成本太高，当涉及到频繁的跨桥调用的时候，就会出现性能问题；维护成本甚至一度超过了Native开发，对于一些小团队来说简直就是噩梦。
第四阶段： Flutter Flutter 是谷歌的移动UI框架，可以快速在 IOS 和 Android 上构建高质量的原生用户界面。使用 Flutter 开发的APP 可以同时运行在 IOS 与 Android 平台上，且都感觉自然流畅。 构建真正的原生移动应用程序（无需学习Swift、ObjectiveC、Java等语言）！Flutter 是一种跨移动平台技术。

参考地址

React Native vs Flutter vs Ionic vs NativeScript vs PWA

PWA

Flutter 阐述完成，有必要再说下 PWA。

接着上面，H5 的发展，对移动端带来了一定的冲击，但是 H5 很难战胜 Native App 在性能和功能上强大。除了昂贵的开发成本、然后审核发布到各个商店的复杂发布流程，使得 Native App 较 Web App 有很大的差异。因此诞生了 PWA。

PWA（Progressive Web App）是一种理念，使用多种技术来增强 Web App 的功能，可以让网站的体验变得更好，能够模拟一些原生功能（PWA 在传统 Web 应用的基础上，通过完善Web应用的一些能力，比如离线使用、后台加载、添加到主屏和消息推送等，达到用户体验提升和性能优化）。在移动端利用标准化框架，让网页应用呈现和原生应用相似的体验。PWA 本质上是 Web App，借助一些新技术也具备了 Native App 的一些特性，兼具 Web App 和 Native App 的优点（需要考量的是，某些Native功能，PWA仍然实现不了，如调取摄像头< 出于安全考虑>）。

强调渐进式的改善站点体验主要有下面两个原因：

降低站点改造的代价，逐步支持各项新技术，不要一蹴而就
新技术标准的支持度还不完全，新技术的标准还未完全确定

PWA 的流行主要包含以下几个特点：

可靠 - 即时加载；即使在不稳定的网络环境下，也能瞬间加载并展现。Service Worker
体验 - 快速响应，并且有平滑的动画响应用户的操作。app Shell 架构模型
粘性 - 感觉就像设备上的原生应用程序，具有沉浸式的用户体验，用户可以添加到桌面

https://lavas.baidu.com/pwa/README

2016年， PWA 在google正式落地，基于 Chromium 的浏览器 Chrome 和 Opera 已经完全支持 PWA 了；随着 iOS 11.3 的发布，iOS正式开始支持PWA；Windows Edge 支持PWA。

PWA 的出现，使得 Web App 可以具备 Native App 的特性。在做开发时，多了一个选择，也多了一种思维方式

前端未来

信息产业的第一次浪潮是以信息处理PC机为代表；以互联网、通信网络为代表的信息传输推动了信息产业的第二次浪潮；而以传感网、物联网为代表的信息获取或信息感知，将会推动信息产业进入第三次浪潮。现在的前端，是由于互联网浪潮带来的，我们对于信息的传输方式的演变，从门户 => 网站 => app => 各种端；信息的传输导致了发展；然而，接下来会发生变化呢？AI？IOT？前端行业依附于整个信息产业，也诞生于第二次浪潮；信息产业本质或追求的变化，必然会导致前端行业的变化，或者导致新的行业产生。如何把握脉搏的发展，是需要我们关注的重点。

变化（全部来源于信息传输的推动）：

交互的改变：PC(键盘/鼠标) => 手机/PAD(触屏/摄像头/语音)，交互越来越自然、简单了
载体的改变：文本 => 图片 => 短视频/直播，用户创作内容的成本越来越低了
信息获取的改变：主动获取 => 被动推送 => 智能推荐，异步 => 实时，信息已触手可及

发展（全部为了满足变化，同时也推动了变化）：

前后端分离：全栈、全端、大前端等分工模式的创新
开发套件：语法、框架、工具、类库
引擎：V8(Nodejs)、Hybrid容器，方式的转变

未来：

AI：算法的天下，但需要关注
IOT：硬件及嵌入式系统，把 Node.js、浏览器内核移植到 IOT 设备 nodejs将 javascript推进了服务器端；同理lot，将js推进到了更广泛的设备。从简单的语音控制台灯，到复杂的javascript+物联网智能家居，js的应用范围越来越广。诸如可以使用 JavaScript 作为开发语言的 IoT.js
智能硬件：在 AI 、自动化控制及硬件上，给前端带来的更多是应用形态和交互方式的升级
Blockchain：利用全新加密认证技术和全网共识机制，维护一个完整的、分布式的、不可篡改的连续账本数据库，参与者通过统一、可靠的账本系统和‘时间戳机制。IPFS协议，利用分布式哈希表解决数据的传输和定位问题，把点对点的单点传输改变成P2P（多点对多点）的传输。
AR/VR/MR：
- AR：现实世界上叠加由计算机生成的虚拟形象，提供一个混合的视觉(手机扫描，出现一个人物)
- VR：虚拟现实，由计算机生成的三维环境，人可以在其中探索和交互
- MR：AR+VR结合
Serverless 最开始，一台单用户的物理服务器便能满足我们的日常所需，它快速，可靠并且安全，只对管理员负责，但是在实际中配置和扩展都很麻烦；虚拟机的出现满足了灵活性和可扩展性的需求；之后云服务提供商为我们带来了基础架构即服务（IaaS — Infrastructure as a Servic），云平台自助服务也由此诞生；再之后开始了集装箱化，带来了**平台即服务（PaaS — Platform as a Service）**的架构；于此同时，程序员仍想要更多的功能，如独立于编程语言（language agnostic）的端点，服务器的水平伸缩能力，以及可以实时支付服务使用量的能力。为了满足这些需求，Serverless计算应运而生，Serverless 架构大量依赖第三方服务。采用 Serverless 架构，也就意味着，我们提取出了大量的基础设施。Serverless 是付完即走，基于实际的消费而不是基于预测的预付款进行收费的—按需使用计费。Serverless 服务器架构是传统的云计算平台延申，是 PaaS 向更细粒度的BaaS和FaaS的发展，Serverless=BaaS+FaaS+…！
- BaaS（Backend as a Service）即后台即服务
- FaaS（Function as a Service）即函数即服务
对于前端而言而使用 Node.js + JavaScript 作为胶水，来快速连接不同的服务，以形成一个快速有效的方案。Node.js 在服务端的 Runtime 和运维方式，把服务端复杂的技术细节屏蔽掉，让Node更好的在服务端延续。并且，编写更少的代码，也意味着更安全、快速。除了直接基于 AWS 的 Serverless Framework 框架的方案，还有 OpenFaaS、Kubeless、OpenWhisk、Fission 等不同的 Serverless 框架。
可视化开发：通过更好的开发套件提升应用生产效率，其最大竞品是成品 SaaS，毕竟拿来就用比搭建更简单，Wix、Webflow