2019 年（大）前端技术规划

新的一年里，有些新的技术会从实验走向试用；有些技术，则会从试用走向采用；有些技术，则会从采用走向弃用。若是以此为出发点，那么这个 2019 年和过去的 2018 年相比，并不会有太大的区别。学一些新的技术，忘掉一些不同使用的技术。只是前端一个这么广的领域，到底要关心什么技术，到底要忽略什么技术呢？

这便也是我写下这篇文章的意义。可是呢，在写作的过程中：“不行啊，我光告诉你 2019 将会流行什么，可能并没有多大的意义。你们需要自己去学会拥有这样的技能，学会去分析出 2020 需要规划什么内容。”

于此，本文便分为了两部分，如何做前端规划以及 2019 年我们需要什么。

技术规划

W-H-Y

每每谈到技术规划，我们谈的总是下一年、下一个阶段、下一个五年的目标。可为什么我们需要做技术规划？或许是出于 KPI 的影响，或者是出于预算的原因，或是在追求技术卓越。

我们的目的是： 变得更好 。于是乎：“为什么我们就不能使用现在的架构？现在的架构不是挺好的吗？？”

为此，我们只需要尝试回答这么几个问题：项目的编译速度快吗？编写新功能的速度快吗？能满足快速上线的需求吗？多个团队并行开发，会出现问题吗？我们依赖的第三方组件，会出现问题吗？……

嗯，对这个问题就好像，别人在问你，“你有什么不足？”。

HOW

从这篇文章的写作过程，及笔者的相应规划步骤来看，可以分为这么几步：

调研技术远景

从社区获得相应的输入

整理潜在的技术方案、架构、技术栈

从利益相关者获得想法。

制定相关的实施计划

规划，它类似于技术远景的味道。可一谈到远景，那么要谈论的东西可多了。说不到我们还需要寻找利益相关者——如团队成员、项目领导，了解一下，他/她对于技术团队的一些期望。我们在社区上看到相似的问题，总有一个相似的开头：“我们的领导……。”

谈理想都特别有意思，因为我们不一定会去做。我们有了一个宏大的想法，只是受限于多个因素，我们只能做这么一点。比如说，我们未来想造一个笔记本，那么现在我们可以只选一个螺丝钉。

而在我们获取更进一步方向的时候，需要从这么几个维度来考虑问题：

从业务现状出发 。譬如，在下一年里，我们的团队将从 20 人扩大到 100 人，为了支撑这么大的团队。我们需要拥有培训机制，来应对这样的人员扩张；需要设计一个更好的架构，来实现多个团队的并行开发。
从技术、架构出发 。在项目中引入新的技术，改进原有的技术方案。
架构的预研 。提前试用未来可能使用的技术，如 AR、VR。这些往往是一些非必需的规划，但是有了它们会更好。
团队能力规则 。谈论到团队规划，我怕是并不是那么擅长。大抵上，哪怕是技术负责人也不是 KPI 的制定者，我们只能谈谈理想，聊聊团队建设的一些建议。有针对性地培养项目的 2nd Tier，至少对方是否能接受，那便不在我们的控制之下。这大抵也是个人发展的好处，，可以选择自己感兴趣的内容学习。
当然了，其它相当多的东西，还是要落地的——我们还是得造螺丝钉。只有落地的东西，才能证明它是真正有价值的东西。为此我们要用 SMART 原则制定一个 smart 目标。当然了，如果你还要对领导汇报，请不到忘了你的时间节点。

总之，保持现在，探索扩展，尝试未来。

WHAT

是不是我们规划每件的事，都值得去做？是不是我们只做规划的事情？未来是一直在发生变化的。而规划，只针对我们知道的内容提出的。它无法用于我们不知道的领域。它也无法应对未知的事务，如产生了一个新的技术，它提高了三倍的生产力。那么，先前我们设计的一些规划，可能在此被新的技术替代掉了。

这方面的实践，便有点类似于演进式架构的味道。我们定好了一个大体的目标，核心的部分，只在真正实现的时候完善。为此，它需要具备一定的可演进式，也因此不会受过去的设计所限制。倘若基于这一点因素考虑，那便是容易得多了。只需要去寻找那些真正可能影响我们的趋势，套上一个模糊的概念，就可以这么轻装上阵。

可是呢，在做这件事情的时候， 每个人心里都有了一个答案 。事实上，你心底也已经有了一个答案，只是说呢，你不敢、不想直接说出自己的想法——一来，受限于能力；二来，怕做了错误的决定。而直接、间接地，你在社区上看到一个大佬的回答，与你想要的答案是类似的。便将这个答案怀chen出来，信心也就有了，再说 “我们也可以这么搞”。好了，以后一旦出现了问题，还有一个人可以莫名地帮你背锅。

大家活着都不容易，背锅事小，不带人身攻击就好。责任，它与能力和屁股的位置是成正比的。

前端 in 后端

所谓的前端 in 后端，便是 在后端开发中，使用前端相关的语言和技术栈 。最典型的场景，便是使用 Node.js 开发后端服务。虽然 Node.js 已经有了 10 年的历史了，但是以我（Phodal）的角度来看，我更希望的是使用编译型语言，来开发后端服务。动态语言，无法使用编译器来检测错误，难以约束代码变动。

Node.js 打造后端服务

从社区的探索来看，存在一些完全使用 Node.js 开发的后台服务。但是，也存在一系列由于代码不规范造成的问题。从社区的经验来看，Node.js + Express + MongoDB + Angular/Vue/React，便是一些不错的选择。当然了，也有相当多的应用，只是采用了 Node.js 来完成 BFF 层（Backend For Frontends）。在这一层业务上，它只做业务数据的中间处理。

虽然，我经常建议在一些关键的节点上，不要采用 Node.js 来打造后台服务。可一旦涉及到 SPA 的服务端渲染，我们就不得不使用 Express、Koa 等这样的服务端 JavaScript/TypeScript 框架，来解决这样的问题。

Serverless

作为一种折中方案，也是我最喜欢的方案。Serverless 架构是指大量依赖第三方服务（也叫做后端即服务，即“BaaS”）或暂存容器中运行的自定义代码（函数即服务，即“FaaS”）的应用程序，函数是无服务器架构中抽象语言运行时的最小单位。

采用 Serverless 架构，也就意味着，我们提取出了大量的基础设施。而使用 Node.js + JavaScript 作为胶水，来快速连接不同的服务，以形成一个快速有效的方案。并且，编写更少的代码，也意味着更安全、快速。

除了直接基于 AWS 的 Serverless Framework 框架的方案，还有 OpenFaaS、Kubeless、OpenWhisk、Fission 等不同的 Serverless 框架。

前端架构

由于前端的代码量在不断地增加，前端不在是一个大泥球架构，越来越多的新架构，将出现在前端领域。

微前端架构

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!