2019 前端年终总结（干货满满）

对我而言，今年技术创新的关键词是「UI 框架 / 脚手架」和「低代码（Low Code）」，技术实践的关键词是「桌面端」。

UI 框架 / 脚手架设计

今年年初的主要工作是对基础组件库进行框架重构以及对业务组件库进行框架设计，这是自我感觉最快乐的时光，因为一直不停的需要解决一些棘手的问题（往往困难是自我成长的机会点）。接下来将从以下四个方面讲解 UI 框架 / 脚手架设计的过程：

• UI 框架重构前提

• 基础组件库的框架重构

• 业务组件库的框架设计

• UI 脚手架的设计

UI 框架重构前提

公司现有的基础组件库 1.x 基于 Element UI 框架进行设计，在开发的过程中发现 Element  UI 框架带来了以下一些问题（相对我司而言）：

• UI 源码编译的 Webpack 配置复杂

• Demo 演示的 Webpack 配置复杂，且对于 UI 开发者的开发体验不够友好

• Demo 演示的线上体验不够友好

• Demo 演示没有 CI 自动部署能力

• UI 框架的 Scripts 脚本繁多（多数是因为需要编译各种输出规范以及按需引入的能力）

“

友情提示：如果 UI 框架的一些能力（例如 、、）根据公司自身的情况并不需要，那么完全可以砍掉从而大幅度简化 Webpack 配置（除非未来想要开源）。

为了解决上述问题，对公司现有的基础组件库 1.x 版本进行了框架重构。

基础组件库的框架重构

首先重点研究了 Element UI 框架的设计，其次在此基础上对组件库进行了框架的重构设计，重构成 2.x 版本后的框架大致如下图所示：

该业务组件库在基础组件库 2.x 特性的基础上，还存在如下特性：

• Webpack 配置相对基础组件库更简单（不需要针对所有的组件统一收口特殊 Loader 和 Plugin 的 Webpack 配置），各个组件库在通用配置的基础上定制化 Webpack 配置的能力即可（Babel 同理）

• 各个业务组件在 Lerna 的统一规范约束下有独立的开发、构建和发布流程，能够快速响应 Bug

• 换肤、、 等天然成为了业务基础组件，被各个业务组件复用的同时也可被业务复用

• 所有业务组件的版本受到了 Lerna 整体版本的约束（不会随着响应 Bug 的修复版本越跑越乱）

• 通用业务组件可编译可不编译（针对使用 Webpack 的工程项目，没有特殊 Loader 理论上不建议编译）

• 不提供全量引入的能力、不提供  能力

“

额外吐槽：这种按需加载的模式最好是和 Vue CLI 3.x 建立配套体系，例如业务项目的脚手架是基于 Vue CLI 3.x 设计的，那么天然可以进行无缝适配。

UI 脚手架的设计

由于 Vue CLI 3.x 提供了插件化的开发方式，于是基于业务组件库的框架设计抽离了一套 UI 脚手架，从而可以快速构建一个新的组件库。该脚手架在业务组件库的特性基础上，还存在如下特性：

• 一键生成：只需一个命令即可快速生成新的 UI 组件库

• 插件体系：除了脚手架中提供的 UI 插件以外，还可以扩展自定义插件

• 统一规范：在 Lerna 的约束下可以形成统一的开发、测试、构建和发布规范

• 响应特点：组件库的版本迭代可以更快，不需要进行整体构建，可以快速响应 Bug

当然这个 UI 脚手架的设计也存在一些缺陷：

• 业务开发成本提升（按需引入）

• 不提供 UMD 模块（针对 Webpack 工程项目）

• 业务项目基于 Vue CLI 3.x （可在此基础上自定义项目工程的脚手架）

通过一键命令生成的 UI 组件库结构大致如下：

“

友情延伸：专门写了一篇关于 UI 脚手架设计的文章，重点讲解了 Element UI 框架的设计原理以及 UI 脚手架的整体框架设计方案，感兴趣的同学具体可查看 Vue CLI 3 结合 Lerna 进行 UI 框架设计。

低代码（Low Code）设计

低代码解决方案是年中的时候设计的，主要源于业务的诉求（需要注意技术都是源于业务的诉求，不要凭白造轮子）。低代码的设计主要经历了以下几个阶段（加粗的部分由其他同事实现或者和其他同事一起协作实现）：

• 动态表单可动态校验（根据 JSON 信息动态渲染表单项）

• 动态表单可动态发请求（表单项可动态发送请求渲染信息）

• 动态表单可动态级联（根据表单项的变化进行表单项的动态渲染等）

• 业务组件库基于 UED 规范设计通用的页面布局组件

• 基于页面布局组件沉淀通用页面模板能力（UED 规范以及业务反哺）

• 制作可一键将通用页面、依赖、菜单处理集入业务工程项目（基于通用项目脚手架）的服务工具，从而提升业务的开发效率

• 基于通用页面模板实现简单的动态页面渲染能力 （此时的渲染 JSON 没有形成规范）

• 制作动态渲染的 JSON 规范（类似于 JSON Schema 规范）

• 制作视图渲染器，可根据规范的 JSON Schema 动态渲染页面（包括路由的跳转）

“

额外补充：当时视图渲染器在逻辑设计以及数据处理上没有完全想清楚，当然后续还需要设计视图拖拽引擎，最终实现可视化低代码的设计。

除了自己参与的低代码设计，也深刻学习了阿里的低代码中台产品，这个体会就深了，由于没有开源这里不再赘述。

桌面端开发

桌面端是年末才接触的，对于桌面端的开发主要经历了以下几个阶段：

• 了解现有 PC 桌面端的开发框架（科普可跳过）

• 优化现有 PC 桌面端 CEF 的开发框架

• 约束 APP 开发规范

现有 PC 桌面端的开发框架

个人认知的现有 PC 桌面端的开发类型主要分为以下几种类型：

其中涉及到 Web 前端的桌面端应用开发框架如下（这里只是做简单调研）：

开发纯 Native 应用的成本较高，一般对性能要求极高的产品才会选择此类开发方式（例如微信）。通常而言，从开发成本、操作系统兼容性、跨平台能力、UI 效果以及产品的迭代速度等方面而言，采用纯 Web 的开发方式是大部分公司都会选择的高性价比开发方式。当然像 DingTalk 这样的产品在考虑整体性价比的同时也会对标微信的性能体验，选择 Hybrid 混合开发是一种非常高效的迁移方案（不仅可以提升产品的性能，实现部分高性能需求的 UI Native 化，还可以从 Nw.js 进行部分应用的平稳迁移）。

优化现有 PC 桌面端的 CEF 开发框架

公司现有的桌面端应用采用 CEF 多容器隔离的框架进行设计，大致的框架图如下所示：

• Webpack 单入口配置（各个应用由通用脚手架生成新的工程项目，新增的应用不需要额外进行 Webpack 多入口配置）

• 新增脚手架且对应用进行规范约束（脚手架是同事做的）

• 新增应用可随着脚手架升级语言新特性

• 解耦公共服务，形成 npm 包独立维护体系，并形成开发文档提升开发体验（未完成）

• 解耦业务组件库，形成 npm 包独立维护体系，并形成开发文档提升开发体验（未完成）

• 应用单独构建且构建速度快，构建整体应用包时稳定性高，可形成局部构建能力（测试期间可进行局部构建测试）

• 一键 CLI 整合整体应用包（未完成）

“

友情提示：这里的公共服务很多，例如还包括 Native API、本地存储、TypeScript 公共类型定义等。

约束应用的开发规范

脚手架只是约束了应用的技术栈（包括开发、校验、构建和测试流程等），除此之外还需要约束工程项目内部更加细致的开发规范，后续更利于多人协作和维护。这里对每个应用的开发做出了如下的规范约束（2 个月的 React 开发经验提出的规范，如果不够完善请大家多多补充）：

“

友情提示：读书是很花时间的，如果你觉得自己静不下心来读书，我觉得看看视频也是不错的。如果你静的下心来读书，那就好好读几本自己欠缺的书籍。当然除了一些技术书籍，平常也应该注意阅读一些能够改善思维的书籍（辛亏小时候养成了阅读文学作品的好习惯）。

笔记

好记性当然不如烂笔头，有些书你读着读着就变得难以理解，或者你读着读着就忘记了。这个时候最笨但最有效的方法是边读边实践边记录。记录和实践的过程一方面可以帮助你理解书中的阐述，另外一方面当然也可以帮助你日后快速回忆书本的大致内容（尤其是面试前特别管用），达到抛开书本提取精华的目的。这里我将我之前的笔记整理出来供大家参考：

• jquery2.0.3源码分析笔记 –  参考《锋利的jQuery》/《jQuery技术内幕》/《JavaScript高级程序设计》/《JavaScript权威指南》

• ES6学习笔记 – 参考《ES6标准入门》

• 设计模式 – 参考两本《JavaScript设计模式》

• JS类和继承 – 参考《ES6标准入门》/ 《JavaScript高级程序设计》/《JavaScript权威指南》

• 如何使JS提高运行性能 – 参考《高性能JavaScript》

• 算法导论与javascript实现 – 参考《算法导论》/《数据结构与算法JavaScript描述》/ javascript-algorithms / CLRS – 【进行中】

• 数据结构和算法  – 参考《数据结构与算法JavaScript描述》

• CSS权威指南 – 参考《CSS权威指南》

• CSS世界 – 参考《CSS世界》/《CSS权威指南》

• 精通CSS – 参考《精通CSS：高级WEB标签解决方案》

• HTTP协议分析 – 参考《图解HTTP》

• 正则表达式 – 参考《精通正则表达式》- 【进行中】

以下是早期的笔记（很 Low 的 Word 文档），但是有好几百页几万字的那种（现在自己看看都蛮佩服自己的），那时候还不知道用 MD 格式：

• JavaScript高级程序设计 – 参考《JavaScript高级程序设计》

• JavaScript权威指南 – 参考《JavaScript权威指南》

“

友情延伸：ziyi2/awesome-front-end 是自己整理的一个前端大杂烩，除了笔记、书籍和博客之外，还有我珍藏多年的书签（不定时更新）。

文档（英文）

文档部分主要强调的是阅读能力和书写能力：

阅读能力：这里需要强调的是培养自己阅读英文文档的能力（尽量阅读官方文档，除非你很难看懂文档到底说了什么）。如果你觉得阅读比较吃力可以配套一些 Chrome 翻译插件（例如 Google 翻译）。通常在研究一些新技术的时候需要阅读一些官方文档（这些文档大比例都是英文文档，而且一般情况下英文文档的更新会比中文文档更新的更快），所以阅读英文文档是一个非常重要的能力。书写能力：书写文档能力是一种非常非常非常重要的能力，它可以很大程度上减少设计和沟通成本（防遗忘 / 防重复说明等）。当然书写规范也是很重要的，你可以参考一些开源作品的官方文档书写风格，也可以参考一些特定的书写规范（例如阮一峰的中文技术文档的写作规范）。当然写文档也需要养成实时更新的好习惯，否则过时的内容反而会导致设计和沟通成本的提升。

“

友情延伸：如果公司能够使用语雀，推荐语雀作为技术文档产品是一个不错的选择。如果不能使用外部产品，可以自行建立文档预览站点，例如使用 VuePress / React Static 等。

博客

写技术博文是今年开始才真正养成的习惯，虽然自己曾经有一个博客站点 www.ziyi2.cn，但其实更多的是记录一些学习笔记或者生活。今年开始在 Github 上使用 Issue 书写技术博客（以前总觉得要有一个自己的域名站点且 页要酷炫，现在是真的觉得要好用且实在，不搞花里胡哨的东西）：

招聘

来了阿里之后，很多地方和原来的公司还是有很大的差异。比如更加自由（上下班不用打卡，如果加班很晚第二天可以中午到公司……）、更加忙碌（各种评审会、周会、双周会以及月会等）、更加独立自主（很多业务有人催但没人管，你需要自己为你的业务买单，是一种自下而上的模式而非自上而下的模式）、更加多面（跨部门协作、移动办公、技术培训、文化培训等等）。我觉得挺好，因为我不单单只是在写代码。除此之外，同事都很厉害，如果你遇到解决不了的问题几乎只要一脑暴，立马就有了解决方案。

说了那么多当然是希望大家能来应聘，因为真的缺人。当然为了让大家能够更加熟悉我们这边的招聘流程，这里会从以下三个方面简单说说我当面试官的一些感受：

• 简历评估

• 面试过程

• 后续流程

简历评估

评估简历是招聘流程中的第一步，如果简历评估不过关那么将不会有接下来的面试流程。很多加我的掘友都会让我帮忙看看简历做的是否合理（往往这些掘友对自己都不够自信），其实简历大多数是由各位的学习和工作经历决定的，没有合理不合理的说法，只有合适或者不合适应聘岗位的情况。当然对于众多投递的简历还是会先做第一步筛选（这不是我自认为的简历评估方法）：

• 3 年以上工作经验

• 技术栈符合 BU 的业务场景

• 技术栈很丰富且有深度

• 技术创新 / 普惠能力

• 业务复杂且能体现自己的负责性 / 主动性

• 带领团队的能力

• 开源项目经验

以上是我作为一面面试官的评估方法，这是一个很现实的问题（有些评估方面怕引起众多掘友不良反应，这里就不一一列举了），因为很难从一堆简历中去精准的挑选出一个合适的简历（事实上大部分简历都千篇一律，因为大家写简历的形式真的都差不多），所以得有一套基本的评估方法。当然如果没有筛选出以上信息，我还会从以下信息进行二次筛选：

• 2 年工作经验技术栈有深度

• 技术普惠能力

• 业务能体现自己的主动性 / 思考性

• 业务上有性能优化经验

除此之外当然也会有一些硬性过滤的指标：

• 频繁跳槽（会被定位成没有业务 / 技术沉淀）

• 简历做的极不认真（排版不清晰 / 错

  声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！